<div dir="ltr">Hi , <div><br></div><div>You can use alot of tools to create virtual machines in openstack.</div><div><br></div><div>The quick answers are: </div><div><br></div><div> 1. Terraform</div><div> 2. Ansible</div><div><br></div><div><br></div><div>Currently I am using a python library developed at CERN-IT called AITOOLS that uses the openstack api to create virtual machines and bind them to puppet and foreman for configuration management.</div><div><br></div><div><br></div><div><a href="https://github.com/iahmad-khan/ai-tools">https://github.com/iahmad-khan/ai-tools</a></div><div><br></div><div>enjoy.</div><div><br></div><div>cheers</div><div>ijaz<br><div class="gmail_extra"><br><div class="gmail_quote">On 6 October 2017 at 13:00, <span dir="ltr"><<a href="mailto:openstack-operators-request@lists.openstack.org" target="_blank">openstack-operators-request@lists.openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send OpenStack-operators mailing list submissions to<br>
<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-operators-request@lists.openstack.org">openstack-operators-request@<wbr>lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-operators-owner@lists.openstack.org">openstack-operators-owner@<wbr>lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-operators digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [puppet] Where to start ? (Tobias Urdin)<br>
2. Re: [glance-survey] specify-an-image-ID-at-image-<wbr>creation<br>
survey (Brian Rosmaita)<br>
3. Re: [nova] Should we allow passing new user_data during<br>
rebuild? (Clint Byrum)<br>
4. Re: [nova] Should we allow passing new user_data during<br>
rebuild? (Clint Byrum)<br>
5. Re: [nova] Should we allow passing new user_data during<br>
rebuild? (Clint Byrum)<br>
6. Re: [nova] Should we allow passing new user_data during<br>
rebuild? (Tomáš Vondra)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Thu, 5 Oct 2017 12:59:33 +0000<br>
From: Tobias Urdin <<a href="mailto:tobias.urdin@crystone.com">tobias.urdin@crystone.com</a>><br>
To: "<a href="mailto:Ulrich.Herbst@t-systems.com">Ulrich.Herbst@t-systems.com</a>" <<a href="mailto:Ulrich.Herbst@t-systems.com">Ulrich.Herbst@t-systems.com</a>><br>
Cc: "<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>"<br>
<<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [puppet] Where to start ?<br>
Message-ID: <<a href="mailto:5346f8bb20a7461395a0c3a295d4fae6@mb01.staff.ognet.se">5346f8bb20a7461395a0c3a295d4f<wbr>ae6@mb01.staff.ognet.se</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello Ulrich,<br>
<br>
<br>
My personal opinion would be that you should not use Puppet for such orchestration like creating resources,but it is possible with puppets node implementations!<br>
<br>
I think what you are looking for is something like this: <a href="https://github.com/puppetlabs/puppetlabs-node_openstack" rel="noreferrer" target="_blank">https://github.com/puppetlabs/<wbr>puppetlabs-node_openstack</a><br>
<br>
It might not be up-to-date. I think you however should look into a more linear orchestration tool instead such as Ansible instead of Puppet's "take me to this state"-like thinking but that's just my opinion.<br>
<br>
<br>
Or any other tool for that matter, Terraform, vagrant or whatever depending on your requirements.<br>
<br>
Best regards<br>
<br>
On 10/05/2017 12:04 PM, <a href="mailto:Ulrich.Herbst@t-systems.com">Ulrich.Herbst@t-systems.com</a><<wbr>mailto:<a href="mailto:Ulrich.Herbst@t-systems.com">Ulrich.Herbst@t-<wbr>systems.com</a>> wrote:<br>
Hi all,<br>
<br>
sorry for asking unprecise questions.<br>
<br>
My question is not how to run puppet on any existing VM, but: How to provision /deploy/create (Not sure about the right word) a new VM with puppet (instead of eg. clicking into the openstack GUI)<br>
<br>
Uli<br>
<br>
Von: Justin Cattle [mailto:<a href="mailto:j@ocado.com">j@ocado.com</a>]<br>
Gesendet: Donnerstag, 5. Oktober 2017 11:52<br>
An: Herbst, Ulrich <<a href="mailto:Ulrich.Herbst@t-systems.com">Ulrich.Herbst@t-systems.com</a>><<wbr>mailto:<a href="mailto:Ulrich.Herbst@t-systems.com">Ulrich.Herbst@t-<wbr>systems.com</a>><br>
Cc: OpenStack Operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><mailto:<a href="mailto:openstack-operators@lists.openstack.org">openstac<wbr>k-operators@lists.openstack.<wbr>org</a>><br>
Betreff: Re: [Openstack-operators] [puppet] Where to start ?<br>
<br>
Running puppet on openstack instances is no different than running puppet on bare metal, or elsewhere.<br>
I would say it's kind of outside the scope of this list, which his more about the openstack infrastructure itself - although someone else may chime in and help you :)<br>
<br>
<br>
<br>
<br>
<br>
Cheers,<br>
Just<br>
<br>
On 5 October 2017 at 08:30, <<a href="mailto:Ulrich.Herbst@t-systems.com">Ulrich.Herbst@t-systems.com</a><<wbr>mailto:<a href="mailto:Ulrich.Herbst@t-systems.com">Ulrich.Herbst@t-<wbr>systems.com</a>>> wrote:<br>
Dear list,<br>
<br>
I'm new on an (existing) OpenStack "cloud" and have to deploy some VMs there.<br>
<br>
I'm experienced with puppet and want to use that to automatically deploy VMs (and install software there).<br>
<br>
I know about <a href="https://docs.openstack.org/puppet-openstack-guide/latest/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>puppet-openstack-guide/latest/</a> - but don't see a point where to start.<br>
<br>
Do you have any pointers, links, tutorials, documentation for me where/how to start ?<br>
<br>
I'm not interested in deploying the OpenStack infrastructure itself.<br>
<br>
Thank you<br>
Uli<br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><mailto:<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack<wbr>-operators@lists.openstack.org</a><wbr>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br>
<br>
<br>
Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.<br>
<br>
<br>
<br>
If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.<br>
<br>
<br>
<br>
Fetch and Sizzle are trading names of Speciality Stores Limited and Fabled is a trading name of Marie Claire Beauty Limited, both members of the Ocado Group.<br>
<br>
<br>
<br>
References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-operators/attachments/20171005/e288708d/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-operators/<wbr>attachments/20171005/e288708d/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 5 Oct 2017 09:45:31 -0400<br>
From: Brian Rosmaita <<a href="mailto:rosmaita.fossdev@gmail.com">rosmaita.fossdev@gmail.com</a>><br>
To: OpenStack Operators List <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [glance-survey]<br>
specify-an-image-ID-at-image-<wbr>creation survey<br>
Message-ID:<br>
<CAFnESPo7LhGOwRy8NDTCw+wGb2d_<wbr>SmYGhFq3VPpY_+9ja=<a href="mailto:WUeA@mail.gmail.com">WUeA@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
Here are the results of the survey:<br>
<br>
OpenStack Glance specify-an-image-ID-at-image-<wbr>creation survey<br>
<br>
This is a quick survey to find out how many people use the ability to<br>
specify a specific image_id at the time of image creation in Glance.<br>
<br>
Note that if you manage multiple clouds, you can fill this out<br>
multiple times with information about each. We encourage you to do so<br>
to help us get an accurate idea of how widely this feature is used.<br>
<br>
Thanks in advance for your help!<br>
<br>
This survey closes at 23:59 UTC on Tuesday 3 October 2017.<br>
<br>
Responses: 8 (1 response == 12.5%)<br>
<br>
Size of deployment (in tenants):<br>
small (1-10): 0%<br>
medium (11-100): 12.5%<br>
large (101-1000): 62.5%<br>
XL (1001+): 25%<br>
<br>
As an operator, do you use the functionality that allows you to set an<br>
image to a specific image_id upon image creation?<br>
yes: 12.5%<br>
no: 87.5%<br>
<br>
Do you know if your end users use this functionality?<br>
yes: 12.5%<br>
no: 50%<br>
don't know: 37.5%<br>
<br>
Are you aware of OSSN-0075, that explains how this functionality is a<br>
security problem?<br>
Yes, I already knew about it: 50%<br>
No, I wasn't aware (but I am now!): 50%<br>
<br>
If a policy were introduced to govern this functionality, what would you do?<br>
Leave the policy unrestricted, I don't need to purge my database: 0%<br>
Leave the policy unrestricted, I can trust my users not to try the<br>
OSSN-0075 exploit: 0%<br>
Leave the policy unrestricted because my users rely on this functionality: 0%<br>
Restrict usage to admin users only: 12.5%<br>
Restrict usage to admin users and other specific trusted users: 50%<br>
Restrict usage completely (allow none), we don't need this functionality: 37.5%<br>
<br>
Does it bother you that if a policy were introduced to govern this<br>
functionality, it could present an interoperability problem?<br>
It bothers me, but I don't think this is a widely-used functionality,<br>
so it's OK: 12.5%<br>
It bothers me, but security trumps interoperability in this case, so<br>
it's OK: 75%<br>
It bothers me enough that I'd prefer that this not be fixed by<br>
introducing a policy, even if that means not fixing it at all: 0%<br>
It bothers me enough that I'd prefer this be fixed by disallowing the<br>
functionality completely so that it could not be used by any user<br>
(even an admin) in any cloud: 12.5%<br>
<br>
-- end --<br>
<br>
<br>
On Thu, Sep 28, 2017 at 6:48 PM, Brian Rosmaita<br>
<<a href="mailto:rosmaita.fossdev@gmail.com">rosmaita.fossdev@gmail.com</a>> wrote:<br>
> The Glance spec freeze is coming up soon and we could use operator<br>
> input on a proposal to govern a currently unrestricted functionality<br>
> by policy. The survey is 6 multiple choice questions and closes at<br>
> 23:59 UTC on Tuesday 3 October 2017, so please fill it out right away.<br>
><br>
> The purpose of the survey is to gather data concerning how many people<br>
> use the ability to specify a specific image_id at the time of image<br>
> creation in Glance -- so even if you've never heard of this<br>
> functionality (and hence have never used it), it would be helpful for<br>
> you to fill out the survey because you will give us a data point.<br>
><br>
> <a href="https://goo.gl/forms/1dATtCW6V0xExRc22" rel="noreferrer" target="_blank">https://goo.gl/forms/<wbr>1dATtCW6V0xExRc22</a><br>
><br>
> Thanks for your help!<br>
> The Glance Team<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 05 Oct 2017 09:41:00 -0700<br>
From: Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
To: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [nova] Should we allow passing new<br>
user_data during rebuild?<br>
Message-ID: <<a href="mailto:1507221103-sup-2389@fewbar.com">1507221103-sup-2389@fewbar.<wbr>com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Excerpts from Chris Friesen's message of 2017-10-04 09:15:28 -0600:<br>
> On 10/03/2017 11:12 AM, Clint Byrum wrote:<br>
><br>
> > My personal opinion is that rebuild is an anti-pattern for cloud, and<br>
> > should be frozen and deprecated. It does nothing but complicate Nova<br>
> > and present challenges for scaling.<br>
> ><br>
> > That said, if it must stay as a feature, I don't think updating the<br>
> > user_data should be a priority. At that point, you've basically created an<br>
> > entirely new server, and you can already do that by creating an entirely<br>
> > new server.<br>
><br>
> If you've got a whole heat stack with multiple resources, and you realize that<br>
> you messed up one thing in the template and one of your servers has the wrong<br>
> personality/user_data, it can be useful to be able to rebuild that one server<br>
> without affecting anything else in the stack. That's just a convenience though.<br>
><br>
<br>
If you just changed that personality/user_data in the template, Heat<br>
would spin up a new one, change all the references to it, wait for any<br>
wait conditions to fire, allowing dependent servers to reconfigure with<br>
the new one and acknowledge that, and then delete the old one for you.<br>
<br>
Making your app work like this means being able to replace failed or<br>
undersized servers with less downtime. You can do other things too,<br>
like spin up a replacement in a different AZ to deal with maintenance<br>
issues on your side or the cloud's side. Or you can deploy a new image,<br>
without any downtime.<br>
<br>
My point remains: rebuild (and resize) train users to see a server as<br>
precious, instead of training users to write automation that expects<br>
cloud servers to come and go often.<br>
<br>
This, btw, is one reason I like that EC2 calls them _instances_ and not<br>
_servers_. They're not servers. We call them servers, but they're just<br>
little regions of memory on actual servers, and as such, they're not<br>
precious, and should be discarded as necessary.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 05 Oct 2017 09:41:43 -0700<br>
From: Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
To: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [nova] Should we allow passing new<br>
user_data during rebuild?<br>
Message-ID: <<a href="mailto:1507221668-sup-1988@fewbar.com">1507221668-sup-1988@fewbar.<wbr>com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Excerpts from Belmiro Moreira's message of 2017-10-04 17:33:40 +0200:<br>
> In our cloud rebuild is the only way for a user to keep the same IP.<br>
> Unfortunately, we don't offer floating IPs, yet.<br>
> Also, we use the user_data to bootstrap some actions in new instances<br>
> (puppet, ...).<br>
> Considering all the use-cases for rebuild it would be great if the<br>
> user_data can be updated at rebuild time.<br>
><br>
<br>
Indeed, it sounds like we're too far down the rabbit hole with rebuild to<br>
stop digging.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 05 Oct 2017 09:49:39 -0700<br>
From: Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
To: openstack-operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [nova] Should we allow passing new<br>
user_data during rebuild?<br>
Message-ID: <<a href="mailto:1507221706-sup-9524@fewbar.com">1507221706-sup-9524@fewbar.<wbr>com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
No offense is intended, so please forgive me for the possibly incendiary<br>
nature of what I'm about to write:<br>
<br>
VPS is the predecessor of cloud (and something I love very much, and<br>
rely on every day!), and encourages all the bad habits that a cloud<br>
disallows. At small scale, it's the right thing, and that's why I use<br>
it for my small scale needs. Get a VM, put your stuff on it, and keep<br>
it running forever.<br>
<br>
But at scale, VMs in clouds go away. They get migrated, rebooted, turned<br>
off, and discarded, often. Most clouds are terrible for VPS compared to<br>
VPS hosting environments.<br>
<br>
I'm glad it's working for you. And I think rebuild and resize will stay<br>
and improve to serve VPS style users in interesting ways. I'm learning now<br>
who our users are today, and I'm confident we should make sure everyone<br>
who has taken the time to deploy and care for OpenStack should be served<br>
by expanding rebuild to meet their needs.<br>
<br>
You can all consider this my white flag. :)<br>
<br>
Excerpts from Tomáš Vondra's message of 2017-10-05 10:22:14 +0200:<br>
> In our cloud, we offer the possibility to reinstall the same or another OS on a VPS (Virtual Private Server). Unfortunately, we couldn’t use the rebuild function because of the VPS‘s use of Cinder for root disk. We create a new instance and inject the same User Data so that the new instance has the same password and key as the last one. It also has the same name, and the same floating IP is attached. I believe it even has the same IPv6 through some Neutron port magic.<br>
><br>
> BTW, you wouldn’t believe how often people use the Reinstall feature.<br>
><br>
> Tomas from Homeatcloud<br>
><br>
><br>
><br>
> From: Belmiro Moreira [mailto:<a href="mailto:moreira.belmiro.email.lists@gmail.com">moreira.belmiro.email.<wbr>lists@gmail.com</a>]<br>
> Sent: Wednesday, October 04, 2017 5:34 PM<br>
> To: Chris Friesen<br>
> Cc: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a><br>
> Subject: Re: [Openstack-operators] [nova] Should we allow passing new user_data during rebuild?<br>
><br>
><br>
><br>
> In our cloud rebuild is the only way for a user to keep the same IP. Unfortunately, we don't offer floating IPs, yet.<br>
><br>
> Also, we use the user_data to bootstrap some actions in new instances (puppet, ...).<br>
><br>
> Considering all the use-cases for rebuild it would be great if the user_data can be updated at rebuild time.<br>
><br>
><br>
><br>
> On Wed, Oct 4, 2017 at 5:15 PM, Chris Friesen <<a href="mailto:chris.friesen@windriver.com">chris.friesen@windriver.com</a>> wrote:<br>
><br>
> On 10/03/2017 11:12 AM, Clint Byrum wrote:<br>
><br>
> My personal opinion is that rebuild is an anti-pattern for cloud, and<br>
> should be frozen and deprecated. It does nothing but complicate Nova<br>
> and present challenges for scaling.<br>
><br>
> That said, if it must stay as a feature, I don't think updating the<br>
> user_data should be a priority. At that point, you've basically created an<br>
> entirely new server, and you can already do that by creating an entirely<br>
> new server.<br>
><br>
><br>
> If you've got a whole heat stack with multiple resources, and you realize that you messed up one thing in the template and one of your servers has the wrong personality/user_data, it can be useful to be able to rebuild that one server without affecting anything else in the stack. That's just a convenience though.<br>
><br>
> Chris<br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Fri, 6 Oct 2017 12:06:45 +0200<br>
From: Tomáš Vondra <<a href="mailto:vondra@homeatcloud.cz">vondra@homeatcloud.cz</a>><br>
To: "'openstack-operators'" <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: Re: [Openstack-operators] [nova] Should we allow passing new<br>
user_data during rebuild?<br>
Message-ID: <095601d33e8a$d279c140$<wbr>776d43c0$@<a href="http://homeatcloud.cz" rel="noreferrer" target="_blank">homeatcloud.cz</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Dear Clint,<br>
maybe you misunderstood a little, or I didn't write it explicitly. We use OpenStack for providing a VPS service, yes. But the VPS users do not get access to OpenStack directly, but instead, they use our Customer Portal which does the orchestration. The whole point is to make the service as easy as possible to use for them and not expose them to the complexity of the Cloud. As I said, we couldn't use Rebuild because VPS's have Volumes. We do use Resize because it is there. But we could as well use more low-level cloud primitives. The user does not care in this case. How does, e.g., WHMCS do it? That is a stock software that you can use to provide VPS over OpenStack.<br>
Tomas from Homeatcloud<br>
<br>
-----Original Message-----<br>
From: Clint Byrum [mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>]<br>
Sent: Thursday, October 05, 2017 6:50 PM<br>
To: openstack-operators<br>
Subject: Re: [Openstack-operators] [nova] Should we allow passing new user_data during rebuild?<br>
<br>
No offense is intended, so please forgive me for the possibly incendiary nature of what I'm about to write:<br>
<br>
VPS is the predecessor of cloud (and something I love very much, and rely on every day!), and encourages all the bad habits that a cloud disallows. At small scale, it's the right thing, and that's why I use it for my small scale needs. Get a VM, put your stuff on it, and keep it running forever.<br>
<br>
But at scale, VMs in clouds go away. They get migrated, rebooted, turned off, and discarded, often. Most clouds are terrible for VPS compared to VPS hosting environments.<br>
<br>
I'm glad it's working for you. And I think rebuild and resize will stay and improve to serve VPS style users in interesting ways. I'm learning now who our users are today, and I'm confident we should make sure everyone who has taken the time to deploy and care for OpenStack should be served by expanding rebuild to meet their needs.<br>
<br>
You can all consider this my white flag. :)<br>
<br>
Excerpts from Tomáš Vondra's message of 2017-10-05 10:22:14 +0200:<br>
> In our cloud, we offer the possibility to reinstall the same or another OS on a VPS (Virtual Private Server). Unfortunately, we couldn’t use the rebuild function because of the VPS‘s use of Cinder for root disk. We create a new instance and inject the same User Data so that the new instance has the same password and key as the last one. It also has the same name, and the same floating IP is attached. I believe it even has the same IPv6 through some Neutron port magic.<br>
><br>
> BTW, you wouldn’t believe how often people use the Reinstall feature.<br>
><br>
> Tomas from Homeatcloud<br>
><br>
><br>
><br>
> From: Belmiro Moreira [mailto:<a href="mailto:moreira.belmiro.email.lists@gmail.com">moreira.belmiro.email.<wbr>lists@gmail.com</a>]<br>
> Sent: Wednesday, October 04, 2017 5:34 PM<br>
> To: Chris Friesen<br>
> Cc: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a><br>
> Subject: Re: [Openstack-operators] [nova] Should we allow passing new user_data during rebuild?<br>
><br>
><br>
><br>
> In our cloud rebuild is the only way for a user to keep the same IP. Unfortunately, we don't offer floating IPs, yet.<br>
><br>
> Also, we use the user_data to bootstrap some actions in new instances (puppet, ...).<br>
><br>
> Considering all the use-cases for rebuild it would be great if the user_data can be updated at rebuild time.<br>
><br>
><br>
><br>
> On Wed, Oct 4, 2017 at 5:15 PM, Chris Friesen <<a href="mailto:chris.friesen@windriver.com">chris.friesen@windriver.com</a>> wrote:<br>
><br>
> On 10/03/2017 11:12 AM, Clint Byrum wrote:<br>
><br>
> My personal opinion is that rebuild is an anti-pattern for cloud, and<br>
> should be frozen and deprecated. It does nothing but complicate Nova<br>
> and present challenges for scaling.<br>
><br>
> That said, if it must stay as a feature, I don't think updating the<br>
> user_data should be a priority. At that point, you've basically<br>
> created an entirely new server, and you can already do that by<br>
> creating an entirely new server.<br>
><br>
><br>
> If you've got a whole heat stack with multiple resources, and you realize that you messed up one thing in the template and one of your servers has the wrong personality/user_data, it can be useful to be able to rebuild that one server without affecting anything else in the stack. That's just a convenience though.<br>
><br>
> Chris<br>
><br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br>
<br>
------------------------------<br>
<br>
End of OpenStack-operators Digest, Vol 84, Issue 5<br>
******************************<wbr>********************<br>
</blockquote></div><br></div></div></div>