On Wednesday 23 February 2011 15:38:25 Hugh Brock wrote:
On Wed, Feb 23, 2011 at 07:15:43AM -0500, Perry Myers wrote:
> On 02/23/2011 04:27 AM, Barak Azulay wrote:
> > On Wednesday 23 February 2011 00:47:48 Perry Myers wrote:
> >> cross-posting to Aeolus and Matahari upstream projects...
> >>
> >> We discussed sort of a pilot project for integration of Matahari into
> >> Aeolus usage. The driver for this is that we need a way for folks
> >> upstream to be able to deploy a single node Aeolus environment
> >> managing 1 or more Fedora hosts using kvm/libvirt (or VMware)
> >>
> >> The problem is that we don't have a way in this environment to
> >> bootstrap, specifically for Aeolus to get the ip address of the guests
> >> as they are booting on the libvirt/kvm/VMware hosts.
> >>
> >> I thought that this would be a good simple first use case for running
> >> Matahari in Aeolus managed guests. So here's what I propose:
> >>
> >> * Aeolus uses Image Factory to build images... When those images are
> >>
> >> either Fedora, RHEL or Windows IF will include Matahari and puppet
> >> in the core images
> >>
> >> * Aeolus will inject basic bootstrapping info for Matahari like broker
> >>
> >> ip address and broker auth info (this ignores the more complex post
> >> boot config process Carl has for the time being, this process is
> >> quick and dirty just to get stuff working and then we can expand to
> >> use Carl's process as a second step)
> >>
> >> * This injection could happen in a few ways:
> >> - During image build
> >> - During image deployment (using guestfish to inject a config file)
> >> - Other? Could rely on DNS SRV records w/ no broker auth (again
> >> this
> >>
> >> is meant for developer environments, not production usage)
> >>
> >> * When an instance is booted, matahari comes up uses the injected
> >> config
> >>
> >> and connects to the broker and a "hey I'm a new guest on the
bus"
> >> event should be sent out which includes the ip address of the guest
> >>
> >> * Simple QMF console written that runs as part of the Conductor
> >>
> >> infrastructure that monitors the bus for new 'I'm here'
events and
> >> when it sees one it grabs the ip address and stores it in the
> >> database
> >>
> >> * It then calls a processConfig method (on which Agent?) which gives a
> >>
> >> puppet file to a guest agent to process via a call to puppet tool.
> >> Return from that method should be success or failure (with logging
> >> info probably) This means puppet needs to be baked into the image
> >> as well along with matahari.
> >
> > This is good as long as the guest obtains network connectivity.
> > When the guest comes up with no network nothing happens and Aeolus will
> > not be able manage this guest.
>
> Yes, I think it's assumed that cloud guests require network
> connectivity... If a guest comes up and cannot get an ip address then
> this is pretty much a critical failure.
>
> Hugh/jrd, let me know if this assumption is incorrect.
If a guest boots in the cloud but no network is there to connect to
it, does it really exist?
Yes it does and it consumes valubale CPU and memory.
The question what happens in such a case.
In RHEVM (we assume rhev-agent is installed) we can tell whether the is a
heartbit to the guest agent and move the VM status accordingly.
if no heartbit available we move the VM's status to "NOT RESPONDING".
--H