ok, I know I'm top posting...
Build you cloud with freedom, freedom to create a private cloud, utilize
public clouds. Run and manage your infrastructure where you choose, when
you choose without lock-in.
Carl.
On 07/15/2011 11:43 AM, Mark McLoughlin wrote:
Hi Hugh,
I like it! :)
On Thu, 2011-07-14 at 14:45 -0400, Hugh Brock wrote:
> What is Aeolus?
> ===============
>
> Aeolus mission: Give users tools to build and manage organized groups
> of virtual machines across multiple clouds.
I don't think I'd emphasize "organized groups" in the mission, or the
build and managing etc. I think that's describing some of the features
we're concentrating on now, as opposed to a broader mission.
How about simply:
Free users from cloud lock-in by making the choice of cloud provider a
simple launch-time option.
Not quite happy with that, but I think that's what we're at. Our goal is
to make it possible to choose between clouds without hesitation, based
on the things that matter like service level and cost.
Part of that is making the cross-cloud feature set as compelling as the
cloud-specific feature set so that you're not penalized by choosing want
to be able to run on multiple clouds.
> So, what does Aeolus need to provide a user to accomplish its mission?
>
> * The "manage" part, handled by Aeolus Conductor
...
> * The "build" part, handled by Aeolus Image Factory
...
> * The "Organized Groups" part, handled by Audrey (config) and Matahari
> (monitoring)
...
I really like this separation. In fact, I'm starting to think we should
emphasize this a bit more.
e.g. Conductor is compelling on its own, even if you're just launching
single instances from images you built manually and will configure
themselves.
Image Factory is compelling on its own as an image building solution
that allows you to change clouds later. Like libvirt or deltacloud, by
choosing to use it you help limit how locked-in you are.
The "Organized Groups" part should be useful on standalone deltacloud
without Conductor involved at all.
Finally, I think the high availability stuff could be a 4th independent
piece in this puzzle. It should be compelling to use on any of
standalone deltacloud, conductor or "Organized Groups".
By keeping these four things slightly more separate, you give each
project the ability to focus more on their problem area and innovate
quickly without having to deal with how changes impact the other
projects.
And yet, using all three together makes perfect sense too. They're
complementary, but not closely coupled.
This is similar to how OpenStack is organizing their projects, giving:
http://nova.openstack.org/
http://swift.openstack.org/
http://glance.openstack.org/
> * The "Multiple Clouds" part, handled by Deltacloud
...
Deltacloud is an external dependency of Aeolus. I'd certainly list it,
but more "And all of this is made possible by Deltacloud" rather than
claiming it under the Aeolus umbrella.
Cheers,
Mark.
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel