On Thu, Jul 14, 2011 at 02:45:12PM -0400, Hugh Brock wrote:
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.
Should we use this as an opportunity to gently introduce the
nomenclature used in our app, or are we intentionally staying vague? It
seems like we could say "...let a user launch a VM (known as an
'instance') or a clump of VMs (known as a 'deployment')..."
(Of course, my example is slightly incorrect; a single instance is still
part of a deployment. But you get the point.)
* 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
I'm not sure "runtime values" will have a lot of meaning to newcomers.
I'm probably not the best person to suggest alternate wording here, but
does it make sense to say something like "We want the user to be able to
have custom server configurations applied to VMs at launch-time"? (That
wording definitely needs work.)
* 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.
I would move "share access to their VMs" to the next bullet point, which
leaves this one just about monitoring and reporting.
* 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.
See above, about moving access sharing to this bullet point.
* 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
This is really nitpicky, but I initially (mis)read "a template that we
can build into images" as meaning that we were injecting the template
inside of images at build-time. Maybe "create a template that defines an
image" will keep others from making the same mistake. Otherwise, this is
good.
* 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.
* 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.
It sounds like these few bullet points overlap a bit with those for
Conductor. Perhaps this is appropriate, though?
* We want the user to be able to include config snippets for each
instalce in their specification that will run after the 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.
* 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.
Overall, I think this is a great overview.
-- Matt