On 06/28/11 - 03:12:57PM, Greg Blomquist wrote:
I talked to clalance for a moment on IRC to figure out what I
seeing. The main piece was the bit between networking and dbus. Since
dbus is likely to be up and configured by the time networking starts,
there are limitations to how we can get to the "user data" in some
cases. Specifically for ec2 (see comments below).
> I had originally thought deltacloud might be involved here in some way
> to consistently load instance data into the instance (and then provide a
> consistent way of accessing it inside the vm that doesn't involve
> writing 10 different access mechanisms).
> I don't know enough about deltacloud, but if the insertion functionality
> is currently a gap in any virtual machine manager (such as paravirt Xen)
> or RHEVH, the entire Aeolus solution as well as cloud-ha becomes
> non-functional on those VMMs.
> The question for deltacloud evaluation of this functionality then boils
> down to:
> 1) is this functionality available on every deltacloud cloud provider
Not readily or consistently. For instance, rhev-m has "hook"
functionality, but we haven't yet figured out what it means to use the
hooks to provide this functionality for rhev-m.
VMWare has some form of data injection available, as long as you install
their guest agent, enabling certain api functionality that deltacloud
could talk to.
It's significantly different for each provider, that it takes research
each time a new provider is taken on.
> 2) is the functionality inside the vm consistent (does a user only call
> a "read_my_id" function or read a file inside the vm) - if library
> access what is the new dependency inside the vm?
No. In fact, for the case of EC2, this particularly breaks down.
Because EC2 stores the "user data" in a place only accessible over the
network, the VM needs to ask a known ec2 location for the user data via
an HTTP GET.
Since dbus is probably already firmly set in stone by the time
networking comes up, it's likely too late to rely on ec2's user data to
store to this information and have it impact dbus after retrieval.
Just to be clear here, I don't know that this is the case. I haven't
personally looked into dbus, and how to configure the UUID on-the-fly. This
definitely bears investigation, as I feel that getting dbus to properly
expose this information is our best path forward.