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