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, <openstack-operators-requ...@lists.openstack.org
> 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 new user_data during
> rebuild? (Clint Byrum)
> 4. Re: [nova] Should we allow passing new user_data during
> rebuild? (Clint Byrum)
> 5. Re: [nova] Should we allow passing new user_data during
> rebuild? (Clint Byrum)
> 6. Re: [nova] Should we allow passing new user_data during
> rebuild? (Tomáš Vondra)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 5 Oct 2017 12:59:33 +0000
> From: Tobias Urdin <tobias.ur...@crystone.com>
> To: "ulrich.her...@t-systems.com" <ulrich.her...@t-systems.com>
> Cc: "openstack-operators@lists.openstack.org"
> <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<mailto:
> 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 <ulrich.her...@t-systems.com><mailto:Ulrich.Herbst@t-
> systems.com>
> Cc: OpenStack Operators <openstack-operators@lists.openstack.org><mailto:
> 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, <ulrich.her...@t-systems.com<mailto:
> ulrich.her...@t-systems.com>> 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<mailto:OpenStack
> -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 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.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-operators/
> attachments/20171005/e288708d/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 5 Oct 2017 09:45:31 -0400
> From: Brian Rosmaita <rosmaita.foss...@gmail.com>
> To: OpenStack Operators List <openstack-operators@lists.openstack.org>
> Subject: Re: [Openstack-operators] [glance-survey]
> specify-an-image-ID-at-image-creation survey
> Message-ID:
> <CAFnESPo7LhGOwRy8NDTCw+wGb2d_SmYGhFq3VPpY_+9ja=WUeA@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
> <rosmaita.foss...@gmail.com> 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
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 05 Oct 2017 09:41:00 -0700
> From: Clint Byrum <cl...@fewbar.com>
> To: openstack-operators <openstack-operators@lists.openstack.org>
> Subject: Re: [Openstack-operators] [nova] Should we allow passing new
> user_data during rebuild?
> Message-ID: <1507221103-sup-2...@fewbar.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 05 Oct 2017 09:41:43 -0700
> From: Clint Byrum <cl...@fewbar.com>
> To: openstack-operators <openstack-operators@lists.openstack.org>
> Subject: Re: [Openstack-operators] [nova] Should we allow passing new
> user_data during rebuild?
> Message-ID: <1507221668-sup-1...@fewbar.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 05 Oct 2017 09:49:39 -0700
> From: Clint Byrum <cl...@fewbar.com>
> To: openstack-operators <openstack-operators@lists.openstack.org>
> Subject: Re: [Openstack-operators] [nova] Should we allow passing new
> user_data during rebuild?
> Message-ID: <1507221706-sup-9...@fewbar.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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 <
> chris.frie...@windriver.com> 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
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 6 Oct 2017 12:06:45 +0200
> From: Tomáš Vondra <von...@homeatcloud.cz>
> To: "'openstack-operators'" <openstack-operators@lists.openstack.org>
> Subject: Re: [Openstack-operators] [nova] Should we allow passing new
> user_data during rebuild?
> Message-ID: <095601d33e8a$d279c140$776d43c0$@homeatcloud.cz>
> Content-Type: text/plain; charset="utf-8"
>
> 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 <
> chris.frie...@windriver.com> 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
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> ------------------------------
>
> End of OpenStack-operators Digest, Vol 84, Issue 5
> **************************************************
>
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
