Re: [Openstack-operators] [openstack-dev] [nova] Should we make rebuild + new image on a volume-backed instance fail fast?

[Matt Riedemann]

On 10/6/2017 1:10 PM, Mathieu Gagné wrote:

I don't think there ever was a technical limitation to add support for it.


See the review comments with the -1 votes on the patches I linked 
originally.


There are valid technical reasons for the -1s on those, including on 
this one from Paul Murray - who spent more time than probably anyone 
trying to get nova to support detach/attach root volumes:


https://review.openstack.org/#/c/201458/

Quoth Dr Murray:

"There is actually a lot more to this than detaching and attaching the 
volume - doing that alone is unsafe because the rest of the code assumes 
there is a root device. So if nova tries to do anything with the 
instance when the volume is detached it will probably fail and to error 
(e.g. delete, migrate, resize, start). All of these cases have to be 
fixed as well as the volume. We also need to make sure that only another 
volume can be attached or handle the case for swapping in any kind of 
storage device (an image on ephemeral disk for example)."


I'm fine with people wanting to resume his old spec and code if someone 
wants to own that, but I can't say it's going to be a review priority.


--

Thanks,

Matt

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Matt Riedemann]

On 10/6/2017 1:30 PM, Joshua Harlow wrote:

+1

I am also personally frustrated by the same thing clint is,

It seems that somewhere along the line we lost the direction of cloud vs 
VPS, and somewhere it was sold (or not sold) that openstack is good for 
both (when it really isn't imho),


http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/

C'est la vie :-/


I get it, but in this case the ship has sailed on rebuild. People are 
using it. It's been around forever.


The point of the question that started this thread is really, do we 
allow this minor thing to come into the API (user_data) to replace 
something we're removing from the API (personality files).


In the grand scheme of things, this is not going to make or break 
anything probably, it might make some users happy but I certainly don't 
think it's a monumental step in supporting pets.


Completely new API workflows like built-in instance HA or something like 
that to Nova would be spending a lot of time and resource on supporting 
pets within Nova, and this isn't that thing.


--

Thanks,

Matt

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nova] Looking for feedback on a spec to limit max_count in multi-create requests

[Matt Riedemann]

I've been chasing something weird I was seeing in devstack when creating 
hundreds of instances in a single request where at some limit, things 
blow up in an unexpected way during scheduling and all instances were 
put into ERROR state. Given the environment I was running in, this 
shouldn't have been happening, and today we figured out what was 
actually happening. To summarize, we retry scheduling requests on RPC 
timeout so you can have scheduler_max_attempts greenthreads running 
concurrently trying to schedule 1000 instances and melt your scheduler.


I've started a spec which goes into the details of the actual issue:

https://review.openstack.org/#/c/510235/

It also proposes a solution, but I don't feel it's the greatest 
solution, so there are also some alternatives in there.


I'm really interested in operator feedback on this because I assume that 
people are dealing with stuff like this in production already, and have 
had to come up with ways to solve it.


--

Thanks,

Matt

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Joshua Harlow]

+1

I am also personally frustrated by the same thing clint is,

It seems that somewhere along the line we lost the direction of cloud vs 
VPS, and somewhere it was sold (or not sold) that openstack is good for 
both (when it really isn't imho),


http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/

C'est la vie :-/

Clint Byrum wrote:

Thanks Tomas, I did understand you, I just didn't make my point perfectly.

The point is that OpenStack has two very different missions today, and
that is causing my frustration and I have let that go for now. There
is a hosting mission, where we try to keep computing pets alive, and a
cloud mission, where we try to give people flexible access to computing
resources at scale to use as cattle.

I've done a poor job of acknowledging those who use OpenStack for hosting,
and I'm trying to get better. Thanks for being a user!

Excerpts from Tomáš Vondra's message of 2017-10-06 12:06:45 +0200:

Dear Clint,
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.
Tomas from Homeatcloud

-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: Thursday, October 05, 2017 6:50 PM
To: openstack-operators
Subject: Re: [Openstack-operators] [nova] Should we allow passing new user_data 
during rebuild?

No offense is intended, so please forgive me for the possibly incendiary nature 
of what I'm about to write:

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.

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.

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.

You can all consider this my white flag. :)

Excerpts from Tomáš Vondra's message of 2017-10-05 10:22:14 +0200:

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.

BTW, you wouldn’t believe how often people use the Reinstall feature.

Tomas from Homeatcloud



From: Belmiro Moreira [mailto:moreira.belmiro.email.li...@gmail.com]
Sent: Wednesday, October 04, 2017 5:34 PM
To: Chris Friesen
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [nova] Should we allow passing new user_data 
during rebuild?



In our cloud rebuild is the only way for a user to keep the same IP. 
Unfortunately, we don't offer floating IPs, yet.

Also, we use the user_data to bootstrap some actions in new instances (puppet, 
...).

Considering all the use-cases for rebuild it would be great if the user_data 
can be updated at rebuild time.



On Wed, Oct 4, 2017 at 5:15 PM, Chris Friesen  
wrote:

On 10/03/2017 11:12 AM, Clint Byrum wrote:

My personal opinion is that rebuild is an anti-pattern for cloud, and
should be frozen and deprecated. It does nothing but complicate Nova
and present challenges for scaling.

That said, if it must stay as a feature, I don't think updating the
user_data should be a priority. At that point, you've basically
created an entirely new server, and you can already do that by
creating an entirely new server.


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.

Chris

Re: [Openstack-operators] [openstack-dev] [nova] Should we make rebuild + new image on a volume-backed instance fail fast?

[Mohammed Naser]

On Fri, Oct 6, 2017 at 1:32 PM, Mathieu Gagné  wrote:
> Why not supporting this use case?
>
> Same reason as before: A user might wish to keep its IP addresses.
>
> The use cannot do the following to bypass the limitation:
> 1) stop instance
> 2) detach root volume
> 3) delete root volume
> 4) create new volume
> 5) attach as root
> 6) boot instance
>
> Last time I tried, operation fails at step 2. I would need to test
> against latest version of Nova to confirm.

You are right, this is indeed something that is not possible.

> Otherwise boot-from-volume feels like a second class citizen.
>
> --
> Mathieu
>
>
> On Fri, Oct 6, 2017 at 1:22 PM, Matt Riedemann  wrote:
>> This came up in IRC discussion the other day, but we didn't dig into it much
>> given we were all (2 of us) exhausted talking about rebuild.
>>
>> But we have had several bugs over the years where people expect the root
>> disk to change to a newly supplied image during rebuild even if the instance
>> is volume-backed.
>>
>> I distilled several of those bugs down to just this one and duplicated the
>> rest:
>>
>> https://bugs.launchpad.net/nova/+bug/1482040
>>
>> I wanted to see if there is actually any failure on the backend when doing
>> this, and there isn't - there is no instance fault or anything like that.
>> It's just not what the user expects, and actually the instance image_ref is
>> then shown later as the image specified during rebuild, even though that's
>> not the actual image in the root disk (the volume).
>>
>> There have been a couple of patches proposed over time to change this:
>>
>> https://review.openstack.org/#/c/305079/
>>
>> https://review.openstack.org/#/c/201458/
>>
>> https://review.openstack.org/#/c/467588/
>>
>> And Paul Murray had a related (approved) spec at one point for detach and
>> attach of root volumes:
>>
>> https://review.openstack.org/#/c/221732/
>>
>> But the blueprint was never completed.
>>
>> So with all of this in mind, should we at least consider, until at least
>> someone owns supporting this, that the API should fail with a 400 response
>> if you're trying to rebuild with a new image on a volume-backed instance?
>> That way it's a fast failure in the API, similar to trying to backup a
>> volume-backed instance fails fast.
>>
>> If we did, that would change the API response from a 202 today to a 400,
>> which is something we normally don't do. I don't think a microversion would
>> be necessary if we did this, however, because essentially what the user is
>> asking for isn't what we're actually giving them, so it's a failure in an
>> unexpected way even if there is no fault recorded, it's not what the user
>> asked for. I might not be thinking of something here though, like
>> interoperability for example - a cloud without this change would blissfully
>> return 202 but a cloud with the change would return a 400...so that should
>> be considered.
>>
>> --
>>
>> 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-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [nova] Should we make rebuild + new image on a volume-backed instance fail fast?

[Mathieu Gagné]

Why not supporting this use case?

Same reason as before: A user might wish to keep its IP addresses.

The use cannot do the following to bypass the limitation:
1) stop instance
2) detach root volume
3) delete root volume
4) create new volume
5) attach as root
6) boot instance

Last time I tried, operation fails at step 2. I would need to test
against latest version of Nova to confirm.

Otherwise boot-from-volume feels like a second class citizen.

--
Mathieu


On Fri, Oct 6, 2017 at 1:22 PM, Matt Riedemann  wrote:
> This came up in IRC discussion the other day, but we didn't dig into it much
> given we were all (2 of us) exhausted talking about rebuild.
>
> But we have had several bugs over the years where people expect the root
> disk to change to a newly supplied image during rebuild even if the instance
> is volume-backed.
>
> I distilled several of those bugs down to just this one and duplicated the
> rest:
>
> https://bugs.launchpad.net/nova/+bug/1482040
>
> I wanted to see if there is actually any failure on the backend when doing
> this, and there isn't - there is no instance fault or anything like that.
> It's just not what the user expects, and actually the instance image_ref is
> then shown later as the image specified during rebuild, even though that's
> not the actual image in the root disk (the volume).
>
> There have been a couple of patches proposed over time to change this:
>
> https://review.openstack.org/#/c/305079/
>
> https://review.openstack.org/#/c/201458/
>
> https://review.openstack.org/#/c/467588/
>
> And Paul Murray had a related (approved) spec at one point for detach and
> attach of root volumes:
>
> https://review.openstack.org/#/c/221732/
>
> But the blueprint was never completed.
>
> So with all of this in mind, should we at least consider, until at least
> someone owns supporting this, that the API should fail with a 400 response
> if you're trying to rebuild with a new image on a volume-backed instance?
> That way it's a fast failure in the API, similar to trying to backup a
> volume-backed instance fails fast.
>
> If we did, that would change the API response from a 202 today to a 400,
> which is something we normally don't do. I don't think a microversion would
> be necessary if we did this, however, because essentially what the user is
> asking for isn't what we're actually giving them, so it's a failure in an
> unexpected way even if there is no fault recorded, it's not what the user
> asked for. I might not be thinking of something here though, like
> interoperability for example - a cloud without this change would blissfully
> return 202 but a cloud with the change would return a 400...so that should
> be considered.
>
> --
>
> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nova] Should we make rebuild + new image on a volume-backed instance fail fast?

[Matt Riedemann]

This came up in IRC discussion the other day, but we didn't dig into it 
much given we were all (2 of us) exhausted talking about rebuild.


But we have had several bugs over the years where people expect the root 
disk to change to a newly supplied image during rebuild even if the 
instance is volume-backed.


I distilled several of those bugs down to just this one and duplicated 
the rest:


https://bugs.launchpad.net/nova/+bug/1482040

I wanted to see if there is actually any failure on the backend when 
doing this, and there isn't - there is no instance fault or anything 
like that. It's just not what the user expects, and actually the 
instance image_ref is then shown later as the image specified during 
rebuild, even though that's not the actual image in the root disk (the 
volume).


There have been a couple of patches proposed over time to change this:

https://review.openstack.org/#/c/305079/

https://review.openstack.org/#/c/201458/

https://review.openstack.org/#/c/467588/

And Paul Murray had a related (approved) spec at one point for detach 
and attach of root volumes:


https://review.openstack.org/#/c/221732/

But the blueprint was never completed.

So with all of this in mind, should we at least consider, until at least 
someone owns supporting this, that the API should fail with a 400 
response if you're trying to rebuild with a new image on a volume-backed 
instance? That way it's a fast failure in the API, similar to trying to 
backup a volume-backed instance fails fast.


If we did, that would change the API response from a 202 today to a 400, 
which is something we normally don't do. I don't think a microversion 
would be necessary if we did this, however, because essentially what the 
user is asking for isn't what we're actually giving them, so it's a 
failure in an unexpected way even if there is no fault recorded, it's 
not what the user asked for. I might not be thinking of something here 
though, like interoperability for example - a cloud without this change 
would blissfully return 202 but a cloud with the change would return a 
400...so that should be considered.


