stuff in the dom0s, so the domUs only need to see actual block
devices.
> That''s one of the difficult issues with managing storage with
puppet:
> initial provisioning of the storage has to happen before puppet has a
> chance to run, so you''d always have to resort to another tool (aka
the
> installer)
Yeah, but only for the initial installation. I don''t mind having to
manually install a dom0, but it would be soooo nice to have a tool
that can do the rest of the LVM partitioning from one centrally
maintained recipe.
> Are you more concerned about the time it takes you to babysit the
> process or to generally speed up how long the whole install process
> takes ? The latter would require some parallelization on puppet''s
part.
Both, actually. The latter, mostly. If I can setup stuff quickly, my
customers are happy puppies. If I don''t have to babysit, I can spend
time on other stuff and that makes my customers even happier...
("Finally you found the time to fix our corporate firewall! Thank you!
Now excuse me, I''ve got three months of email backlog to filter
through...")
> Agreed, and it would probably handle a large percentage of the cases
> where you want to modify storage on a running machine.
I''ve never had to resize a partition to something smaller. We leave
room to spare in each of our installation. If I ever need to resize
smaller, I''m probably screwing so much with the installation, I
don''t
*want* to do it automagically.
> It''s at http://www.libvirt.org/ and is part of RH-based distros;
AFAIK,
> it''s not in Debian, but all that is missing is somebody who
understands
> Debian packaging to package it - I''ve mentioned that to the
libvirt
> maintainers, and they are very interested in helping whoever is picking
> this up to get there.
I can look into that this weekend, I hope. Debian packages aren''t that
difficult once you know how to make them :)
> The dom0/domU relation is a lot more dynamic than what puppet is
> supposed to do; I doubt that you would want to contol VM migration
> through puppet. One of the advantages of puppet _not_ knowing about that
> is that puppet focuses entirely on the ''insides'' of a
system (dom0 or
> domU) whereas some other tool is responsible of pushing the domU''s
> around as black boxes.
Well, we don''t really use migration of domUs yet. Migration gets kinda
useless if your machine breaks down. We deploy fail-over with
heartbeat and DRBD or something where we need high-availability, don''t
really see a use for migration in that. I might be wrong, though, I''m
the suit of our little company, my coworker is the one with the
technical knowledge :) Migration is nice for scheduled maintenance,
but we use fail-over for that too.
But, as I said, it''s only a gut feeling. I''m probably wrong.
The only
thing I can think of right now in which case it would be convenient is
when you''re using the puppet manifests as a central documentation for
your network (see other mails about documentation). Something that''s
high on my priority list too...
--
Gegroet,
Tim
