On Mon, Jul 18, 2011 at 12:42:44PM +0200, Tomas Sedovic wrote:
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
You're absolutely right that getting the UI integration to work for
this kind of separate-project setup is a tough problem.
Of course, we're already dealing with the problem now to some
extent. For example we chopped off the template building UI when we
realized it's really Katello's job to build images from templates. Now
we have an integration problem there :).
Having an entirely separate UI project is an interesting possible
solution, although I suspect such a project would have to do
non-railsy sorts of things like call a whole bunch of REST or XMLRPC
APIs to compose a page. An alternative way to manage it might be
coming up with an extensible Conductor UI.
Does anyone have any experience, or passing familiarity even, with a
project that puts a UI in front a bunch of separate-but-interrelated
projects?
--Hugh
>
> 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
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
==
http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey