On 07/27/11 - 03:57:37PM, Loranz Steve wrote:
> For a bug filed at https://bugzilla.redhat.com/show_bug.cgi?id=726107
Thanks for the patch. In the future, can you send these patches to me, but
remember to CC aeolus-devel (I've added the list as a CC to this reply).
I've used this patch as the base, but committed a slightly more robust version.
Take a look when you get a chance.
Currently most linux distributions that use dbus store a UUID in
/var/lib/dbus/machine_id. In our pacemaker-cloud work test tools, we
must manipulate this file via oz image creation to match a value we know
Q1. Is this file freshly created on each image creation/cloning process?
If not, it should be, because Matahari uses this information to uniquely
identify a host. If it is copied exactly to each new image, that
creates a problem (all hosts appear the same to matahari).
Q2. If/when it is created by image factory, will it be stored in a
database or other storage medium?
In pacemaker-cloud we need to have a mapping from image->internal id id
so that we know which VM maps to which deployable HA configuration.
If we wait on this point until after our 1.0 release, we could end up
with a bunch of images in the field that have either the same machine id
or are not mapped in any way that allows us to provide HA functionality.
Angus and I announced a project to apply high availability best known
practice to the field of cloud computing in late March 2011. We reuse
the policy engine of Pacemaker. Our first tarball is available today
containing a functional prototype demonstrating these best known practices.
Today the software supports a deployable/assembly model. Assemblies
represent a virtual machine and deployables represent a collection of
virtual machines. Resources within a virtual machine can be monitored
for failure and recovered. Assemblies and deployables are also
monitored for failure and recovered.
Currently the significant limitation with the software is that it
operates single node. As a result it is not suitable for deployment
today. We plan to address this in the future by integrating with other
cloud infrastructure systems such as Aeolus (developer ml on CC list).
The software will be available in Fedora 16 for all to evaluate that run
Fedora. Your feedback is greatly appreciated. To provide feedback,
join the mailing list:
If you have interest in developing for cloud environments around the
topic of high availability, please feel free to download our git repo
and submit patches. We also are interested in user feedback!
To get the software, check out:
On the pools#index page, the scoreboard had hardcoded values of 0 for updates, and for the quota. This patch removes that information.
This is intended for 0.3.x only. It should not be applied to master, where we hope to eventually implement those features.
I was asked this afternoon to look into the bug where some instances
(particularly on vSphere, and possibly on other providers) reported a
MAC address instead of an IP. There are a few things going on and I
wanted to update everybody on the status. We're going to need to wrap
this up tomorrow.
The problem is that before the instance has obtained an IP, all that's
available is its MAC address. This MAC gets reported over deltacloud as
the IP address, so EventLog has this as the "IP" and dbomatic picks it
up and dutifully stores it in the database. But there is no Condor event
triggered on the change of an IP; it's not considered a state change.
Ergo, we never notice that the MAC has been replaced by an IP.
Worse, after spending a bit trying to just read the data out of Condor,
we discovered that Condor is never updated with the IP at all in these
cases. Even long after deltacloud starts reporting an IP and Condor
polls for status, the MAC stores as an IP in Condor is never updated.
It looks like deltacloud will be updated tomorrow to split out the
'address' tag to have type="mac" and "type="ipv4", but this won't fully
solve our problem -- we'll be able to tell the difference between MACs
and IPs now, but we'll still have the problem of not getting an IP in
Short-term, the fix we identified is to go off to deltacloud any time we
display IP and obtain the information there. It should work to define
public_addresses and private_addresses in instance.rb, and insert calls
to Deltacloud there. (As a slight optimization, we could write the
values to the database here, and use those if the values were present,
so we don't have to go out to the network each time.) This isn't ideal
in the long-term, since it's fairly slow, but it's the best we're able
to do on short notice.
Unfortunately I've got to head out for the night now, so I can't take
care of this. I think the task will be slightly complicated by trying to
find the right instance on the API-side, since vSphere instances (that
will be reported over the API) have crazy UUID-derived names. I have a
sneaking suspicion you'll also have to go out to Image Warehouse to get
the image or build UUID, and then use that to find the matching instance
in deltacloud. From there, though, it should be a simple matter of
grabbing the IP, possibly updating it in the database, and then
returning it. It'll just take queries to a couple of external services.
Is there any way someone not in UTC-5 could pick this up in the morning,
to try to get a fix out? I'm told it's the last bug blocking us from
releasing. And I'm afraid I've got to head out for the night.