Justin, Can we get this info linked from the Aeolus web pages? Carl. On 06/09/2011 12:32 PM, Steven Dake wrote:

On 06/10/2011 07:00 AM, Justin Clift wrote: Feel free to change as you like - sure it can be reworked in your UGH red box :) Why monitor applications at all? Monitoring applications allows the complete HA methodology to be applied to enterprise and open source applications. This monitoring provides improved availability. WHy not have the cloud provider tell when an assembly has failed? There is a big loss of context. Feel free to rework this how you like, but please keep context. This "FAQ" entry purpose is to tell the community about active monitoring of the VM inside the cloud. Typically cloud providers can tell if a VM crashes or disappears, but it can't tell that the VM operating system is still functional. This can lead to situation where the vm has failed in some way that the cloud provider can't determine because it uses passive monitoring. Rest looks great! thanks! -steve

On Sat, 2011-06-11 at 00:00 +1000, Justin Clift wrote: Kudos Justin and Steve, I love the focus on why this is interesting to users. Very cool stuff. I've tried to get my head around the architecture of the technical integration here, but I'm still missing some of the big picture. e.g. - matahari needs to be installed in all the guests because it's what does the application monitoring and restarting. That sounds like a job for our "service" concept. You can include a matahari service descriptor in your deployable or template and it will be configured at either boot-time or build-time, respectively - the DPE - is that on the guest and built on matahari? or is it the server-side piece that talks to matahari on the guest - the CPE is server-side. Is there one of these per cloud? Similar to the config server? Is it plausible for it to be combined with the config server somehow? e.g. if we have an AMI for the config server on EC2, would we put the CPE on it too? - it sounds like CPE is going to consume the deployable XML. Does conductor push this to CPE, or does CPE watch for new deployables and pull it from conductor? - the assumption is that the deployable XML will describe the applications that the CPE needs to monitor. They'll be described as services. And the service descriptions in the deployable XML will include the information required for matahari to restart the daemons configured by the deployable. at first glance, I'm not sure that's the best way of doing this. e.g. if the script associated with a service (the script runs at build or boot time, depending on whether the service is in the deployable or the template) enables some daemons and configures matahari with the information it needs to restart it, does that work? think about where the service script is a puppet manifest. The recipe descibes the daemons that need to be running. Does conductor need to be involved here, or can matahari just figure out from the manifest (which will be available on the VM) that it needs to monitor and restart some daemons? - does conductor have a hard-dependency on pacemaker-cloud? or is it an optional dependency? or does conductor know nothing at all about pacemaker-cloud? - should pacemaker-cloud be a part of Aeolus releases so that we can pimp the HA stuff as an Aeolus feature? if so, is it okay for it to follow the Aeolus release schedule? Thanks, Mark.

On 11/06/2011, at 2:41 AM, Perry Myers wrote: <snip> Trying to think what this would mean in practical terms. We presently have: + an existing "stable" release (Fedora 14 & RHEL 6.1 rpms in public repos) It's version 0.2.0 presently (kind of old), and we're working on 0.3.0 + a "development/testing" repo (Fedora 14 & RHEL 6.1 rpms in public repos) Rpms go in here pretty frequently. They're presently the rpms being worked upon for Aeolus 0.3.0. For any of these repo's, we carry every package (and dependency) that we need, that's not already in each base OS. So, we carry what's not in Fedora 14, and what's not in RHEL 6.1. (tracked separately) We're actively getting packages put into Fedora proper too, so we don't have to completely maintain them ourselves. Looking at the Pacemaker Cloud README in git, it looks like this would add a further new dependency package of libqb: https://github.com/pacemaker-cloud/pacemaker-cloud And we might need to get the qpid on F14 updated too (unsure). Not sure of the effort involved, to do this. Chris Lalancette has been involved in the Aeolus packaging side of things, so would be able to give more guidance. In the medium to long term, it could be interesting (depending upon effort required). In the short term, not sure if this would mean we'd be overcommitting ourselves? + Justin -- Aeolus Community Manager http://www.aeolusproject.org

On 06/10/11 - 01:08:06PM, Perry Myers wrote: We would like to move it ASAP, but there is a roadblock. F-15 updated to rails 3.0, and we are still using rails-2.3.X. Now, our goal is to move to rails-3 anyway, but it requires a bunch of changes to the codebase and it keeps getting pushed off. We'll have to resolve this sooner rather than later. -- Chris Lalancette P.S. An alternative here would be to build 2.3.X packages for F-15, but that is really just putting off the inevitable

On 06/10/2011 09:41 AM, Perry Myers wrote: A DPE process maps to each deployable and handles the activity of maintaining availability for the deployable. Speaking about where we are today: CPE process is a one to one mapping with each cloud environment. This doesn't allow us to do deployable relocation per escalation (which may not be a feature of our first releases). Our long term plan is to allow each CPE to communicate with each other via a multi-node bus (QMF). The details of this are not yet worked out, but would allow us to scale to large number of assemblies and handle failure of any CPE process or node hosting a CPE process. yes Our model is as follows: CPE has an XML schema that it specifically understands. We will take whatever xml config bits we get from others and use xslt to translate it into "our standard" format. CPE is a process which is responsible for the following: starting dpe processes detecting failed dpe processes terminating and restarting failed dpe processes when they fail taking incoming xml config bits and xslt-ing them to its internal representation. Once DPE starts, CPE sends xml config that only pacemaker-cloud is aware of to DPE The model we are working under is that conductor will tell us that a deployable should be launched, and then our DPE process tells condor which images to spin up at which point. Keep in mind this has been under heavy debate in the past, and I believe we are at a point where we can proceed upstream. I am still hunting down information on this point, and we aren't ready for integration, but I believe we want to integrate at the "iwhd". My understanding is this component will contain the database access for images/deployables and how they are configured. See thread: [PATCH 3/3] changes for #1610: launching deployments via deployable xml (current xml deployable data) <deployable name="Redmine"> <description>Redmine is a web-based project management application</description> <assemblies> <assembly name="frontend" hwp="small"> <image id="53d2a281-448b-4872-b1b0-680edaad5922"> </image> </assembly> <assembly name="backend" hwp="medium"> <image id="85653387-88b2-46b0-b7b2-c779d2af06c7" build="c5fc000b-829a-4bb5-9df1-bb228da2c7ec"> </image> </assembly> </assemblies> </deployable> (how we would like this deployable data) <deployable name="Redmine"> <ha id="HA_UUID_CONFIG"/> <description>Redmine is a web-based project management application</description> <assemblies> <assembly name="frontend" hwp="small"> <ha id="HA_UUID_CONFIG/"> <image id="53d2a281-448b-4872-b1b0-680edaad5922"> </image> </assembly> <assembly name="backend" hwp="medium"> <ha id="HA_UUID_CONFIG/"> <image id="85653387-88b2-46b0-b7b2-c779d2af06c7" build="c5fc000b-829a-4bb5-9df1-bb228da2c7ec"> </image> </assembly> </assemblies> </deployable> </deployable> ha_id are UUIDs mapped to a XML database containing the ha config bits. Where this ha data is contained is an unsolved integration problem. The configuration format of this data is a solved problem. Specifically configuring this data is an unsolved integration point. WFM once we get to point that we actually have some Aeolus integration. We will be ready to integrate once we have the CPE/DPE processes finished as I described above. This is coming along nicely.