--

Thanks,

Matt

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Clint Byrum]

Thanks Tomas, I did understand you, I just didn't make my point perfectly.

The point is that OpenStack has two very different missions today, and
that is causing my frustration and I have let that go for now. There
is a hosting mission, where we try to keep computing pets alive, and a
cloud mission, where we try to give people flexible access to computing
resources at scale to use as cattle.

I've done a poor job of acknowledging those who use OpenStack for hosting,
and I'm trying to get better. Thanks for being a user!

Excerpts from Tomáš Vondra's message of 2017-10-06 12:06:45 +0200:
> Dear Clint,
> 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.
> Tomas from Homeatcloud
> 
> -Original Message-
> From: Clint Byrum [mailto:cl...@fewbar.com] 
> Sent: Thursday, October 05, 2017 6:50 PM
> To: openstack-operators
> Subject: Re: [Openstack-operators] [nova] Should we allow passing new 
> user_data during rebuild?
> 
> No offense is intended, so please forgive me for the possibly incendiary 
> nature of what I'm about to write:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> You can all consider this my white flag. :)
> 
> Excerpts from Tomáš Vondra's message of 2017-10-05 10:22:14 +0200:
> > 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.
> > 
> > BTW, you wouldn’t believe how often people use the Reinstall feature.
> > 
> > Tomas from Homeatcloud
> > 
> >  
> > 
> > From: Belmiro Moreira [mailto:moreira.belmiro.email.li...@gmail.com]
> > Sent: Wednesday, October 04, 2017 5:34 PM
> > To: Chris Friesen
> > Cc: openstack-operators@lists.openstack.org
> > Subject: Re: [Openstack-operators] [nova] Should we allow passing new 
> > user_data during rebuild?
> > 
> >  
> > 
> > In our cloud rebuild is the only way for a user to keep the same IP. 
> > Unfortunately, we don't offer floating IPs, yet.
> > 
> > Also, we use the user_data to bootstrap some actions in new instances 
> > (puppet, ...).
> > 
> > Considering all the use-cases for rebuild it would be great if the 
> > user_data can be updated at rebuild time.
> > 
> >  
> > 
> > On Wed, Oct 4, 2017 at 5:15 PM, Chris Friesen  
> > wrote:
> > 
> > On 10/03/2017 11:12 AM, Clint Byrum wrote:
> > 
> > My personal opinion is that rebuild is an anti-pattern for cloud, and 
> > should be frozen and deprecated. It does nothing but complicate Nova 
> > and present challenges for scaling.
> > 
> > That said, if it must stay as a feature, I don't think updating the 
> > user_data should be a priority. At that point, you've basically 
> > created an entirely new server, and you can already do that by 
> > creating an entirely new server.
> > 
> > 
> > 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.
> > 
> > Chris
> > 
> 
> ___
> 

Re: [Openstack-operators] [puppet] Where to start ?

[ijaz ahmad]

Hi ,

You can use alot of tools to create virtual machines in openstack.

The quick answers are:

  1. Terraform
  2. Ansible


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.


https://github.com/iahmad-khan/ai-tools

enjoy.

cheers
ijaz

On 6 October 2017 at 13:00,  wrote:

