Open Stack

> From: Prasad Vellanki <prasad.vellanki at oneconvergence.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>, 
> Date: 01/21/2014 02:16 AM
> Subject: Re: [openstack-dev] [heat] Sofware Config progress
> 
> Steve & Clint
> 
> 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. 
> 
> thanks
> prasadv
> 

> On Wed, Jan 15, 2014 at 7:53 PM, Steven Dake <sdake at redhat.com> wrote:
> 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
> 

(1) What destroys the short-lived VM if the heat engine crashes between 
creating and destroying that short-lived VM?

(2) What if something goes wrong and the heat engine never gets the signal 
it is waiting for?

(3) This still has the problem that something needs to be configured 
some(client-ish)where to support the client authorization solution 
(usually username/password).

(4) Given that everybody seems sanguine about solving the client 
authorization problem, what is wrong with code in the heat engine opening 
and using a connection to code in an appliance?  Steve, what do you mean 
by "reaching into your machines" that is critically different from calling 
their APIs?

(5) Are we really talking about the same kind of software configuration 
here?  Many appliances do not let you SSH into a bash shell and do 
whatever you want; they provide only their own API or special command 
language over a telnet/ssh sort of connection.  Is hot-software-config 
intended to cover that?  Is this what the OneConvergence guys are 
concerned with?

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140206/797fe348/attachment.html>