----- Original Message ----- > From: "Bob Doolittle" <b...@doolittle.us.com> > To: "Simone Tiraboschi" <stira...@redhat.com>, de...@ovirt.org, "users-ovirt" > <users@ovirt.org> > Cc: "Fabian Deutsch" <fdeut...@redhat.com> > Sent: Thursday, March 12, 2015 3:54:27 PM > Subject: Re: [ovirt-devel] oVirt node, hosted-engine, oVirt appliance and > cloud-init > > On 03/12/2015 10:02 AM, Simone Tiraboschi wrote: > > Hi all, > > cloud-init is a powerful tool to configure from outside a cloud instance or > > an appliance as in our scenario. > > > > Deploying the engine as an appliance is indeed a good way to speed up and > > make easier the hosted-engine deployment: you don't need to install an OS > > on the engine virtual machine and than install the engine and so on but > > you could simply run a ready to use oVirt engine appliance. But you still > > need to configure it and so cloud-init support within hosted-engine is a > > reasonable way to complement it. > > > > Then we could also integrate it with oVirt node to let the user input the > > required info from node TUI in order to have an almost unattended > > hosted-engine setup on oVirt node using an engine appliance with > > cloud-init. > > > > The idea is to collect the required information interactively from > > hosted-engine setup or from node TUI (passing them to hosted-engine setup > > via an answer file) and pass them to the appliance via cloud-init using a > > no-cloud datasource. > > > > So now the question is what do you really want to configure via cloud-init? > > It's just to define what we want in order to be more focused on user needs: > > for instance we could configure engine VM instance hostname, we could set > > the root password, we could create other users, we could upload ssh > > private keys, we could run a command on the first boot and so on. > > So, if you have any ideas or requirement about that it's the right time for > > it. > > Great suggestions, Simone! > > The things you list cover most of what I do to the engine VM (I do all of > those except for "configure ssh private keys"). In addition, I: > > * Add a couple of packages (e.g. zsh) > * Configure alternate shells for some initial users (this could be "run a > command on the first boot", as long as adding the necessary packages was > done before that somehow, perhaps simply as a prior command) > * Populate some specific files, e.g.: > o Add specific ssh *public* keys into the $HOME/.ssh/authorized_keys > files for some user and root accounts > o Replace /etc/hosts with a master copy that contains all hosts on my > network > > > I'd like to see the "additional packages" abstracted out somehow and added > prior to the "run a command on the first boot" step, as opposed to using > "yum" explicitly for one of those commands, but that's somewhat of a > cosmetic "nice to have" since obviously it can be done explicitly. It's > separate conceptually, so would be nice to treat as such.
It's already designed like that in cloud-init: http://cloudinit.readthedocs.org/en/latest/topics/examples.html#install-arbitrary-packages > I'm learning Puppet at the moment, and it strikes me that what you want to do > is pretty much the same thing that Puppet manifests are designed to do. You could also setup an run puppet from cloud-init: http://cloudinit.readthedocs.org/en/latest/topics/examples.html#setup-and-run-puppet > Thanks, > Bob > > > > > thanks, > > Simone > > > > > > > > > > _______________________________________________ > > Devel mailing list > > de...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users