On 02/05/2013 08:10 PM, Kelven Yang wrote:
On 2/5/13 11:02 AM, "Wido den Hollander" <w...@widodh.nl> wrote:
On 02/04/2013 11:18 PM, Kelven Yang wrote:
On 2/4/13 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.
Generally agree that if possible we should adopt third-party solution in
stead of to do everything ourselves. One thing to add is that does the
solution comes with support to Windows VM? We had a special package that
is for windows VM on password-reset.
Well, I guess that works the same way as the current scripts do? So we
should not break that.
The password-reset client script and Windows password-reset service use
customized protocol to talk to the password provider, replacement of the
facility will need these client-side tools to cooperate with, is there any
details on these tools we are talking about so that we can evaluate the
impact and feasible solutions?
What I meant is that the current scripts (both Linux AND Windows) should
keep working.
While they work we should provide methods to get cloud-init working and
actually promote that.
We should NOT break existing setups, but also not encourage users to
start using these scripts on new systems.
Wido
-Kelven
Wido
Kelven
This makes it also easier for companies to make templates which work on
OpenStack and CloudStack. Interoperability!
Wido
