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 <sd...@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 > > > _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
