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

[Clint Byrum]

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

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

[Clint Byrum]

Excerpts from Chris Friesen's message of 2017-10-04 09:15:28 -0600:
> 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.
> 

If you just changed that personality/user_data in the template, Heat
would spin up a new one, change all the references to it, wait for any
wait conditions to fire, allowing dependent servers to reconfigure with
the new one and acknowledge that, and then delete the old one for you.

Making your app work like this means being able to replace failed or
undersized servers with less downtime. You can do other things too,
like spin up a replacement in a different AZ to deal with maintenance
issues on your side or the cloud's side. Or you can deploy a new image,
without any downtime.

My point remains: rebuild (and resize) train users to see a server as
precious, instead of training users to write automation that expects
cloud servers to come and go often.

This, btw, is one reason I like that EC2 calls them _instances_ and not
_servers_. They're not servers. We call them servers, but they're just
little regions of memory on actual servers, and as such, they're not
precious, and should be discarded as necessary.

___
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]

Excerpts from Belmiro Moreira's message of 2017-10-04 17:33:40 +0200:
> 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.
> 

Indeed, it sounds like we're too far down the rabbit hole with rebuild to
stop digging.

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

Re: [Openstack-operators] [glance-survey] specify-an-image-ID-at-image-creation survey

[Brian Rosmaita]

Here are the results of the survey:

OpenStack Glance specify-an-image-ID-at-image-creation survey

This is a quick survey to find out how many people use the ability to
specify a specific image_id at the time of image creation in Glance.

Note that if you manage multiple clouds, you can fill this out
multiple times with information about each.  We encourage you to do so
to help us get an accurate idea of how widely this feature is used.

Thanks in advance for your help!

This survey closes at 23:59 UTC on Tuesday 3 October 2017.

Responses: 8 (1 response == 12.5%)

Size of deployment (in tenants):
small (1-10): 0%
medium (11-100): 12.5%
large (101-1000): 62.5%
XL (1001+): 25%

As an operator, do you use the functionality that allows you to set an
image to a specific image_id upon image creation?
yes: 12.5%
no: 87.5%

Do you know if your end users use this functionality?
yes: 12.5%
no: 50%
don't know: 37.5%

Are you aware of OSSN-0075, that explains how this functionality is a
security problem?
Yes, I already knew about it: 50%
No, I wasn't aware (but I am now!): 50%

If a policy were introduced to govern this functionality, what would you do?
Leave the policy unrestricted, I don't need to purge my database: 0%
Leave the policy unrestricted, I can trust my users not to try the
OSSN-0075 exploit: 0%
Leave the policy unrestricted because my users rely on this functionality: 0%
Restrict usage to admin users only: 12.5%
Restrict usage to admin users and other specific trusted users: 50%
Restrict usage completely (allow none), we don't need this functionality: 37.5%

Does it bother you that if a policy were introduced to govern this
functionality, it could present an interoperability problem?
It bothers me, but I don't think this is a widely-used functionality,
so it's OK: 12.5%
It bothers me, but security trumps interoperability in this case, so
it's OK: 75%
It bothers me enough that I'd prefer that this not be fixed by
introducing a policy, even if that means not fixing it at all: 0%
It bothers me enough that I'd prefer this be fixed by disallowing the
functionality completely so that it could not be used by any user
(even an admin) in any cloud: 12.5%

-- end --


On Thu, Sep 28, 2017 at 6:48 PM, Brian Rosmaita
 wrote:
> The Glance spec freeze is coming up soon and we could use operator
> input on a proposal to govern a currently unrestricted functionality
> by policy.  The survey is 6 multiple choice questions and closes at
> 23:59 UTC on Tuesday 3 October 2017, so please fill it out right away.
>
> The purpose of the survey is to gather data concerning how many people
> use the ability to specify a specific image_id at the time of image
> creation in Glance -- so even if you've never heard of this
> functionality (and hence have never used it), it would be helpful for
> you to fill out the survey because you will give us a data point.
>
> https://goo.gl/forms/1dATtCW6V0xExRc22
>
> Thanks for your help!
> The Glance Team

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

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

[Tobias Urdin]

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 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 

Cc: OpenStack Operators 

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
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 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.



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.



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.

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

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

[Ulrich.Herbst]

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 
Cc: OpenStack Operators 
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
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 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.



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.



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.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Justin Cattle]

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
> 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 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. 

 

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.

 

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.
___
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?

[Tomáš Vondra]

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

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

[Ulrich.Herbst]

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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators