VM lifecycle management using Salt.

[ed.lane]

There seems to be a plethora of ways in SaltStack for creating/managing/destroying VMs.

Here are some methods I have uncovered using SaltStack (not exhaustive):

salt-cloud ( CLI)

cloud (execution module)

cloud (state module)

virt (execution module)

other methods:

salt-vagrant

I am also guilty of creating additional methods of managing cloud specific VMs by writing a custom CloudStack/SaltStack execution module.

Can you provide some general guidance for VM orchestration and lifecycle orchestration?

Is there a generally preferred approach?

Is the Salt state system thought to be too clumsy for managing VM creation/destruction so all these additional methods had to be added?

Is VM lifecycle management not sufficiently standardized to allow a common API abstraction across all clouds and virtualization techniques?

-ed lane

Verio, Inc.

[Joseph Hall]

Hi Ed,

The cloud execution module is a wrapper around the salt-cloud
libraries. It is not yet complete (note that it is only in the develop
branch). The cloud state module is a wrapper around the cloud
execution module. It is also not yet complete (for the same reasons).
The virt execution module is a wrapper around libvirt and ESXi.
Whereas the cloud stuff interacts with existing cloud interfaces, the
virt module is essentially a small, private cloud controller. It has
been present for several months.

If you want to dig a little, there is a CloudAPI, which is also new
enough that it is probably not yet documented (nor is it, or the cloud
execution and state modules, in any official release). There is also a
CloudClient, which is similar to Salt's own LocalClient, which is in
the same status (no official release, but the cloud execution module
uses it directly).

I notice you failed to mention the new cloud runner, which was
developed at the same time. Documentation and further development are
forthcoming, and all of these things will be included in the next
feature release of Salt.

For now, continue to use the salt-cloud command for standard cloud
provisioning. It is not expected to go away, and its configuration is
not expected to change. The new stuff is being developed to better
integrate salt-cloud into salt.

> --
> You received this message because you are subscribed to the Google Groups
> "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to salt-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
"In order to create, you have to have the willingness, the desire to
be challenged, to be learning." -- Ferran Adria (speaking at Harvard,
2011)

[Seth House]

On Mon, Dec 9, 2013 at 2:50 PM, ed.lane <ed.l...@gmail.com> wrote:

> Can you provide some general guidance for VM orchestration and lifecycle
> orchestration?

Use salt-cloud to spin up VM groups and auto-accept the minion keys.
Use salt-cloud to delete VM groups and auto-delete the minion keys.
Use the reactor to handle orchestrating tasks after birth or death:

reactor:
- 'salt/minion/*/start':
- /srv/salt/provision.sls
- 'salt/cloud/*/destroying':
- /srv/salt/deprovision.sls

(The above works with the current Salt and salt-cloud releases. Read
on for what's coming.)

> Is the Salt state system thought to be too clumsy for managing VM
> creation/destruction so all these additional methods had to be added?

No. As Joseph said, the state system will be able to do VM
creation/destruction now that salt-cloud is merged into Salt core. It
will utilize and tie together all those components you cited earlier.
Each component handles a different level of the life cycle and having
salt-cloud in Salt core allows us to use them in a single interface
(states).

> Is VM lifecycle management not sufficiently standardized to allow a common
> API abstraction across all clouds and virtualization techniques?

That is what salt-cloud does. :-)

[ed.lane]

Seth, Joseph,

Thanks for the insights.  I appreciate your disclosure of the roadmap ahead and also the rationale for how we got here.

-ed

[Dan Garthwaite]

Ditto.  Thanks.