Re: [openstack-dev] [Cinder] PTL candidacy
+1. Sean's services as Cinder PTL is really appreciable!! Regards, Sheel Rana On Sep 12, 2016 7:11 PM, "Sean McGinnis" wrote: Hello everyone, I would like to announce my candidacy to continue as Cinder PTL for the Ocata release. The Cinder project has made great strides over the last several releases adding functionality and improving stability. I think we have a very active team and love being part of such a strong community. The Ocata cycle will be a much shorter one than in the past. One thing I would like to encourage for this release, as much as makes sense, is to focus on being mostly a bug fix and stabilization cycle. One side effect of all of the great new work going in recently is there has been a lot of new code introduced and changes made. There have been fundamental changes in how some things operate with the the change from rootwrap to privsep. I would like to take advantage of this shorter concentrated cycle to delay some things in order to make sure we have a solid foundation to build on. Not to say there are any major issues with the project, or that there isn't new work that we do want to get in to Cinder. We have an incredible team that has been able to introduce some pretty significant code with little to no impact on the rest of the system. Folks have done a great job manually testing as well as adding unit and other automated testing to ensure high quality. But even with code that has been in there untouched for years we still find certain conditions that bring out issues. It would be great to find some of these now before we build too much more on top. Between the Summit and holidays for most over this cycle, Ocata will really be a short one. But I look forward to seeing how much this team can do, even in this quick cycle. This could be a lot of fun! Thank you for your consideration! 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
[openstack-dev] [Cinder] PTL candidacy
Hello everyone, I would like to announce my candidacy to continue as Cinder PTL for the Ocata release. The Cinder project has made great strides over the last several releases adding functionality and improving stability. I think we have a very active team and love being part of such a strong community. The Ocata cycle will be a much shorter one than in the past. One thing I would like to encourage for this release, as much as makes sense, is to focus on being mostly a bug fix and stabilization cycle. One side effect of all of the great new work going in recently is there has been a lot of new code introduced and changes made. There have been fundamental changes in how some things operate with the the change from rootwrap to privsep. I would like to take advantage of this shorter concentrated cycle to delay some things in order to make sure we have a solid foundation to build on. Not to say there are any major issues with the project, or that there isn't new work that we do want to get in to Cinder. We have an incredible team that has been able to introduce some pretty significant code with little to no impact on the rest of the system. Folks have done a great job manually testing as well as adding unit and other automated testing to ensure high quality. But even with code that has been in there untouched for years we still find certain conditions that bring out issues. It would be great to find some of these now before we build too much more on top. Between the Summit and holidays for most over this cycle, Ocata will really be a short one. But I look forward to seeing how much this team can do, even in this quick cycle. This could be a lot of fun! Thank you for your consideration! 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
Re: [openstack-dev] [Cinder] PTL Candidacy
On 03/11/2016 01:41 PM, Sean McGinnis wrote: > Hey everyone, > > Wow, how six months flies! I'd like to announce my candidacy to continue on as > Cinder PTL for the Newton release cycle. > > A lot has been accomplished in the Mitaka cycle. After a lot of work by many > folks, over a couple development cycles, we now have what we consider a "tech > preview" of rolling upgrades. It just hasn't had enough runtime and testing > for > us to say it's "official". We will likely need to fix a few minor things in > the > Newton timeframe before it's fully baked and reliable. But it has come a long > way and I'm really happy with the progress that has been made. > > Another priority we had identified for Mitaka was active/active high > availability of the c-vol service. We were not able to complete that work, but > many pieces have been put in place to support that in Newton. We fixed several > API races and added the ability to use something like tooz for locking. These > are foundation pieces for us to be able to start breaking out things and > running in a reliable active/active configuration. > > Microversion support has been added and there is now a new v3 API endpoint. > This was a bit of a controversy as we really had just started to get folks to > move off of v1 to v2. To be safe though I decided it would protect end users > better to have a clearly separate new API endpoint for the microversion > compatibility. And now hopefully it is our last. > > Replication was another slightly controversial feature implemented. Late in > Liberty we finally agreed on a spec for a v2 version of replication. The v2 > spec was approved so late that no one actually had time to implement it for > that release. As we started to implement it for Mitaka we found that a lot of > compromises had crept in during the spec review that it had the risk of being > too complex and having some of the issues we were trying to get rid of by > moving away from replication v1. At our midcycle we had a lot of discussion on > replication and finally decided to change course before it was too late. > Whether that ends up being the best choice when we look back a year from now > or > not, I'm proud of the team that we were willing to put on the brakes and make > changes - even though it was more work for us - before we released something > out to end users that would have caused problems or a poor experience. > > Other than that, there's mostly been a lot of good bug fixes. Eight new > drivers > have been added from (I think) five different vendors. The os-brick library is > now 1.0 (actually 1.1.0) and is in use by both Cinder and Nova for common > storage management operations so there is not a duplication and disconnect of > code between the two projects. We were also able to add a Brick cinder client > extension to be able to perform storage management on nodes without Nova (bare > metal, etc.). > > None of this goodness was from me. > > We have a bunch of smart and active members of the Cinder community. They are > the ones that are making a difference, working across the community, and > making sure Cinder is a solid component in an OpenStack cloud. > > Being part of the Cinder community has been one of the best and most engaging > parts of my career. I am lucky enough to have support from my company to be > able to devote time to being a part of this. I would love the opportunity to > continue as PTL to not just contribute where I can, but to make sure the folks > doing the heavy lifting have the support and project organization they need to > avoid distractions and be able to focus on getting the important stuff done. > > I think in Newton we need to continue the momentum and get Active/Active > Cinder > volume service support implemented. We need to continue to work closely with > the Nova team to make sure our interaction is correct and solid. But also work > to make Cinder a useful storage management interface in environments without > Nova. I will continue to encourage developer involvement and vendor support. > We need to improve the user experience with better error reporting when things > go wrong. And last, but definitely not least, we need to continue to expand > our > testing - unit, functional, and tempest - to make sure we can avoid those > errors and deliver a high quality and solid solution. > > I really feel I'm just getting into the swing of things. I would love the > opportunity to serve as PTL for the Newton release. FWIW, you have my support. Thanks for your service! -- Tom > > Thank you for your consideration. > > Sean McGinnis (smcginnis) > > > __ > 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] [Cinder] PTL Candidacy
Thanks for your leadership Sean, I think you've done a terrific job. Gorka. On 11/03, Sean McGinnis wrote: > Hey everyone, > > Wow, how six months flies! I'd like to announce my candidacy to continue on as > Cinder PTL for the Newton release cycle. > > A lot has been accomplished in the Mitaka cycle. After a lot of work by many > folks, over a couple development cycles, we now have what we consider a "tech > preview" of rolling upgrades. It just hasn't had enough runtime and testing > for > us to say it's "official". We will likely need to fix a few minor things in > the > Newton timeframe before it's fully baked and reliable. But it has come a long > way and I'm really happy with the progress that has been made. > > Another priority we had identified for Mitaka was active/active high > availability of the c-vol service. We were not able to complete that work, but > many pieces have been put in place to support that in Newton. We fixed several > API races and added the ability to use something like tooz for locking. These > are foundation pieces for us to be able to start breaking out things and > running in a reliable active/active configuration. > > Microversion support has been added and there is now a new v3 API endpoint. > This was a bit of a controversy as we really had just started to get folks to > move off of v1 to v2. To be safe though I decided it would protect end users > better to have a clearly separate new API endpoint for the microversion > compatibility. And now hopefully it is our last. > > Replication was another slightly controversial feature implemented. Late in > Liberty we finally agreed on a spec for a v2 version of replication. The v2 > spec was approved so late that no one actually had time to implement it for > that release. As we started to implement it for Mitaka we found that a lot of > compromises had crept in during the spec review that it had the risk of being > too complex and having some of the issues we were trying to get rid of by > moving away from replication v1. At our midcycle we had a lot of discussion on > replication and finally decided to change course before it was too late. > Whether that ends up being the best choice when we look back a year from now > or > not, I'm proud of the team that we were willing to put on the brakes and make > changes - even though it was more work for us - before we released something > out to end users that would have caused problems or a poor experience. > > Other than that, there's mostly been a lot of good bug fixes. Eight new > drivers > have been added from (I think) five different vendors. The os-brick library is > now 1.0 (actually 1.1.0) and is in use by both Cinder and Nova for common > storage management operations so there is not a duplication and disconnect of > code between the two projects. We were also able to add a Brick cinder client > extension to be able to perform storage management on nodes without Nova (bare > metal, etc.). > > None of this goodness was from me. > > We have a bunch of smart and active members of the Cinder community. They are > the ones that are making a difference, working across the community, and > making sure Cinder is a solid component in an OpenStack cloud. > > Being part of the Cinder community has been one of the best and most engaging > parts of my career. I am lucky enough to have support from my company to be > able to devote time to being a part of this. I would love the opportunity to > continue as PTL to not just contribute where I can, but to make sure the folks > doing the heavy lifting have the support and project organization they need to > avoid distractions and be able to focus on getting the important stuff done. > > I think in Newton we need to continue the momentum and get Active/Active > Cinder > volume service support implemented. We need to continue to work closely with > the Nova team to make sure our interaction is correct and solid. But also work > to make Cinder a useful storage management interface in environments without > Nova. I will continue to encourage developer involvement and vendor support. > We need to improve the user experience with better error reporting when things > go wrong. And last, but definitely not least, we need to continue to expand > our > testing - unit, functional, and tempest - to make sure we can avoid those > errors and deliver a high quality and solid solution. > > I really feel I'm just getting into the swing of things. I would love the > opportunity to serve as PTL for the Newton release. > > Thank you for your consideration. > > Sean McGinnis (smcginnis) > > > __ > 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] [Cinder] PTL Candidacy
Hey everyone, Wow, how six months flies! I'd like to announce my candidacy to continue on as Cinder PTL for the Newton release cycle. A lot has been accomplished in the Mitaka cycle. After a lot of work by many folks, over a couple development cycles, we now have what we consider a "tech preview" of rolling upgrades. It just hasn't had enough runtime and testing for us to say it's "official". We will likely need to fix a few minor things in the Newton timeframe before it's fully baked and reliable. But it has come a long way and I'm really happy with the progress that has been made. Another priority we had identified for Mitaka was active/active high availability of the c-vol service. We were not able to complete that work, but many pieces have been put in place to support that in Newton. We fixed several API races and added the ability to use something like tooz for locking. These are foundation pieces for us to be able to start breaking out things and running in a reliable active/active configuration. Microversion support has been added and there is now a new v3 API endpoint. This was a bit of a controversy as we really had just started to get folks to move off of v1 to v2. To be safe though I decided it would protect end users better to have a clearly separate new API endpoint for the microversion compatibility. And now hopefully it is our last. Replication was another slightly controversial feature implemented. Late in Liberty we finally agreed on a spec for a v2 version of replication. The v2 spec was approved so late that no one actually had time to implement it for that release. As we started to implement it for Mitaka we found that a lot of compromises had crept in during the spec review that it had the risk of being too complex and having some of the issues we were trying to get rid of by moving away from replication v1. At our midcycle we had a lot of discussion on replication and finally decided to change course before it was too late. Whether that ends up being the best choice when we look back a year from now or not, I'm proud of the team that we were willing to put on the brakes and make changes - even though it was more work for us - before we released something out to end users that would have caused problems or a poor experience. Other than that, there's mostly been a lot of good bug fixes. Eight new drivers have been added from (I think) five different vendors. The os-brick library is now 1.0 (actually 1.1.0) and is in use by both Cinder and Nova for common storage management operations so there is not a duplication and disconnect of code between the two projects. We were also able to add a Brick cinder client extension to be able to perform storage management on nodes without Nova (bare metal, etc.). None of this goodness was from me. We have a bunch of smart and active members of the Cinder community. They are the ones that are making a difference, working across the community, and making sure Cinder is a solid component in an OpenStack cloud. Being part of the Cinder community has been one of the best and most engaging parts of my career. I am lucky enough to have support from my company to be able to devote time to being a part of this. I would love the opportunity to continue as PTL to not just contribute where I can, but to make sure the folks doing the heavy lifting have the support and project organization they need to avoid distractions and be able to focus on getting the important stuff done. I think in Newton we need to continue the momentum and get Active/Active Cinder volume service support implemented. We need to continue to work closely with the Nova team to make sure our interaction is correct and solid. But also work to make Cinder a useful storage management interface in environments without Nova. I will continue to encourage developer involvement and vendor support. We need to improve the user experience with better error reporting when things go wrong. And last, but definitely not least, we need to continue to expand our testing - unit, functional, and tempest - to make sure we can avoid those errors and deliver a high quality and solid solution. I really feel I'm just getting into the swing of things. I would love the opportunity to serve as PTL for the Newton release. Thank you for your consideration. Sean McGinnis (smcginnis) __ 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] [Cinder] PTL Candidacy
Hello everyone, I'm announcing my candidacy for Cinder PTL for the Mitaka release. First of all, I would like to thank John and Mike for their great and hard work making Cinder such a great project with good and a big community. As a Cinder community we made a great progress not only with new features, but with improving Cinder quality too. Our community grows quickly and we are glad to see new contributors again and again. I've started work with OpenStack since Diablo release. I’ve been an active contributor to Cinder since Juno cycle [1]. As a Cinder PTL I would like to focus on the following areas of improvements for the next release cycle: * Finally move all projects to Cinder API v2 and prepare to remove v1 API. * Better Cinder integration with other OpenStack projects like Nova and Ironic, support Keystone API v3. * Continue to work on Cinder backups improvements like: scaling, performance, etc. * Work with driver vendors to stabilize third party CI. I believe, every PTL candidate will have this item on the list. * Improve Cinder test coverage and quality: we need to get functional tests, better Tempest and Rally coverage, make our unit tests better We need to continue to be open for developers community and operators needs. Improving quality and growing the community are the tasks which should be done indefinitely. But we need to keep balance between new features development and support of existing ones by all drivers and stability of Cinder project. [1] http://stackalytics.com/report/contribution/cinder/180 Thank you, Ivan Kolodyazhny (e0ne) __ 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] [Cinder] PTL Candidacy
Cinder community, I am announcing my candidacy for Cinder PTL for the Mitaka release. Cinder is a fundamental piece of the puzzle for the success of OpenStack. I've been lucky enough to work on Cinder since the Grizzly release cycle. The Cinder community has grown every release, and we've gotten a lot of great features implemented as well as many new drivers. We've instituted a baseline requirement for third party CI, which is critical to the quality of Cinder. I believe this goes a long way to proving to deployers that Cinder is dedicated to building a quality product. I believe the single best component of the project, is the diverse community itself. We have people from all over the world helping Cinder grow. We have companies that compete directly with each other, in the marketplace for customers, working together to solve complex problems. I would like to continue to encourage more driver developers to get involved in Cinder core features. This is the future of the community itself and the lifeblood of Cinder. We also need to get more active in Nova to ensure that the interactions are stable. The following is a list of a few areas of focus that I would like to encourage the community to consider over the next release. * Solidify all/any deadlines milestone deadlines early in the release * Iron out the Nova <--> Cinder interactions * Get active-active c-vol services working * Get driver bug fixes into previous releases * Continue the stabilization of the 3rd party CI system. * Support any efforts to integrate with Ironic There is always a long list of cool stuff to work on and issues to fix in Cinder, and the more participation we have with Cinder core the better. We have a strong and vibrant community and I look forward to working on Cinder for many releases ahead. Thank you for considering me. Walter A. Boring IV (hemna) __ 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] [Cinder] PTL Candidacy
Hi I'd like to announce my candidacy for Cinder PTL. I've been actively involved in Cinder as a core since it was split out of Nova, and with nova-volume before that. I've been involved in mentoring new people, reviews, code and community discussions all of that time. I've been an operator of Cinder in a large public cloud, including being called out at 4am when something breaks, giving me a great deal of sympathy for operational matters. Cinder has grown and matured at an impressive rate, and I now feel the project is at an important decision point about what we want to be going forward. With that in mind, my main aims as a PTL would be as follows: - Make the ideology of Cinder - standard features, good discoverability where universal implementation of a feature isn;t possible, and keeping the tenant experience as clean as possible - the admin experience should be as clean as possible without compromising the tenant experience. - Matching our bleeding edge velocity with our trailing edge velocity - we merged a bunch of features that only work in a very, very limited number of drivers. We need to push implementation of these features as widely as possible, and where a reasonable generic implementation can be made then we need to push that as a requirement for adding the feature. - Stability and quality - our unit test test coverage has not improved significantly in terms of lines of code or quality of tests, and our tempest coverage has got worse. I suggest that we push for more tempest tests to go with new features. The reliability and usability of third party CI can also be incrementally improved - we've got nearly every driver being tested now, lets make the test output more useful to developers. - Communication - Mike demonstrated the great value of clear, regular and open communication and I intend to keep building on this example - Less bureaucracy that gets in the way - I think that the way we did prioritisation in Liberty, while a good first attempt, can be improved, particularly with dropping the review priority of tasks that are blocked waiting for rework, so that more smaller patches can bubble up the priority list. I'd also like to look at using review priority to encourage good community behaviour (reviews of other people's code, bug fixes and triage, test writing, documentation, etc) - Finishing open work before starting more work - we have a large list of part-implemented tasks, so we should avoiding taking on new work that doesn't drive these goals forward. The things I'd like to see finished in the M release: - Replication. At least 5 drivers implementing it. - Smooth upgrade experience - even if we can't get it to zero downtime, I'd like a well documented, tested upgrade path and a well understood list of work to be finished.. - H/A - I believe we can have and should have a cinder experience where the failure of any one node does not affect the externals of cinder, without requiring pacemaker. Thank you for your consideration. -- 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
Re: [openstack-dev] [Cinder] PTL Candidacy
Voting is done by formal ballot just before the summit. All Cinder ATCs will be invited to vote. Voting on the mailing list is just noise. On 15 September 2015 at 23:40, Nikesh Kumar Mahalka < nikeshmaha...@vedams.com> wrote: > Thanks Sean, Vote +1. > > On Tue, Sep 15, 2015 at 8:36 AM, hao wang wrote: > >> Thanks Sean, Vote +1. >> >> 2015-09-14 22:49 GMT+08:00 Sean McGinnis : >> > Hello everyone, >> > >> > I'm announcing my candidacy for Cinder PTL for the Mitaka release. >> > >> > The Cinder team has made great progress. We've not only grown the >> > number of supported backend drivers, but we've made significant >> > improvements to the core code and raised the quality of existing >> > and incoming code contributions. While there are still many things >> > that need more polish, we are headed in the right direction and >> > block storage is a strong, stable component to many OpenStack clouds. >> > >> > Mike and John have provided the leadership to get the project where >> > it is today. I would like to keep that momentum going. >> > >> > I've spent over a decade finding new and interesting ways to create >> > and delete volumes. I also work across many different product teams >> > and have had a lot of experience collaborating with groups to find >> > a balance between the work being done to best benefit all involved. >> > >> > I think I can use this experience to foster collaboration both within >> > the Cinder team as well as between Cinder and other related projects >> > that interact with storage services. >> > >> > Some topics I would like to see focused on for the Mitaka release >> > would be: >> > >> > * Complete work of making the Cinder code Python3 compatible. >> > * Complete conversion to objects. >> > * Sort out object inheritance and appropriate use of ABC. >> > * Continued stabilization of third party CI. >> > * Make sure there is a good core feature set regardless of backend >> type. >> > * Reevaluate our deadlines to make sure core feature work gets enough >> >time and allows drivers to implement support. >> > >> > While there are some things I think we need to do to move the project >> > forward, I am mostly open to the needs of the community as a whole >> > and making sure that what we are doing is benefiting OpenStack and >> > making it a simpler, easy to use, and ubiquitous platform for the >> > cloud. >> > >> > Thank you for your consideration! >> > >> > Sean McGinnis (smcginnis) >> > >> > >> __ >> > 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 >> >> >> >> -- >> Best Wishes For You! >> >> __ >> 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 > > -- -- 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
Re: [openstack-dev] [Cinder] PTL Candidacy
Thanks Sean, Vote +1. On Tue, Sep 15, 2015 at 8:36 AM, hao wang wrote: > Thanks Sean, Vote +1. > > 2015-09-14 22:49 GMT+08:00 Sean McGinnis : > > Hello everyone, > > > > I'm announcing my candidacy for Cinder PTL for the Mitaka release. > > > > The Cinder team has made great progress. We've not only grown the > > number of supported backend drivers, but we've made significant > > improvements to the core code and raised the quality of existing > > and incoming code contributions. While there are still many things > > that need more polish, we are headed in the right direction and > > block storage is a strong, stable component to many OpenStack clouds. > > > > Mike and John have provided the leadership to get the project where > > it is today. I would like to keep that momentum going. > > > > I've spent over a decade finding new and interesting ways to create > > and delete volumes. I also work across many different product teams > > and have had a lot of experience collaborating with groups to find > > a balance between the work being done to best benefit all involved. > > > > I think I can use this experience to foster collaboration both within > > the Cinder team as well as between Cinder and other related projects > > that interact with storage services. > > > > Some topics I would like to see focused on for the Mitaka release > > would be: > > > > * Complete work of making the Cinder code Python3 compatible. > > * Complete conversion to objects. > > * Sort out object inheritance and appropriate use of ABC. > > * Continued stabilization of third party CI. > > * Make sure there is a good core feature set regardless of backend type. > > * Reevaluate our deadlines to make sure core feature work gets enough > >time and allows drivers to implement support. > > > > While there are some things I think we need to do to move the project > > forward, I am mostly open to the needs of the community as a whole > > and making sure that what we are doing is benefiting OpenStack and > > making it a simpler, easy to use, and ubiquitous platform for the > > cloud. > > > > Thank you for your consideration! > > > > Sean McGinnis (smcginnis) > > > > > __ > > 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 > > > > -- > Best Wishes For You! > > __ > 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] [Cinder] PTL Candidacy
Thanks Sean, Vote +1. 2015-09-14 22:49 GMT+08:00 Sean McGinnis : > Hello everyone, > > I'm announcing my candidacy for Cinder PTL for the Mitaka release. > > The Cinder team has made great progress. We've not only grown the > number of supported backend drivers, but we've made significant > improvements to the core code and raised the quality of existing > and incoming code contributions. While there are still many things > that need more polish, we are headed in the right direction and > block storage is a strong, stable component to many OpenStack clouds. > > Mike and John have provided the leadership to get the project where > it is today. I would like to keep that momentum going. > > I've spent over a decade finding new and interesting ways to create > and delete volumes. I also work across many different product teams > and have had a lot of experience collaborating with groups to find > a balance between the work being done to best benefit all involved. > > I think I can use this experience to foster collaboration both within > the Cinder team as well as between Cinder and other related projects > that interact with storage services. > > Some topics I would like to see focused on for the Mitaka release > would be: > > * Complete work of making the Cinder code Python3 compatible. > * Complete conversion to objects. > * Sort out object inheritance and appropriate use of ABC. > * Continued stabilization of third party CI. > * Make sure there is a good core feature set regardless of backend type. > * Reevaluate our deadlines to make sure core feature work gets enough >time and allows drivers to implement support. > > While there are some things I think we need to do to move the project > forward, I am mostly open to the needs of the community as a whole > and making sure that what we are doing is benefiting OpenStack and > making it a simpler, easy to use, and ubiquitous platform for the > cloud. > > Thank you for your consideration! > > Sean McGinnis (smcginnis) > > __ > 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 -- Best Wishes For You! __ 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] [Cinder] PTL Candidacy
Hello everyone, I'm announcing my candidacy for Cinder PTL for the Mitaka release. The Cinder team has made great progress. We've not only grown the number of supported backend drivers, but we've made significant improvements to the core code and raised the quality of existing and incoming code contributions. While there are still many things that need more polish, we are headed in the right direction and block storage is a strong, stable component to many OpenStack clouds. Mike and John have provided the leadership to get the project where it is today. I would like to keep that momentum going. I've spent over a decade finding new and interesting ways to create and delete volumes. I also work across many different product teams and have had a lot of experience collaborating with groups to find a balance between the work being done to best benefit all involved. I think I can use this experience to foster collaboration both within the Cinder team as well as between Cinder and other related projects that interact with storage services. Some topics I would like to see focused on for the Mitaka release would be: * Complete work of making the Cinder code Python3 compatible. * Complete conversion to objects. * Sort out object inheritance and appropriate use of ABC. * Continued stabilization of third party CI. * Make sure there is a good core feature set regardless of backend type. * Reevaluate our deadlines to make sure core feature work gets enough time and allows drivers to implement support. While there are some things I think we need to do to move the project forward, I am mostly open to the needs of the community as a whole and making sure that what we are doing is benefiting OpenStack and making it a simpler, easy to use, and ubiquitous platform for the cloud. Thank you for your consideration! Sean McGinnis (smcginnis) __ 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] [Cinder] PTL Candidacy
confirmed On 04/02/2015 02:46 PM, Mike Perez wrote: > Hello all, > > I'm announcing my candidacy for Cinder PTL for the Liberty release. > > I have contributed to block storage in OpenStack since Bexar back when things > were within nova-volume, before Cinder, and the honor of serving as PTL for > Cinder in the Kilo cycle. > > I've spoke in the past about focused participation, something I still feel is > needed in the projects that are the basic foundation of OpenStack. Compute, > storage and networking need to be solid. My work as core in Cinder and > continuing as PTL has involved a lot of evangelizing and making new > contributors feel comfortable with becoming part of the team. As a project > grows, communication needs to be excellent, coordination is key to making sure > reviews don't stick around too long for contributors to feel discouraged. > I think the Cinder team has done an excellent job in managing this as we grow, > based on the feedback received. I really do think participation in Cinder > is getting better, and it's wonderful to be part of that. > > If we take the Kilo-3 milestone for example, we landed 44 blueprints in > a single milestone [1]. That's huge progress. I would like to believe this > happens because of focus, and that happens because of better tracking of what > is a priority and clear communication. Lastly participation, not just core > folks, but any contributor that feels welcomed by the team and not to be burnt > out on never ending patch revisions. > > Most of 2014 in Cinder was a lot of discussions on third party CI's. Third > party CI's are a great way for vendors to verify if a proposed upstream patch > would break their integration. In addition, it identifies if a vendor really > does work with the current state of the OpenStack project. There have been > plenty of cases that vendors discovered that their integration in OpenStack > really didn't work until they ran these tests. Last year, there was a real > lack > of coordination and communication with vendors on getting them on board with > reporting third party CI results. In 2015 I took on the responsibility of > being > the point of contact for the 70+ drivers in Cinder, emailing the mailing list, > countless reminders on IRC, contacting maintainers directly, and actually > making phone calls to companies if maintainers were not responsive by email. > > I'm happy to report that majority of vendors have responded back and are > active > in the Cinder community to ensure their integration is solid. Compare that to > last year when we just had one or two vendors reporting and majority of > vendors > not having a clue! It's very exciting to help build a better experience for > their users using OpenStack. The communities pouring support to me on this > issue was hugely appreciated, and is what keeps me coming back to help. > > We added 14 new drivers to Cinder in the Kilo release. Coordination was > beautiful thanks to clear communication and coordination with the hard working > reviewers in the Cinder team. > > My priorities for Cinder in the Kilo release was to make progress on rolling > upgrades. I have spent a greater deal of my time testing the work to allow > Cinder services to not be dependent on database schemas. This is a big change, > and doesn't completely solve rolling upgrades in Cinder, but is a building > block needed to begin solving the other rolling upgrade problems. I'm really > happy with the work done by the team in the Kilo release and excited with how > comfortable I feel in terms of stability of the work thanks to the amount of > testing we've done. > > This work however not only benefits Cinder, but is a general solution into > Oslo, in attempt to help other OpenStack projects in upgrades. Upgrades are > a huge problem that needs to be solved across OpenStack, and I'm proud of the > Cinder team for helping do their part to help drive adoption. Long term I see > this work contributing to an ideal single upgrade solution, so that operators > aren't having to learn how to upgrade 12 different services they may deploy. > > My plans for Liberty is to work with the team on creating a better use of > milestones for appropriate changes. While we started some initial requirements > like making new drivers focus on the first milestone only, I think stability > time needs to be stretched a bit longer, and I think others will agree Kilo > didn't have a lot of this as planned for Kilo-3. > > Cinder will continue on efforts for rolling upgrades by now focusing on > compatibility across Cinder services with RPC. This is a very important piece > for making rolling upgrades complete. We will continue to work through > projects > like Oslo to make sure these solutions general enough to benefit other > OpenStack projects, so as a whole, we will improve together. > > Cinder volumes that end up in a stuck state. This has been a problem for ages, > and I have heard from countless people at the O
[openstack-dev] [Cinder] PTL Candidacy
Hello all, I'm announcing my candidacy for Cinder PTL for the Liberty release. I have contributed to block storage in OpenStack since Bexar back when things were within nova-volume, before Cinder, and the honor of serving as PTL for Cinder in the Kilo cycle. I've spoke in the past about focused participation, something I still feel is needed in the projects that are the basic foundation of OpenStack. Compute, storage and networking need to be solid. My work as core in Cinder and continuing as PTL has involved a lot of evangelizing and making new contributors feel comfortable with becoming part of the team. As a project grows, communication needs to be excellent, coordination is key to making sure reviews don't stick around too long for contributors to feel discouraged. I think the Cinder team has done an excellent job in managing this as we grow, based on the feedback received. I really do think participation in Cinder is getting better, and it's wonderful to be part of that. If we take the Kilo-3 milestone for example, we landed 44 blueprints in a single milestone [1]. That's huge progress. I would like to believe this happens because of focus, and that happens because of better tracking of what is a priority and clear communication. Lastly participation, not just core folks, but any contributor that feels welcomed by the team and not to be burnt out on never ending patch revisions. Most of 2014 in Cinder was a lot of discussions on third party CI's. Third party CI's are a great way for vendors to verify if a proposed upstream patch would break their integration. In addition, it identifies if a vendor really does work with the current state of the OpenStack project. There have been plenty of cases that vendors discovered that their integration in OpenStack really didn't work until they ran these tests. Last year, there was a real lack of coordination and communication with vendors on getting them on board with reporting third party CI results. In 2015 I took on the responsibility of being the point of contact for the 70+ drivers in Cinder, emailing the mailing list, countless reminders on IRC, contacting maintainers directly, and actually making phone calls to companies if maintainers were not responsive by email. I'm happy to report that majority of vendors have responded back and are active in the Cinder community to ensure their integration is solid. Compare that to last year when we just had one or two vendors reporting and majority of vendors not having a clue! It's very exciting to help build a better experience for their users using OpenStack. The communities pouring support to me on this issue was hugely appreciated, and is what keeps me coming back to help. We added 14 new drivers to Cinder in the Kilo release. Coordination was beautiful thanks to clear communication and coordination with the hard working reviewers in the Cinder team. My priorities for Cinder in the Kilo release was to make progress on rolling upgrades. I have spent a greater deal of my time testing the work to allow Cinder services to not be dependent on database schemas. This is a big change, and doesn't completely solve rolling upgrades in Cinder, but is a building block needed to begin solving the other rolling upgrade problems. I'm really happy with the work done by the team in the Kilo release and excited with how comfortable I feel in terms of stability of the work thanks to the amount of testing we've done. This work however not only benefits Cinder, but is a general solution into Oslo, in attempt to help other OpenStack projects in upgrades. Upgrades are a huge problem that needs to be solved across OpenStack, and I'm proud of the Cinder team for helping do their part to help drive adoption. Long term I see this work contributing to an ideal single upgrade solution, so that operators aren't having to learn how to upgrade 12 different services they may deploy. My plans for Liberty is to work with the team on creating a better use of milestones for appropriate changes. While we started some initial requirements like making new drivers focus on the first milestone only, I think stability time needs to be stretched a bit longer, and I think others will agree Kilo didn't have a lot of this as planned for Kilo-3. Cinder will continue on efforts for rolling upgrades by now focusing on compatibility across Cinder services with RPC. This is a very important piece for making rolling upgrades complete. We will continue to work through projects like Oslo to make sure these solutions general enough to benefit other OpenStack projects, so as a whole, we will improve together. Cinder volumes that end up in a stuck state. This has been a problem for ages, and I have heard from countless people at the Ops Midcycle Meetup that I attended. I'm happy to say, as reported from my take on the Ops Midcycle meetup [2], that this was something the Cinder team discussed at the Cinder Midcycle Meetup this year and we will be working on
Re: [openstack-dev] [cinder] PTL Candidacy
confirmed On 23/09/14 10:19 AM, Duncan Thomas wrote: > This is an announcement of my standing for PTL of the Cinder project. > > I've been an active member of the Cinder core team from day one, and > I've had the pleasure of working closely with John Griffith, the > incumbent PTL, and a large and varied collection of contributors for > that period. > > My job is running block storage in HP's public cloud, as well as > working on our private cloud offering. This has give me a strong > emphasis on the day to day operational aspects of running Cinder at > scale, backward compatibility and the challenges of continuous > deployment of head-of-tree code in production. > > I think Cinder is a project reaching technical maturity; it has a > strong team behind it, both core and non-core. We work well together, > and I see the main role of the PTL not as making decisions but in > enabling this community to progress as smoothly as possible. I've had > a great deal of success in driving forward the 3rd party CI > requirements, working with the infra team to work out process and > where necessary giving engineers the tools and leverage they need to > overcome roadblocks within their own companies. I feel that some > gentle shepherding in terms of review focus can help us increase our > velocity without disrupting the very successful way of working we > currently have. > > The hugely successful mid-cycle meetup set the main goal of the Kilo > cycle as stability and paying down technical debt, and there are a > number of pieces of work started by myself and others that should > produce significant dividends in that area - state machine, cinder > agent, decoupling of drivers and connector types. > > I have always encouraged anybody to reach out to me with questions and > concerns, and continue to do so. I look forward to continuing the > great work we've been doing. > > > Regards > signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] PTL Candidacy
This is an announcement of my standing for PTL of the Cinder project. I've been an active member of the Cinder core team from day one, and I've had the pleasure of working closely with John Griffith, the incumbent PTL, and a large and varied collection of contributors for that period. My job is running block storage in HP's public cloud, as well as working on our private cloud offering. This has give me a strong emphasis on the day to day operational aspects of running Cinder at scale, backward compatibility and the challenges of continuous deployment of head-of-tree code in production. I think Cinder is a project reaching technical maturity; it has a strong team behind it, both core and non-core. We work well together, and I see the main role of the PTL not as making decisions but in enabling this community to progress as smoothly as possible. I've had a great deal of success in driving forward the 3rd party CI requirements, working with the infra team to work out process and where necessary giving engineers the tools and leverage they need to overcome roadblocks within their own companies. I feel that some gentle shepherding in terms of review focus can help us increase our velocity without disrupting the very successful way of working we currently have. The hugely successful mid-cycle meetup set the main goal of the Kilo cycle as stability and paying down technical debt, and there are a number of pieces of work started by myself and others that should produce significant dividends in that area - state machine, cinder agent, decoupling of drivers and connector types. I have always encouraged anybody to reach out to me with questions and concerns, and continue to do so. I look forward to continuing the great work we've been doing. Regards -- Duncan Thomas Cinder Core, and HP Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] PTL Candidacy
confirmed On 23/09/14 12:58 AM, Mike Perez wrote: > Hello all, > > My name is Mike Perez, and I would like to be your next PTL for the OpenStack > block storage project Cinder. > > I've been involved with the OpenStack community since October 2010. I'm > a senior developer for Datera, which contributes to Linux Bcache and the > Linux-IO SCSI Target (LIO) in the Linux kernel (which some Cinder setups use > underneath for target management). Before that I was for seven years a senior > developer for DreamHost, working on their core products and storage in their > OpenStack public cloud. > > Since November 2012 I've been a core developer for Cinder. Besides code > reviews, my main contributions include creating the v2 API, writing the v2 API > reference and spec docs and rewriting the v1 api docs. These are contributions > that I feel were well thought out and complete. This is exactly how I > would like to see the future of Cinder's additional contributions and would > like to lead the team in that direction. > > Over the years I've advocated for OpenStack [1][2][3][4] and its community to > bring in more contributors by teaching the basics of Cinder's design, which > then can be applied to a project a potential contributor is interested in. > I also contribute to programs such as the Women Who Code event [5][6] to help > get future OpenStack interns in the Gnome Outreach Program excited to help the > project. I feel, as a leader, helping to build a healthy diverse community is > key. > > I would like to continue to help the Cinder team with focusing on what the > bigger picture is. Not letting us get lost in long discussion, but come to > a consensus sooner and start making better progress now. Some of this includes > better organizing of the blueprints and better triaging of bugs so > contributors > can use tools more effectively [7]. I would also like to guide folks with > their > ideas early on as something that fits with the project or not. > > For the Kilo release, a lot of features have a dependency on a state machine. > I agree with the rest of Cinder contributors, this needs to happen now so > that we can can progress forward. I have a summit session with an approach as > discussed in the previous Cinder Mid-cycle meet up [8] to drive this important > change forward. Lastly, rolling upgrades is being picked back up, and I will > be > showing interest in reviews and discussion with helping the contributors focus > to bring this wonderful feature forward. These are the only changes I'm > mentioning as I'm sure we'll need bandwidth for other necessary features that > contributors will be bringing in. > > I'm looking forward to continuing to grow, and the opportunity to contribute > to > this project in new ways. > > Thanks, > Mike Perez > > [1] - http://www.meetup.com/OpenStack-Northwest/events/151114422 > [2] - http://www.meetup.com/meetup-group-NjZdcegA/events/150630962 > [3] - http://www.meetup.com/OpenStack-Seattle/events/159943872 > [4] - http://www.meetup.com/openstack/events/150932582/ > [5] - http://www.meetup.com/Women-Who-Code-SF/events/195850392/ > [6] - http://www.meetup.com/Women-Who-Code-SF/events/195850922/ > [7] - http://status.openstack.org/reviews/ > [8] - https://etherpad.openstack.org/p/cinder-meetup-summer-2014 > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] PTL Candidacy
Hello all, My name is Mike Perez, and I would like to be your next PTL for the OpenStack block storage project Cinder. I've been involved with the OpenStack community since October 2010. I'm a senior developer for Datera, which contributes to Linux Bcache and the Linux-IO SCSI Target (LIO) in the Linux kernel (which some Cinder setups use underneath for target management). Before that I was for seven years a senior developer for DreamHost, working on their core products and storage in their OpenStack public cloud. Since November 2012 I've been a core developer for Cinder. Besides code reviews, my main contributions include creating the v2 API, writing the v2 API reference and spec docs and rewriting the v1 api docs. These are contributions that I feel were well thought out and complete. This is exactly how I would like to see the future of Cinder's additional contributions and would like to lead the team in that direction. Over the years I've advocated for OpenStack [1][2][3][4] and its community to bring in more contributors by teaching the basics of Cinder's design, which then can be applied to a project a potential contributor is interested in. I also contribute to programs such as the Women Who Code event [5][6] to help get future OpenStack interns in the Gnome Outreach Program excited to help the project. I feel, as a leader, helping to build a healthy diverse community is key. I would like to continue to help the Cinder team with focusing on what the bigger picture is. Not letting us get lost in long discussion, but come to a consensus sooner and start making better progress now. Some of this includes better organizing of the blueprints and better triaging of bugs so contributors can use tools more effectively [7]. I would also like to guide folks with their ideas early on as something that fits with the project or not. For the Kilo release, a lot of features have a dependency on a state machine. I agree with the rest of Cinder contributors, this needs to happen now so that we can can progress forward. I have a summit session with an approach as discussed in the previous Cinder Mid-cycle meet up [8] to drive this important change forward. Lastly, rolling upgrades is being picked back up, and I will be showing interest in reviews and discussion with helping the contributors focus to bring this wonderful feature forward. These are the only changes I'm mentioning as I'm sure we'll need bandwidth for other necessary features that contributors will be bringing in. I'm looking forward to continuing to grow, and the opportunity to contribute to this project in new ways. Thanks, Mike Perez [1] - http://www.meetup.com/OpenStack-Northwest/events/151114422 [2] - http://www.meetup.com/meetup-group-NjZdcegA/events/150630962 [3] - http://www.meetup.com/OpenStack-Seattle/events/159943872 [4] - http://www.meetup.com/openstack/events/150932582/ [5] - http://www.meetup.com/Women-Who-Code-SF/events/195850392/ [6] - http://www.meetup.com/Women-Who-Code-SF/events/195850922/ [7] - http://status.openstack.org/reviews/ [8] - https://etherpad.openstack.org/p/cinder-meetup-summer-2014 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] PTL Candidacy
confirmed On 04/03/2014 12:19 PM, Mike Perez wrote: > Hello all, > > My name is Mike Perez, and I would like to be your next PTL for the OpenStack > block storage project Cinder. > > I've been involved with the OpenStack community since October 2010. I'm > a senior developer for Datera which contributes to Linux Bcache and the > Linux-IO SCSI Target (LIO) in the kernel. Before that I was for seven years > a senior developer for DreamHost, working on their core products and storage > in > their OpenStack public cloud. > > Since November 2012 I've been a core developer for Cinder. Besides code > reviews, my main contributions include creating the v2 API, writing the v2 API > reference and spec docs and rewriting the v1 api docs. These are contributions > that I feel were were well thought out and complete. This is exactly how I > would like to see the future of Cinder's additional contributions and would > like to lead the team that direction. > > Instead of listing out the technical things that need to be improved in > Cinder, > I would like to just talk about the things as PTL I would improve, which as > a side effect will allow the team to focus better on those technical issues. > > Cinder is a small but a very effective team. Just like other projects, we need > more contributors to handle the requirements we get daily. First impressions > with contributors who are very excited to make their name in OpenStack can be > better helped by simple outreach in how they can be more effective with the > team. Guiding those contributors on what are the goals, and spending a little > time with them on how their interests can help those goals can go a long > way. Currently I feel like potential long term contributors are discouraged in > the time that they spend on evaluating what they could improve and to later > find out that their proposed improvements don't fit the project plans. > > Focus itself can help contributors be effective in what's important. With the > support of the community, I would like to raise better guidelines on when > certain contributions are appropriate. With these community agreed guidelines, > it should be clearer on what is appropriate for review and what can be pushed > to the next release. With a better focus we can allow more time for features > to > be more complete as mentioned earlier. Being complete means having confidence > something works. This can be ensured by trying changes before merge when > possible and not relying on tests alone, having performance results, and > actually having documentation so people know how to use new features. Release > notes are not enough to figure out new Cinder features. > > I want to help the team realize more they can do in Cinder. I don't want to be > a single person people rely on in the project, but rather have this team help > me carry this project forward. > > Thank you, > Mike Perez > > ___ > 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] [Cinder] PTL Candidacy
Hello all, My name is Mike Perez, and I would like to be your next PTL for the OpenStack block storage project Cinder. I've been involved with the OpenStack community since October 2010. I'm a senior developer for Datera which contributes to Linux Bcache and the Linux-IO SCSI Target (LIO) in the kernel. Before that I was for seven years a senior developer for DreamHost, working on their core products and storage in their OpenStack public cloud. Since November 2012 I've been a core developer for Cinder. Besides code reviews, my main contributions include creating the v2 API, writing the v2 API reference and spec docs and rewriting the v1 api docs. These are contributions that I feel were were well thought out and complete. This is exactly how I would like to see the future of Cinder's additional contributions and would like to lead the team that direction. Instead of listing out the technical things that need to be improved in Cinder, I would like to just talk about the things as PTL I would improve, which as a side effect will allow the team to focus better on those technical issues. Cinder is a small but a very effective team. Just like other projects, we need more contributors to handle the requirements we get daily. First impressions with contributors who are very excited to make their name in OpenStack can be better helped by simple outreach in how they can be more effective with the team. Guiding those contributors on what are the goals, and spending a little time with them on how their interests can help those goals can go a long way. Currently I feel like potential long term contributors are discouraged in the time that they spend on evaluating what they could improve and to later find out that their proposed improvements don't fit the project plans. Focus itself can help contributors be effective in what's important. With the support of the community, I would like to raise better guidelines on when certain contributions are appropriate. With these community agreed guidelines, it should be clearer on what is appropriate for review and what can be pushed to the next release. With a better focus we can allow more time for features to be more complete as mentioned earlier. Being complete means having confidence something works. This can be ensured by trying changes before merge when possible and not relying on tests alone, having performance results, and actually having documentation so people know how to use new features. Release notes are not enough to figure out new Cinder features. I want to help the team realize more they can do in Cinder. I don't want to be a single person people rely on in the project, but rather have this team help me carry this project forward. Thank you, Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] Cinder PTL Candidacy
confirmed On 04/01/2014 03:02 PM, John Griffith wrote: > I'd like to announce my candidacy for the Block Storage (Cinder) PTL > position. > > I've been involved with OpenStack for about two and a half years now, > starting out by trying to help with some things in Nova-Volumes and then > with the help of a lot of great folks creating Cinder. I have been the > unofficial and official PTL for Cinder since its beginning, and I've been > pretty passionate about the project, it's goals and it's evolution the > entire time. > > There are a lot of different views about what a PTL "does", some > candidacies point out that it's not technical, others talk about delegation > and management. I think that every project is different, and a lot of the > responsibility comes down to what sort of dedicated team of contributors > you have working on the project. The role of PTL has requirements that are > well defined in item [1]. In addition however I think it's > the responsibility to step in and fill in the gaps if and when needed. > This could be spending late nights debugging issues that slipped in to the > gate and wreak havoc on our process, or picking up the bugs that nobody > else wants to work on. In my opinion the PTL is not only a Project Manager > and an Ambassador, but he or she is also a sort of pinch hitter on the > technical side. > > Cinder has come a long way over the past year, not only the project, but > the team itself. The maturity and growth of the project is visible from > the diverse group of dedicated folks we now have working on the project on > a regular basis. We have greatly increased our number of reviewers as well > as contributors and while it's sometimes challenging we've maintained our > stance on API compatibility and feature implementation requirements for > all drivers. The review and contribution stats(here [2] and here [3]) are > a clear indication that the project is actively growing and the work-load > is becoming more and more evenly distributed. I personally think Cinder is > on the right track and the current direction is the right one to continue > on. > > All of that being said, there are still significant challenges ahead; the > top items I see for the Juno release: > * Maintaining driver compatibility > We've always taken a hard stance on requiring all submitted drivers to meet > a base set of requirements, this is extremely important for end users to > ensure the promise of OpenStack is realized. It's rather difficult to pool > multiple block storage resources into a single virtual resource if some of > them don't implement the expected functionality. > > * Quality and Performance > We've spent a good deal of effort on quality during the Icehouse release, > but I think there's still a lot of work to be done here. In addition I > feel we should be starting to look at things like performance and > scalability of the core project itself. We haven't done a lot of focused > work here in the past, and I think we should. > > We also would benefit greatly from more in-depth testing being added to > Tempest as part of the CI process. In particular we don't have much of the > scenario testing that's been introduced to some of the other projects to do > more stress and large-scale type operations. > > * Processes to test storage backends > This has been somewhat controversial, but it really shouldn't be. Once you > strip away the rhetoric and the strong opinions, at the end of the day I > would just like to see every driver in Cinder undergo and pass the same > tests that every commit runs against the LVMiSCSI driver. It doesn't have > to be "everything" at once, but starting on this and getting data will help > to make Cinder and OpenStack a much stronger and healthier project. > > * Configuration and Management improvements > This is something that has a lot of potential in my opinion. Cinder isn't > the most difficult project to set up and manage, however it does have a > daunting number of options, and ever growing number of choices in > components and many of them aren't well understood. I'd like to see > easier, more clear configuration options, the ability to do things like > "plug and play" driver/backend addition etc. > > * Tighter integration and collaboration with other OpenStack projects > This is a big one in my opinion as the number of projects in OpenStack > continues to grow at an exponential rate. We as the Cinder team should do > a much better job of tying in with other groups, not only the obvious like > Nova, but also Ceilometer, Trove, Savannah and of course Horizon. > > Our logging and exception handling also still needs a good deal of work. > I've spent a lot of time this release inspecting logs and debugging issues > and I'm afraid we don't make things very easy for folks that are actually > deploying OpenStack and trying to use the logs to debug issues. > > I've had a few people approach me and ask if I thought it would be good
[openstack-dev] [OpenStack-Dev] Cinder PTL Candidacy
I'd like to announce my candidacy for the Block Storage (Cinder) PTL position. I've been involved with OpenStack for about two and a half years now, starting out by trying to help with some things in Nova-Volumes and then with the help of a lot of great folks creating Cinder. I have been the unofficial and official PTL for Cinder since its beginning, and I've been pretty passionate about the project, it's goals and it's evolution the entire time. There are a lot of different views about what a PTL "does", some candidacies point out that it's not technical, others talk about delegation and management. I think that every project is different, and a lot of the responsibility comes down to what sort of dedicated team of contributors you have working on the project. The role of PTL has requirements that are well defined in item [1]. In addition however I think it's the responsibility to step in and fill in the gaps if and when needed. This could be spending late nights debugging issues that slipped in to the gate and wreak havoc on our process, or picking up the bugs that nobody else wants to work on. In my opinion the PTL is not only a Project Manager and an Ambassador, but he or she is also a sort of pinch hitter on the technical side. Cinder has come a long way over the past year, not only the project, but the team itself. The maturity and growth of the project is visible from the diverse group of dedicated folks we now have working on the project on a regular basis. We have greatly increased our number of reviewers as well as contributors and while it's sometimes challenging we've maintained our stance on API compatibility and feature implementation requirements for all drivers. The review and contribution stats(here [2] and here [3]) are a clear indication that the project is actively growing and the work-load is becoming more and more evenly distributed. I personally think Cinder is on the right track and the current direction is the right one to continue on. All of that being said, there are still significant challenges ahead; the top items I see for the Juno release: * Maintaining driver compatibility We've always taken a hard stance on requiring all submitted drivers to meet a base set of requirements, this is extremely important for end users to ensure the promise of OpenStack is realized. It's rather difficult to pool multiple block storage resources into a single virtual resource if some of them don't implement the expected functionality. * Quality and Performance We've spent a good deal of effort on quality during the Icehouse release, but I think there's still a lot of work to be done here. In addition I feel we should be starting to look at things like performance and scalability of the core project itself. We haven't done a lot of focused work here in the past, and I think we should. We also would benefit greatly from more in-depth testing being added to Tempest as part of the CI process. In particular we don't have much of the scenario testing that's been introduced to some of the other projects to do more stress and large-scale type operations. * Processes to test storage backends This has been somewhat controversial, but it really shouldn't be. Once you strip away the rhetoric and the strong opinions, at the end of the day I would just like to see every driver in Cinder undergo and pass the same tests that every commit runs against the LVMiSCSI driver. It doesn't have to be "everything" at once, but starting on this and getting data will help to make Cinder and OpenStack a much stronger and healthier project. * Configuration and Management improvements This is something that has a lot of potential in my opinion. Cinder isn't the most difficult project to set up and manage, however it does have a daunting number of options, and ever growing number of choices in components and many of them aren't well understood. I'd like to see easier, more clear configuration options, the ability to do things like "plug and play" driver/backend addition etc. * Tighter integration and collaboration with other OpenStack projects This is a big one in my opinion as the number of projects in OpenStack continues to grow at an exponential rate. We as the Cinder team should do a much better job of tying in with other groups, not only the obvious like Nova, but also Ceilometer, Trove, Savannah and of course Horizon. Our logging and exception handling also still needs a good deal of work. I've spent a lot of time this release inspecting logs and debugging issues and I'm afraid we don't make things very easy for folks that are actually deploying OpenStack and trying to use the logs to debug issues. I've had a few people approach me and ask if I thought it would be good if I were to "not" run; in my case I still feel that I have a good deal to offer and I'd like to continue doing the work. I'm relying more and more on other contributors in the community which makes a huge difference. Eve
Re: [openstack-dev] [Cinder] PTL candidacy
+1 Duncan has always been helpful and insightful as well as seeming keen to maintain good standards within the project and while the competition is strong I am happy to support Duncan's candidacy. On 26/09/13 16:44, Duncan Thomas wrote: > I would like to run for election as Cinder PTL for the upcoming > Icehouse release. > > I've been involved with Openstack for more than 2 years, I've been an > active and vocal member of the Cinder core team since cinder was > formed and have contributed to variously to debates, reviews, designs > and code. Before that I've been involved with high-performance compute > clusters and networking both as a developer and from an ops > prospective. > > I think Cinder is a strong and healthy project, and I'd like to > continue to build on the great work John Griffith has been doing as > PTL. We have at least 16 different back-ends supported, and have been > very successful in allowing many levels of contribution and > involvement. > > If elected, my main drives for the Icehouse release will be: > > - Cross project coordination - several features have suffered somewhat > from the fact that coordination is needed between cinder and other > projects, particularly nova and horizon. I'd like to work with the PTL > and core team of those projects to see what we can do to better align > expectations and synchronisation between projects, so that features > like volume encryption, read-only volumes, ACLs etc. can be landed > more smoothly > > - Deployment issues - several large companies now deploy code from > trunk between releases, and perform regular rolling releases. I'd like > to focus on what makes that difficult and what we can do in terms of > reviews, testing and design to make that a smoother progress. This > includes tying into OSLO and other projects that are working on this. > Task-flow is a good example of a project that made significant useful > progress by working with cinder as a first user before moving out to > otehr projects. > > - Grow the cinder community, and encourage new contributes in form of > testing and validation as well as new features. Generally keep the > fantastic inclusive nature of the cinder project going, and encourage > the healthy debates that have allowed us to come up with great > solutions. > > - Blueprint management - Many blueprints are currently very thin > indeed, often no more than a sentence or two. I'd like to see more > push-back blueprints that do not provide a reasonable amount of detail > before the code comes along, in order to allow discussion and debate > earlier in the development cycle. > > There are many other sub-projects within cinder, such as driver > validation, that I support and intend to do my best to see succeed. > > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] PTL candidacy
I would like to run for election as Cinder PTL for the upcoming Icehouse release. I've been involved with Openstack for more than 2 years, I've been an active and vocal member of the Cinder core team since cinder was formed and have contributed to variously to debates, reviews, designs and code. Before that I've been involved with high-performance compute clusters and networking both as a developer and from an ops prospective. I think Cinder is a strong and healthy project, and I'd like to continue to build on the great work John Griffith has been doing as PTL. We have at least 16 different back-ends supported, and have been very successful in allowing many levels of contribution and involvement. If elected, my main drives for the Icehouse release will be: - Cross project coordination - several features have suffered somewhat from the fact that coordination is needed between cinder and other projects, particularly nova and horizon. I'd like to work with the PTL and core team of those projects to see what we can do to better align expectations and synchronisation between projects, so that features like volume encryption, read-only volumes, ACLs etc. can be landed more smoothly - Deployment issues - several large companies now deploy code from trunk between releases, and perform regular rolling releases. I'd like to focus on what makes that difficult and what we can do in terms of reviews, testing and design to make that a smoother progress. This includes tying into OSLO and other projects that are working on this. Task-flow is a good example of a project that made significant useful progress by working with cinder as a first user before moving out to otehr projects. - Grow the cinder community, and encourage new contributes in form of testing and validation as well as new features. Generally keep the fantastic inclusive nature of the cinder project going, and encourage the healthy debates that have allowed us to come up with great solutions. - Blueprint management - Many blueprints are currently very thin indeed, often no more than a sentence or two. I'd like to see more push-back blueprints that do not provide a reasonable amount of detail before the code comes along, in order to allow discussion and debate earlier in the development cycle. There are many other sub-projects within cinder, such as driver validation, that I support and intend to do my best to see succeed. -- Duncan Thomas -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] PTL candidacy
I would like to run for election as Cinder PTL for the upcoming Icehouse release. I've been involved with Openstack for more than 2 years, I've been an active and vocal member of the Cinder core team since cinder was formed and have contributed to variously to debates, reviews, designs and code. Before that I've been involved with high-performance compute clusters and networking both as a developer and from an ops prospective. I think Cinder is a strong and healthy project, and I'd like to continue to build on the great work John Griffith has been doing as PTL. We have at least 16 different back-ends supported, and have been very successful in allowing many levels of contribution and involvement. If elected, my main drives for the Icehouse release will be: - Cross project coordination - several features have suffered somewhat from the fact that coordination is needed between cinder and other projects, particularly nova and horizon. I'd like to work with the PTL and core team of those projects to see what we can do to better align expectations and synchronisation between projects, so that features like volume encryption, read-only volumes, ACLs etc. can be landed more smoothly - Deployment issues - several large companies now deploy code from trunk between releases, and perform regular rolling releases. I'd like to focus on what makes that difficult and what we can do in terms of reviews, testing and design to make that a smoother progress. This includes tying into OSLO and other projects that are working on this. Task-flow is a good example of a project that made significant useful progress by working with cinder as a first user before moving out to otehr projects. - Grow the cinder community, and encourage new contributes in form of testing and validation as well as new features. Generally keep the fantastic inclusive nature of the cinder project going, and encourage the healthy debates that have allowed us to come up with great solutions. - Blueprint management - Many blueprints are currently very thin indeed, often no more than a sentence or two. I'd like to see more push-back blueprints that do not provide a reasonable amount of detail before the code comes along, in order to allow discussion and debate earlier in the development cycle. There are many other sub-projects within cinder, such as driver validation, that I support and intend to do my best to see succeed. -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
