[Openstack-operators] [simplification] PTG Recap

# Simplification PTG Recap ## Introduction This goal was started off in the May 2017 leadership workshop [1]. We are collecting feedback from the community that OpenStack can be complex for deployers, contributors, and ultimately the people we’re all supporting, our consumers of clouds. This

Re: [Openstack-operators] [openstack-dev] [nova] key_pair update on rebuild (a whole lot of conversations)

On 10/3/2017 3:16 PM, Sean Dague wrote: There is currently a spec up for being able to specify a new key_pair name during the rebuild operation in Nova - https://review.openstack.org/#/c/375221/ For those not completely familiar with Nova operations, rebuild triggers the "reset this vm to

Re: [Openstack-operators] [nova] Should we allow passing new user_data during rebuild?

On Tue, Oct 03, 2017 at 08:29:45PM +, Jeremy Stanley wrote: :On 2017-10-03 16:19:27 -0400 (-0400), Jonathan Proulx wrote: :[...] :> This works in our OpenStack where it's our IP space so PTR record also :> matches, not so well in public cloud where we can reserve an IP and :> set forward DNS

Re: [Openstack-operators] [nova] Should we allow passing new user_data during rebuild?

On 2017-10-03 16:19:27 -0400 (-0400), Jonathan Proulx wrote: [...] > This works in our OpenStack where it's our IP space so PTR record also > matches, not so well in public cloud where we can reserve an IP and > set forward DNS but not control its reverse mapping. [...] Not that it probably

Re: [Openstack-operators] [nova] Should we allow passing new user_data during rebuild?

On Tue, Oct 03, 2017 at 01:00:13PM -0700, Clint Byrum wrote: :It's worth noting that AD and Kerberos were definitely not designed :for clouds that have short lived VMs, so it does not surprise me that :treating VMs as cattle and then putting them in AD would confuse it. For instances we have

Re: [Openstack-operators] [nova] Should we allow passing new user_data during rebuild?

I fully appreciate that there are users of it today, and that it is a thing that will likely live for years. Long lived VMs can use all sorts of features to make VMs work more like precious long lived servers. However, supporting these cases directly doesn't make OpenStack scalable or simple.

Re: [Openstack-operators] [nova] Should we allow passing new user_data during rebuild?

We use rebuild when reverting with snapshots. Keeping the same IP and hostname avoids some issues with Active Directory and Kerberos. Tim -Original Message- From: Clint Byrum Date: Tuesday, 3 October 2017 at 19:17 To: openstack-operators

Re: [Openstack-operators] [nova] Should we allow passing new user_data during rebuild?

Excerpts from Matt Riedemann's message of 2017-10-03 10:53:44 -0500: > We plan on deprecating personality files from the compute API in a new > microversion. The spec for that is here: > > https://review.openstack.org/#/c/509013/ > > Today you can pass new personality files to inject during

Re: [Openstack-operators] [nova] Should we allow passing new user_data during rebuild?

On 10/3/2017 10:53 AM, Matt Riedemann wrote: However, if the only reason one would need to pass personality files during rebuild is because we don't persist them during the initial server create, do we really need to also allow passing user_data for rebuild? Given personality files were

[Openstack-operators] [nova] Should we allow passing new user_data during rebuild?

We plan on deprecating personality files from the compute API in a new microversion. The spec for that is here: https://review.openstack.org/#/c/509013/ Today you can pass new personality files to inject during rebuild, and at the PTG we said we'd allow passing new user_data to rebuild as a

Re: [Openstack-operators] [openstack-dev] [nova] reset key pair during rebuilding

Hello, I agree this feature of injecting a new keypair is something of great use. We are always dealing with users that cant access their VMs anymore. But AFAIU here we are talking about injecting a new key at REBUILD. So it does not fit the scenario of a staff member that leaves ! We hardly

[Openstack-operators] Ops Meetups Team Meeting 2017-10-3

Minutes and meeting log for today's IRC meeting may be found here: Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-10-03-14.02.html Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-10-03-14.02.txt Log:

Re: [Openstack-operators] [magnum] issue using magnum on Pike

Thank you very much! That makes a ton of sense. How did you troubleshoot this? I couldn’t find anything intuitive about the error message. Do you think this is worthy of a bug submittal? Or is it strictly a build issue on SuSE’s part? Thanks, Andrew Wojnarek | Sr. Systems Engineer| ATS

[Openstack-operators] [openstack-ansible] Meetings change

Hello everyone, Some people on this planet are more aware of others of this fact: we have too many meetings in our life. I don't think OpenStack-Ansible should be so greedy to take 8 hours of your life a month for meetings. I therefore propose the reduction to 4 meetings/month: 3 bug triages and

Re: [Openstack-operators] [magnum] issue using magnum on Pike

cc Andy Wojnarek and Erik McCormick On 3 October 2017 at 10:32, Spyros Trigazis wrote: > Hello, > > It looks like the new docker module is not installed. > The docker client moved from docker 1.x to 2.x and > unfortunately they changed the name. > > Magnum Pike depends on

Re: [Openstack-operators] [magnum] issue using magnum on Pike

Hello, It looks like the new docker module is not installed. The docker client moved from docker 1.x to 2.x and unfortunately they changed the name. Magnum Pike depends on python-docker 2.x. http://git.openstack.org/cgit/openstack/magnum/tree/requirements.txt?h=stable%2Fpike#n16 Module named