On 07/15/2011 11:25 PM, Hugh Brock wrote:
On Fri, Jul 15, 2011 at 04:43:58PM +0100, Mark McLoughlin wrote:
> Hi Hugh,
>
> I like it! :)
Well, OK, here is a revision where I tried to incorporate everyone's
suggestions and comments, to the extent it made sense.
Mark had the very interesting idea of conceptually separating the
Aeolus components into discrete projects, each responsible for its own
existence and usefulness. Obviously in the short term this will be a
conceptual separation only, but I'd like to know what folks think of
the idea of actually splitting the projects up this way at some time
in the future. The idea of Conductor as the resource management and
monitoring gui that lets you launch single instances via UI or a an
exposed Deltacloud API, with a separate "Orchestrator" project for
multi-instance orchestration and other separate projects for building
("Composer") and HA ("need a catchier name") is somewhat compelling
I
think.
All we're missing now is the Lead Singer, the Cashier and the Janitor.
Or are those part of Katello? :-)
On a more serious note, we've already been doing this to a certain extent.
"Composer" is pretty much separate now: it uses Image Factory, IWHD and
Oz which are all standalone projects. The composing itself happens in
the aeolus-image CLI, which is de facto a separate beast from Conductor.
It doesn't have any library/module dependencies on Conductor -- it only
needs a running Conductor instance.
"Orchestrator" uses Audry and Matahari -- again, separate standalone
projects.
However, we still have one important bullet point that makes a clean
separation hard if not infeasible: the "truly superior GUI". If we make
all of these parts standalone, each of them will need their own UI,
presumably.
Making it feel consistent and *seamless* to the end user would be a huge
challenge there, I fear.
I would prefer to lean more towards the idea of having a single project
that is The UI. It would in turn use all the different components via
APIs as a backend.
Note that this doesn't necessarily mean throwing everything onto a
single website with 20 tabs and split windows and infinitely deep
navigation tree.
We can have multiple separate UI views for the specific tasks that use
the same set of backend projects underneath.
I fear that if we cleanly split the functionality into separate projects
for Conductor, Composer, Orchestrator and HA, we'll have the UI too
tightly coupled to the then structure of the projects.
That will make us less able to change the backend (if we want to
drop/reorganize the parts, we'll have to change the UI as well) and if
we need to change the UI significantly (say, based on users' feedback
based on their actual usage), we'll have to move around the backend
projects, too.
(one more note inline)
Thomas
I like Mark's rethinking of the mission statement, focusing on the
purpose of the project rather than the pieces of the project. For now,
I left in the definition ("Aeolus is"), but I'm not sure if that
really works or not.
Finally, the masses seemed to appreciate "clump," so I left it in
there :).
Anyway please let me know what you think of this draft.
Take care,
--H
What is Aeolus?
===============
Aeolus mission: To free users from cloud lock-in by making the choice
of cloud provider -- private, public, or hybrid -- a simple
launch-time option.
Aeolus is: A single, consistent set of tools to build and manage
organized groups of virtual machines across clouds.
So, what does Aeolus need to provide a user to accomplish its mission?
* Aeolus Conductor: A way to provide cloud resources to users, manage
users' access to and use of those resources, and control users'
instances in clouds. This lets users make intelligent choices about
which cloud to use.
* Aeolus Composer: A way to build cloud-specific images from
generic templates, so that users can choose clouds freely using
compatible images.
* Aeolus Orchestrator: A way to manage clumps of instances in an
organized way. Users should be able to automatically bring up a set
of different instances on a single cloud or spanning multiple
clouds, configure them, and tell them about each other.
* Aeolus HA Manager (need a better name): A way to make instances or
clumps of instances in the cloud highly available.
All these things are possible because of the Deltacloud cross-cloud
abstraction library -- but Deltacloud itself is a separate project.
What does each Aeolus component do, specifically?
=================================================
Aeolus Conductor:
* lets a user launch a VM on a cloud, track it through its
lifecycle, and clean it up when it is no longer needed
* lets a user easily check how much cloud time she has burned up,
set thresholds for alerting her when interesting things happen
(a VM crashed, she's about to go over n hours of usage this
month)
* lets an administrator group cloud resources for other users, so
that they can track and control which resources are used and at what
level.
* lets a user share access to his VMs with others
* lets a user make an informed choice of which of the available
clouds to use, based on cost and QOS data and other useful
metrics. Or, lets the user delegate that choice to Conductor
itself
* lets the user monitor software and services on the guest, and the
health of the guest
* has a truly superior GUI for doing all this
Aeolus Composer:
* lets users create a template that defines an image, which we can
build for each cloud they are interested in
* lets users, as part of building the image, specify arguments to
pass into the build process to configure software installation,
and also to specify values that will be passed back into the image
metadata to be used later
* lets users build images for multiple operating systems, including
Windows and various Linux flavors
* lets users rebuild images from the original template if needed, to
update packages for feature enhacements, bug fixes, or security
issues
Aeolus Orchestrator:
* lets users specify a clump of images to launch and configure
simultaneously. We want the user's specification to be human
readable and portable
* lets users specify values to collect at launch-time. The values
will influence how the instances configure themselves, either by
being interpolated into config snippets in the clump
specification, or by being passed directly to the instance
post-boot. Launch-time values mean the instances in a clump can be
configured differently each time they are launched
I think this could use an example. I'm not 100% sure what is this about.
Does this mean things like the IP address, what daemons are bound to
which port, etc.? Essentially what we've been referring to as "services"?
* lets users provide configuration parameters and tooling for each
instance, to be injected and run at launch time. User-provided
configuration tooling can do anything including install software
packages, set config values, or start and stop services. Config
tooling can be in any form that the user's image supports --
puppet manifest, bash script, powershell script are all fine.
Aeolus HA Manager:
* lets users include instances or clumps of instances in an HA
infrastructure which provides isolation, recovery, and
notification of failed applications or instances
* lets users specify policy for maintaining or relaunching services
within an HA infrastructure
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel