[openstack-dev] [heat] Sofware Config progress
Steven Dake
sdake at redhat.com
Thu Jan 16 03:53:26 UTC 2014
On 01/14/2014 09:27 PM, Clint Byrum wrote:
> Excerpts from Prasad Vellanki's message of 2014-01-14 18:41:46 -0800:
>> Steve
>>
>> I did not mean to have custom solution at all. In fact that would be
>> terrible. I think Heat model of software config and deployment is really
>> good. That allows configurators such as Chef, Puppet, Salt or Ansible to be
>> plugged into it and all users need to write are modules for those.
>>
>> What I was thinking is if there is a way to use software config/deployment
>> to do initial configuration of the appliance by using agentless system
>> such as Ansible or Salt, thus requiring no cfminit. I am not sure this
>> will work either, since it might require ssh keys to be installed for
>> getting ssh to work without password prompting. But I do see that ansible
>> and salt support username/password option.
>> If this would not work, I agree that the best option is to make them
>> support cfminit...
> Ansible is not agent-less. It just makes use of an extremely flexible
> agent: sshd. :) AFAIK, salt does use an agent though maybe they've added
> SSH support.
>
> Anyway, the point is, Heat's engine should not be reaching into your
> machines. It talks to API's, but that is about it.
>
> What you really want is just a VM that spins up and does the work for
> you and then goes away once it is done.
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.
The custom config setup might still be a problem with the original
constraints (not modifying images to inject SSH keys).
That model wfm.
Regards
-steve
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list