[openstack-dev] [heat] Sofware Config progress [for appliances]

Prasad Vellanki prasad.vellanki at oneconvergence.com
Fri Feb 7 03:18:50 UTC 2014


On Thu, Feb 6, 2014 at 1:19 AM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Mike Spreitzer's message of 2014-02-05 22:17:50 -0800:
> > > 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?
> >
>
> The heat-engine that takes over the stack. Same as the answer for what
> happens when a stack is half-created and heat-engine dies.
>
> > (2) What if something goes wrong and the heat engine never gets the
> signal
> > it is waiting for?
> >
>
> Timeouts already cause failed state or rollback.
>
> > (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).
> >
>
> The usual answer is "that's cloud-init's job" but we're discussing
> working around not having cloud-init, so I suspect it has to be built
> into the image (which, btw, is a really really bad idea). Another option
> is that these weird proprietary systems might reach out to an auth
> service which the short-lived VM would also be able to contact given
> appropriate credentials for said auth service fed in via parameters.
>
> The idea I thought was that the short lived VM will act as a proxy to the
configuration engine such as Puppet or chef to bootstrap ie get the
credentials for appliance. Once the initial bootstrap is done, then regular
configuration process as suggested by Heat will work.

Though I had one question as to how heat will send configuration
information to puppet or chef that configures the VM in tenant domain.
Assuming that the chef or puppet can be reachable from tenant VM, how does
heat reach chef server.

One scenario  that needs a little thought is if the service VM is actually
owned by the provider but is  invoked in the tenant domain. The management
of such will come  via Neutron API but then on the backend driver for that
service will configure the service VM. It would be great if Heat is used
for this.

> (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?
> >
>
> We can, and should, poke holes from heat-engine, out through a firewall,
> so it can connect to all of the endpoints. However, if we start letting
> it talk to all the managed machines, it becomes a really handy DoS tool
> and also spends a ton of time talking to things that we have no control
> over, thus taking up resources to an unknown degree.
>


>
> Heat-engine is precious, it has access to a database with a ton of really
> sensitive information. It is also expensive when heat-engine dies (until
> we can make all tasks distributed) as it may force failure states. So
> I think we need to be very careful about what we let it do.
>
> > (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?
> >
>
> No. We are suggesting a solution to their unique problem of having to
> talk to said API/special command language/telnet/IP-over-avian-carrier.
> The short-lived VM can just have a UserData section which does all of
> this really.
>
> I think long term cfm utils should be the method for bootstrapping any VM.
I think appliances will support that as they become cloud friendly. In the
interim this can be used as a solution.


> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140206/6f975faf/attachment.html>


More information about the OpenStack-dev mailing list