Re: [openstack-dev] [nova] key_pair update on rebuild (a whole lot of conversations)
Excerpts from Ben Nemec's message of 2017-10-03 23:05:49 -0500: > > On 10/03/2017 03:16 PM, Sean Dague wrote: > > = Where I think we are? = > > > > I think with all this data we're at the following: > > > > Q: Should we add this to rebuild > > A: Yes, probably - after some enhancement to the spec * > > > > * - we really should have much better use cases about the situations it > > is expected to be used in. We spend a lot of time 2 and 3 years out > > trying to figure out how anyone would ever use a feature, and adding > > another one without this doesn't seem good > > Here's an example from my use: I create a Heat stack, then realize I > deployed some of the instances with the wrong keypair. I'd rather not > tear down the entire stack just to fix that, and being able to change > keys on rebuild would allow me to avoid doing so. I can rebuild a > Heat-owned instance without causing any trouble, but I can't re-create it. > > I don't know how common this is, but it's definitely something that has > happened to me in the past. > Sorry but this is an argument to use Heat more, but rebuild is totally unnecessary. In heat if you change the keypair and update the stack, it will create a new one with the right keypair and delete the old instance (or you can make it use rebuild, a feature I believe I developed actually). The updated IPs will be rolled out to all resources that reference that instance's IP. If you have wait conditions which depend on this instance, Heat will wait until they are re-triggered before deleting the old instance. This is literally why Heat is a cool thing, because it lets you use the cloud the way the cloud was intended to be used. If you use rebuild, while it is rebuilding, your service is unavailable. If you use create/wait/delete you have a chance to automate the transition from the old to new instance. > > > > Q: should this also be on reboot? > > A: NO - it would be too fragile > > > > > > I also think figuring out a way to get Nova out of the key storage > > business (which it really shouldn't be in) would be good. So if anyone > > wants to tackle Nova using Barbican for keys, that would be ++. Rebuild > > doesn't wait on that, but Barbican urls for keys seems like a much > > better world to be in. > > > > -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] [security] Security SIG
Luke Hinds wrote: > [...] > Something else which comes to mind; it seems to me we are more of a > 'working group', are working groups no longer a thing in OpenStack? - > SIG seems like a better fit for topics focused mainly on cross project > collaborations efforts (API's being a good example), whereas we have a > lot of group like tasks that we handle in silo? Working groups are still a thing, but they are tied to a specific governance body (TC, UC, Board of Directors). SIGs are cross-community working groups, beyond a single governance body. Project teams are a form of TC-owned working group dedicated to the production of OpenStack software. With security having so much operational ties, it feels like a SIG would be the best match as it prevents artificial governance boundaries from getting in the way of getting people more directly involved. -- Thierry Carrez (ttx) __ 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] Developer Mailing List Digest October 28th - November 3rd
Contribute to the Dev Digest by summarizing OpenStack Dev List thread: * https://etherpad.openstack.org/p/devdigest * http://lists.openstack.org/pipermail/openstack-dev/ HTML version: https://www.openstack.org/blog/2017/11/developer-mailing-list-digest-october-28th-november-3rd/ News * Sydney Summit Etherpads [0] [0] - https://wiki.openstack.org/wiki/Forum/Sydney2017 Community Summaries === Nova Placements Resource Provider Update by Eric Fried [0] Nova Notification Update by Balazs Gibizer [1] Technical Committee Status update by Thierry Carrez [2] Technical Committee Report by Chris Dent [3] Release Countdown by Sean McGinnis [4] POST /api-sig/news by Chris Dent [5] [0] - http://lists.openstack.org/pipermail/openstack-dev/2017-November/124233.html [1] - http://lists.openstack.org/pipermail/openstack-dev/2017-October/124079.html [2] - http://lists.openstack.org/pipermail/openstack-dev/2017-October/124049.html [3] - http://lists.openstack.org/pipermail/openstack-dev/2017-October/124134.html [4] - http://lists.openstack.org/pipermail/openstack-dev/2017-October/123799.html [5] - http://lists.openstack.org/pipermail/openstack-dev/2017-October/124023.html TC Election Results (continued) === Congrats to our 6 newly elected Technical Committee members: Colleen Murphy (cmurphy) Doug Hellmann (dhellmann) Emilien Macchi (emilienm) Jeremy Stanley (fungi) Julia Kreger (TheJulia) Paul Belanger (pabelanger) Full results are available [0]. The process and results are also available [1]. 420 voted out of 2430 electorate, giving us a 17.28% turn out with a delta of 29.16% [2]. Reasons for the low turnout is hard to tell without knowing who is voting and what their activity is in the community. More people are beginning to understand the point of the TC activities, being more around duties than rights (e.g. stewardship and leadership). People could care a bit less about specific individuals and are less motivated by the vote itself. If the activity of the TC was a lot more conflict and a lot less consensus, people might care about it more. [0] - http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae [1] - https://governance.openstack.org/election/ [2] - http://lists.openstack.org/pipermail/openstack-dev/2017-October/123848.html Full thread: http://lists.openstack.org/pipermail/openstack-dev/2017-October/thread.html#124004 Security SIG Our governance used to only have project teams to recognize activity in OpenStack, so we created a security team. Introduction of sigs provide a new construct for recognizing activity around a group that share interest around a topic or practice that are not mainly around software bits. Security is a great example of a topic that could benefit from this construct to gather all security-conscious people in our community. SIGs can have software by-products and own git repositories, and the software is more about security in general than a piece of OpenStack itself. It's important to consider the Vulnerability Management Team (VMT) under the new model, which acts as an independent task force. The Security team discussed the idea of a SIG in their meeting, and overall think it's worth exploring by having the SIG and team exist in parallel to see if there is traction. Full thread: http://lists.openstack.org/pipermail/openstack-dev/2017-October/thread.html#124053 -- Mike Perez (thingee) pgpVF01hhDNf9.pgp Description: PGP signature __ 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] [Neut​ron][L3-subteam] Weekly IRC meeting cancelled on November 9th
Dear Neutron L3 sub-team, Several of the team members will be attending the Summit in Sydney. Therefore, we will cancel the weekly meeting on November 9th. We will resume normally on the 16th. Cheers Miguel __ 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] [Neut​ron][Drivers-team] Weekly IRC meeting cancelled on November 9th
Dear Neutrinos, Due to the Summit in Sydney, we will cancel the scheduled drivers meeting on November 10th. We will resume normally on the 16th Cheers Miguel __ 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
