On 02/04/2013 08:47 PM, Chiradeep Vittal wrote:
I like cloud-init as well, but it sounds to me that we are hurting the
investment of existing CloudStack users who have built hundreds of
templates with the extant scripts.
We should ofcourse not break existing setups, their scripts should keep
working.
But, if we start packaging these scripts in DEB/RPM packages new comers
will start to use them as well while cloud-init is probably much better
to use when you have a fresh start.
Wido
On 2/4/13 10:51 AM, "Ahmad Emneina" <aemne...@gmail.com> wrote:
+1 cloud-init is the way to go IMO. It's also supported as long as the vm
can query its respective virtual router/dhcp server, since thats where
cloudstack places the user/meta data.
On Mon, Feb 4, 2013 at 3:35 AM, Wido den Hollander <w...@widodh.nl> wrote:
On 02/03/2013 12:44 PM, David Nalley wrote:
Hi folks:
One of the discussions that came up while we were in Ghent was whether
or not to package the SSH key reset and password reset utilities, or
whether we should focus our PW/SSH efforts on cloud-init.
The points for consideration are essentially:
* If we begin packaging them, they will be expected to be maintained
over the long term - are we as a project ready to do that?
* Do we keep the scripts in the repo, or perhaps consider adding a
separate repo for the scripts themselves. (This would make it easier
for distribution packagers to consume - and even if they don't wish to
package all of CloudStack - packaging the scripts themselves would be
substantially easier.
* cloud-init has CloudStack support IIRC, does it make sense to adopt
that rather than doing our own thing, or perhaps to elect one as the
primary method.
+1 cloud-init
We want CloudStack to be accepted by more and more users and they
probably
want to use cloud-init.
cloud-init has cool Puppet and Chef plugins as well which make it very
easy to get it all up and running.
Do we have full cloud-init support yet? Are we able to pass "User Data"
to
a VM?
I think it would be wise to support cloud-init and do not use our own
custom, homegrown scripts.
This makes it also easier for companies to make templates which work on
OpenStack and CloudStack. Interoperability!
Wido
