4:02 p.m.
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.
thanks,
Simone
4:54 p.m.
This is a multi-part message in MIME format.
--------------070400040605090801030307
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
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.
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.
Thanks,
Bob
thanks,
Simone
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--------------070400040605090801030307
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
On 03/12/2015 10:02 AM, Simone Tiraboschi wrote:<br>
<blockquote
cite=3D"mid:1957349372.20499494.1426168924455.JavaMail.zimbra@redha=
t.com"
type=3D"cite">
<pre wrap=3D"">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 O=
S 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 stil=
l 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 a=
n answer file) and pass them to the appliance via cloud-init using a no-c=
loud datasource.
So now the question is what do you really want to configure via cloud-ini=
t?
It's just to define what we want in order to be more focused on user need=
s:
for instance we could configure engine VM instance hostname, we could set=
the root password, we could create other users, we could upload ssh priv=
ate 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 f=
or it.</pre>
</blockquote>
<br>
Great suggestions, Simone!<br>
<br>
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:<br>
<br>
<ul>
<li>Add a couple of packages (e.g. zsh)</li>
<li>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)<br>
</li>
<li>Populate some specific files, e.g.:<br>
</li>
<ul>
<li>Add specific ssh *public* keys into the
$HOME/.ssh/authorized_keys files for some user and root
accounts</li>
<li>Replace /etc/hosts with a master copy that contains all
hosts on my network<br>
</li>
</ul>
</ul>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
=A0=A0 Bob<br>
<br>
<blockquote
cite=3D"mid:1957349372.20499494.1426168924455.JavaMail.zimbra@redha=
t.com"
type=3D"cite">
<pre wrap=3D"">
thanks,
Simone
_______________________________________________
Devel mailing list
<a class=3D"moz-txt-link-abbreviated"
href=3D"mailto:Devel@ovirt.org">Dev=
el(a)ovirt.org</a>
<a class=3D"moz-txt-link-freetext"
href=3D"http://lists.ovirt.org/mailman=
/listinfo/devel">http://lists.ovirt.org/mailman/listinfo/devel</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------070400040605090801030307--
5 p.m.
----- Original Message -----
From: "Bob Doolittle" <bob(a)doolittle.us.com>
To: "Simone Tiraboschi" <stirabos(a)redhat.com>, devel(a)ovirt.org,
"users-ovirt" <users(a)ovirt.org>
Cc: "Fabian Deutsch" <fdeutsch(a)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-a...
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...
Thanks,
Bob
>
> thanks,
> Simone
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
9:53 p.m.
Hi
First of all I think cloud-init is optional so user can select if use it or not.
So if somebody wants to deploy hosted engine the hard way by installing it on OS , its his
choice allowed too.
For our appliance I dont think we need anything except for root password.
Last option is in case somebody have some complicated net config he needs to implement in
the engine VM on the first run
we should allow him the option to provide the cloud-init iso by himself and he can define
all he wants there.
Tolik.
----- Original Message -----
From: "Simone Tiraboschi" <stirabos(a)redhat.com>
To: devel(a)ovirt.org, "users-ovirt" <users(a)ovirt.org>
Cc: "Fabian Deutsch" <fdeutsch(a)redhat.com>, "Tolik Litovsky"
<tlitovsk(a)redhat.com>
Sent: Thursday, 12 March, 2015 4:02:04 PM
Subject: oVirt node, hosted-engine, oVirt appliance and cloud-init
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.
thanks,
Simone
3:38 p.m.
On Mar 13, 2015, at 20:53 , Tolik Litovsky <tlitovsk(a)redhat.com> wrote:
Hi
First of all I think cloud-init is optional so user can select if use it or not.
So if somebody wants to deploy hosted engine the hard way by installing it on OS , its
his choice allowed too.
in this case you can require the user to pre-install the cloud-init rpm or use a
cloud-ready images
we use this approach for neutron appliance, though, to be fair…last time I tried it on the
latest image cloud-init just doesn't work:) it's not really a rock-solid
thingie…but in normal conditions it seems to work, more or less.
virt-sysprep is another way, not requiring and guest-side cooperation
Thanks,
michal
For our appliance I dont think we need anything except for root
password.
Last option is in case somebody have some complicated net config he needs to implement in
the engine VM on the first run
we should allow him the option to provide the cloud-init iso by himself and he can define
all he wants there.
Tolik.
----- Original Message -----
> From: "Simone Tiraboschi" <stirabos(a)redhat.com>
> To: devel(a)ovirt.org, "users-ovirt" <users(a)ovirt.org>
> Cc: "Fabian Deutsch" <fdeutsch(a)redhat.com>, "Tolik
Litovsky" <tlitovsk(a)redhat.com>
> Sent: Thursday, 12 March, 2015 4:02:04 PM
> Subject: oVirt node, hosted-engine, oVirt appliance and cloud-init
>
> 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.
>
> thanks,
> Simone
>
>
>
>
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
3329
days inactive
3333
days old
4 comments
4 participants
participants (4)
-
Bob Doolittle -
Michal Skrivanek -
Simone Tiraboschi -
Tolik Litovsky