[openstack-dev] [fuel] time to retire (parts of) fuel?
I see that many repos have not seen any merges for fuel. Do you want to
retire at least parts of it?
We have many bitrot jobs for fuel set up and people proposing jobs
against it that get no reaction - so, I suggest to make it's state clear.
I see some changes in fuel-devops - but the rest looks really dead.
What's your suggestion to move forward?
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
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] [ironic][bifrost][sushy][ironic-inspector][ironic-ui][virtualbmc] sub-project/repository core reviewer changes
+1 to all On Thu, Aug 23, 2018, 20:25 Julia Kreger wrote: > Greetings everyone! > > In our team meeting this week we stumbled across the subject of > promoting contributors to be sub-project's core reviewers. > Traditionally it is something we've only addressed as needed or > desired by consensus with-in those sub-projects, but we were past due > time to take a look at the entire picture since not everything should > fall to ironic-core. > > And so, I've taken a look at our various repositories and I'm > proposing the following additions: > > For sushy-core, sushy-tools-core, and virtualbmc-core: Ilya > Etingof[1]. Ilya has been actively involved with sushy, sushy-tools, > and virtualbmc this past cycle. I've found many of his reviews and > non-voting review comments insightful and willing to understand. He > has taken on some of the effort that is needed to maintain and keep > these tools usable for the community, and as such adding him to the > core group for these repositories makes lots of sense. > > For ironic-inspector-core and ironic-specs-core: Kaifeng Wang[2]. > Kaifeng has taken on some hard problems in ironic and > ironic-inspector, as well as brought up insightful feedback in > ironic-specs. They are demonstrating a solid understanding that I only > see growing as time goes on. > > For sushy-core: Debayan Ray[3]. Debayan has been involved with the > community for some time and has worked on sushy from early on in its > life. He has indicated it is near and dear to him, and he has been > actively reviewing and engaging in discussion on patchsets as his time > has permitted. > > With any addition it is good to look at inactivity as well. It saddens > me to say that we've had some contributors move on as priorities have > shifted to where they are no longer involved with the ironic > community. Each person listed below has been inactive for a year or > more and is no longer active in the ironic community. As such I've > removed their group membership from the sub-project core reviewer > groups. Should they return, we will welcome them back to the community > with open arms. > > bifrost-core: Stephanie Miller[4] > ironic-inspector-core: Anton Arefivev[5] > ironic-ui-core: Peter Peila[6], Beth Elwell[7] > > Thanks, > > -Julia > > [1]: http://stackalytics.com/?user_id=etingof=marks > [2]: http://stackalytics.com/?user_id=kaifeng=marks > [3]: http://stackalytics.com/?user_id=deray=marks=all > [4]: http://stackalytics.com/?metric=marks=all_id=stephan > [5]: http://stackalytics.com/?user_id=aarefiev=marks > [6]: http://stackalytics.com/?metric=marks=all_id=ppiela > [7]: > http://stackalytics.com/?metric=marks=all_id=bethelwell=ironic-ui > > __ > 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] [ironic][bifrost][sushy][ironic-inspector][ironic-ui][virtualbmc] sub-project/repository core reviewer changes
+1 to all proposed changes. Thanks and Regards Shivanand On Thu, Aug 23, 2018 at 11:54 PM, Julia Kreger wrote: > Greetings everyone! > > In our team meeting this week we stumbled across the subject of > promoting contributors to be sub-project's core reviewers. > Traditionally it is something we've only addressed as needed or > desired by consensus with-in those sub-projects, but we were past due > time to take a look at the entire picture since not everything should > fall to ironic-core. > > And so, I've taken a look at our various repositories and I'm > proposing the following additions: > > For sushy-core, sushy-tools-core, and virtualbmc-core: Ilya > Etingof[1]. Ilya has been actively involved with sushy, sushy-tools, > and virtualbmc this past cycle. I've found many of his reviews and > non-voting review comments insightful and willing to understand. He > has taken on some of the effort that is needed to maintain and keep > these tools usable for the community, and as such adding him to the > core group for these repositories makes lots of sense. > > For ironic-inspector-core and ironic-specs-core: Kaifeng Wang[2]. > Kaifeng has taken on some hard problems in ironic and > ironic-inspector, as well as brought up insightful feedback in > ironic-specs. They are demonstrating a solid understanding that I only > see growing as time goes on. > > For sushy-core: Debayan Ray[3]. Debayan has been involved with the > community for some time and has worked on sushy from early on in its > life. He has indicated it is near and dear to him, and he has been > actively reviewing and engaging in discussion on patchsets as his time > has permitted. > > With any addition it is good to look at inactivity as well. It saddens > me to say that we've had some contributors move on as priorities have > shifted to where they are no longer involved with the ironic > community. Each person listed below has been inactive for a year or > more and is no longer active in the ironic community. As such I've > removed their group membership from the sub-project core reviewer > groups. Should they return, we will welcome them back to the community > with open arms. > > bifrost-core: Stephanie Miller[4] > ironic-inspector-core: Anton Arefivev[5] > ironic-ui-core: Peter Peila[6], Beth Elwell[7] > > Thanks, > > -Julia > > [1]: http://stackalytics.com/?user_id=etingof=marks > [2]: http://stackalytics.com/?user_id=kaifeng=marks > [3]: http://stackalytics.com/?user_id=deray=marks=all > [4]: http://stackalytics.com/?metric=marks=all_id=stephan > [5]: http://stackalytics.com/?user_id=aarefiev=marks > [6]: http://stackalytics.com/?metric=marks=all_id=ppiela > [7]: http://stackalytics.com/?metric=marks=all_ > id=bethelwell=ironic-ui > > __ > 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][cinder] Disabling nova volume-update (aka swap volume; aka cinder live migration)
On Fri, Aug 24, 2018 at 04:20:21PM -0500, Matt Riedemann wrote: > On 8/20/2018 10:29 AM, Matthew Booth wrote: > > Secondly, is there any reason why we shouldn't just document then you > > have to delete snapshots before doing a volume migration? Hopefully > > some cinder folks or operators can chime in to let me know how to back > > them up or somehow make them independent before doing this, at which > > point the volume itself should be migratable? > > Coincidentally the volume migration API never had API reference > documentation. I have that here now [1]. It clearly states the preconditions > to migrate a volume based on code in the volume API. However, volume > migration is admin-only by default and retype (essentially like resize) is > admin-or-owner so non-admins can do it and specify to migrate. In general I > think it's best to have preconditions for *any* API documented, so anything > needed to perform a retype should be documented in the API, like that the > volume can't have snapshots. That's where things get tricky though. There aren't really reconditions we can have as a blanket statement with the retype API. A retype can do a lot of different things, all dependent on what type you are coming from and trying to go to. There are some retypes where all it does is enable vendor flag ``foo`` on the volume with no change in any other state. Then there are other retypes (using --migrate-policy on-demand) that completely move the volume from one backend to another one, copying every block along the way from the original to the new volume. It really depends on what types you are trying to retype to. > > [1] https://review.openstack.org/#/c/595379/ > > -- > > Thanks, > > Matt > > __ > 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
