Hugh
This is great! I wish I had it when I started at Red Hat a few months
ago.
Some rewording suggestions in-line below. I thing Greg and Matt may have
commented similarly on the sections I have...
Joe
On Thu, 2011-07-14 at 14:45 -0400, Hugh Brock wrote:
I had one too many new hires ask me just what the purpose of Aeolus
as
an upstream project was, so I decided I would have a crack at writing
it down.
What I've done here is try to list the things we want Aeolus users to
be able to accomplish by using the various pieces under our
umbrella. I tried to hold it together with a draft of a "mission" at
the top, although I'm afraid it still turned into a bit of a laundry
list.
This is a community project, so I shouldn't be the one dictating this
stuff. Therefore I ask, nay beg each of you who have contributed code
on this list (or nearby it, even): Please, read the list and tell me
a. what I've left out, b. what should be reworded, or c. what we
*shouldn't* be doing as part of Aeolus. I'm happy to add or
consolidate points as needed to make the document better.
Once folks are generally happy with it, I'll ask Justin to put it on
the website. Hopefully it will be helpful...
Thanks,
--Hugh
--
== 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
What is Aeolus?
===============
Aeolus mission: Give users tools to build and manage organized groups
of virtual machines across multiple clouds.
So, what does Aeolus need to provide a user to accomplish its mission?
* The "manage" part, handled by Aeolus Conductor
* We want a way to let a user launch a VM or a clump of VMs on a
cloud, track them through their lifecycle, and clean them up when
they are no longer needed.
* We want the user to be able to wait to decide where to launch
their clump until the very last minute, or even let us decide for
them.
* We want the user to be able to set runtime values for the VMs in
their clump at launch-time
Suggest moving the above bullet under "Organized Groups" and reword to:
* We want the user to be able to set service configuration parameters at
runtime.
* We want the user to be able to easily check how much cloud time
they have burned up, set threshholds for alerting them when
interesting things happen (a VM crashed, they're about to go over n
hours of usage this month), and share access to their VMs with
others.
* We want an admin user to be able to group cloud resources for
other users, so that they can track and control which resources are
used and at what level.
* We want all this to happen in a truly superior GUI.
* The "build" part, handled by Aeolus Image Factory
* We want to let a user create a template that we can build into
images for each cloud they are interested in
* We want to let the user, 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.
* We want to let the user build images for multiple operating
systems, including Windows and various Linux flavors.
* We want to let the user rebuild images from the original template
if needed.
* The "Organized Groups" part, handled by Audrey (config) and Matahari
(monitoring)
* We want to give our users a way to specify a clump of images to
launch. We want the user's specification to be human readable and
portable.
Suggestion for rewording for above bullet:
We want to give our users a human readable way of specifying a group of
images to launch and a way to coordinate service configuration across
the group at launch time.
* We want the user to be able to specify values to collect at
launch-time via the Conductor UI. 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.
* We want the user to be able to include config snippets for each
instalce in their specification that will run after the instance
Nit: Spelling instalce -> instance
boots, injected by Audrey. Config snippets can do anything
including install software packages, set config values, or start
and stop services. Config snippets can be in any form that the
user's image supports -- Puppet manifest, bash script, powershell
script are all fine.
Rewording Suggestion:
We want the user to be able to provide configuration parameters and/or
tooling for each instance, to be injected and initiated at launch time
by Audrey
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.
Configuration tooling for a limited number of services will be provided
by Red Hat.
* We want the user to be able to monitor software and services on
the guest, and the health of the guest.
* The "Multiple Clouds" part, handled by Deltacloud
* We want users to be able to connect to and use multiple clouds as
seamlessly as possible.
* We want users to be able to set up complex network and storage
topology in multiple clouds just as they would in a bare-metal
environment. So a user should be able to describe a subnet for his
VM clump and the Conductor and the Deltacloud API should make
appropriate calls into the back-end cloud to create that subnet
and then launch the user's instances in it.
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel