<div dir="ltr">Steve & Clint<div><br></div><div>That should work. We will look at implementing a resource that spins up a shortlived VM for bootstrapping a service VM and informing configuration server for further configuration. </div>
<div><br></div><div>thanks</div><div>prasadv</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 15, 2014 at 7:53 PM, Steven Dake <span dir="ltr"><<a href="mailto:sdake@redhat.com" target="_blank">sdake@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 01/14/2014 09:27 PM, Clint Byrum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Excerpts from Prasad Vellanki's message of 2014-01-14 18:41:46 -0800:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Steve<br>
<br>
I did not mean to have custom solution at all. In fact that would be<br>
terrible.  I think Heat model of software config and deployment is really<br>
good. That allows configurators such as Chef, Puppet, Salt or Ansible to be<br>
plugged into it and all users need to write are modules for those.<br>
<br>
What I was  thinking is if there is a way to use software config/deployment<br>
  to do initial configuration of the appliance by using agentless system<br>
such  as Ansible or Salt, thus requiring no cfminit. I am not sure this<br>
will work either, since it might require ssh keys to be installed for<br>
getting ssh to work without password prompting. But I do see that ansible<br>
and salt support username/password option.<br>
If this would not work, I agree that the best option is to make them<br>
support cfminit...<br>
</blockquote>
Ansible is not agent-less. It just makes use of an extremely flexible<br>
agent: sshd. :) AFAIK, salt does use an agent though maybe they've added<br>
SSH support.<br>
<br>
Anyway, the point is, Heat's engine should not be reaching into your<br>
machines. It talks to API's, but that is about it.<br>
<br>
What you really want is just a VM that spins up and does the work for<br>
you and then goes away once it is done.<br>
</blockquote></div>
Good thinking.  This model might work well without introducing the "groan another daemon" problems pointed out elsewhere in this thread that were snipped.  Then the "modules" could simply be heat templates available to the Heat engine to do the custom config setup.<br>

<br>
The custom config setup might still be a problem with the original constraints (not modifying images to inject SSH keys).<br>
<br>
That model wfm.<br>
<br>
Regards<br>
-steve<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>