> Send OpenStack-operators mailing list submissions to
> openstack-operators@lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-operators
>
> or, via email, send a message with subject or body 'help' to
> openstack-operators-requ...@lists.openstack.org
>
> You can reach the person managing the list at
> openstack-operators-ow...@lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenStack-operators digest..."
>
>
> Today's Topics:
>
>1. Re: [puppet] Where to start ? (Tobias Urdin)
>2. Re: [glance-survey]   specify-an-image-ID-at-image-creation
>   survey (Brian Rosmaita)
>3. Re: [nova] Should we allow passing newuser_data during
>   rebuild? (Clint Byrum)
>4. Re: [nova] Should we allow passing newuser_data during
>   rebuild? (Clint Byrum)
>5. Re: [nova] Should we allow passing newuser_data during
>   rebuild? (Clint Byrum)
>6. Re: [nova] Should we allow passingnew user_data during
>   rebuild? (Tomáš Vondra)
>
>
> --
>
> Message: 1
> Date: Thu, 5 Oct 2017 12:59:33 +
> From: Tobias Urdin 
> To: "ulrich.her...@t-systems.com" 
> Cc: "openstack-operators@lists.openstack.org"
> 
> Subject: Re: [Openstack-operators] [puppet] Where to start ?
> Message-ID: <5346f8bb20a7461395a0c3a295d4f...@mb01.staff.ognet.se>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Ulrich,
>
>
> 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!
>
> I think what you are looking for is something like this:
> https://github.com/puppetlabs/puppetlabs-node_openstack
>
> 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.
>
>
> Or any other tool for that matter, Terraform, vagrant or whatever
> depending on your requirements.
>
> Best regards
>
> On 10/05/2017 12:04 PM, ulrich.her...@t-systems.com ulrich.her...@t-systems.com> wrote:
> Hi all,
>
> sorry for asking unprecise questions.
>
> 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)
>
> Uli
>
> Von: Justin Cattle [mailto:j...@ocado.com]
> Gesendet: Donnerstag, 5. Oktober 2017 11:52
> An: Herbst, Ulrich  systems.com>
> Cc: OpenStack Operators  openstack-operators@lists.openstack.org>
> Betreff: Re: [Openstack-operators] [puppet] Where to start ?
>
> Running puppet on openstack instances is no different than running puppet
> on bare metal, or elsewhere.
> 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 :)
>
>
>
>
>
> Cheers,
> Just
>
> On 5 October 2017 at 08:30, > wrote:
> Dear list,
>
> I'm new on an (existing) OpenStack "cloud" and have to deploy some VMs
> there.
>
> I'm experienced with puppet and want to use that to automatically deploy
> VMs (and install software there).
>
> I know about https://docs.openstack.org/puppet-openstack-guide/latest/ -
> but don't see a point where to start.
>
> Do you have any pointers, links, tutorials, documentation for me where/how
> to start ?
>
> I'm not interested in deploying the OpenStack infrastructure itself.
>
> Thank you
> Uli
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org -operat...@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> 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.
>
>
>
> If you are not 

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

[Tomáš Vondra]

Dear Clint,
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.
Tomas from Homeatcloud

-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com] 
Sent: Thursday, October 05, 2017 6:50 PM
To: openstack-operators
Subject: Re: [Openstack-operators] [nova] Should we allow passing new user_data 
during rebuild?

No offense is intended, so please forgive me for the possibly incendiary nature 
of what I'm about to write:

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.

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.

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.

You can all consider this my white flag. :)

Excerpts from Tomáš Vondra's message of 2017-10-05 10:22:14 +0200:
> 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.
> 
> BTW, you wouldn’t believe how often people use the Reinstall feature.
> 
> Tomas from Homeatcloud
> 
>  
> 
> From: Belmiro Moreira [mailto:moreira.belmiro.email.li...@gmail.com]
> Sent: Wednesday, October 04, 2017 5:34 PM
> To: Chris Friesen
> Cc: openstack-operators@lists.openstack.org
> Subject: Re: [Openstack-operators] [nova] Should we allow passing new 
> user_data during rebuild?
> 
>  
> 
> In our cloud rebuild is the only way for a user to keep the same IP. 
> Unfortunately, we don't offer floating IPs, yet.
> 
> Also, we use the user_data to bootstrap some actions in new instances 
> (puppet, ...).
> 
> Considering all the use-cases for rebuild it would be great if the user_data 
> can be updated at rebuild time.
> 
>  
> 
> On Wed, Oct 4, 2017 at 5:15 PM, Chris Friesen  
> wrote:
> 
> On 10/03/2017 11:12 AM, Clint Byrum wrote:
> 
> My personal opinion is that rebuild is an anti-pattern for cloud, and 
> should be frozen and deprecated. It does nothing but complicate Nova 
> and present challenges for scaling.
> 
> That said, if it must stay as a feature, I don't think updating the 
> user_data should be a priority. At that point, you've basically 
> created an entirely new server, and you can already do that by 
> creating an entirely new server.
> 
> 
> 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.
> 
> Chris
> 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators