On Tue, Jul 19, 2011 at 03:55:16PM +0100, Mark McLoughlin wrote:
Hi Matt,
On Mon, 2011-07-18 at 09:57 -0400, Matt Wagner wrote:
> Conceptually and perhaps behind-the-scenes, I like the idea of having
> various components that interact.
>
> Speaking practically, though, it already drives me crazy that we have
> various bits and pieces that don't necessarily fit together perfectly.
> We have components written in Ruby, Python, and C. Sometimes they
> interact over REST APIs, other times they use QMF, and sometimes they
> just directly modify each others' databases. (Although hopefully not so
> much of that last one these days.)
Certainly things are a little disjointed now. If you're keen to see this
cleaned up, you should definitely take a stab at figuring out what next
steps would take us in the right direction.
Nothing is set in stone here. It's up to all of us to keep the
architecture on the right track. We're Agile, right?
Yes, well-put. Really, my point here was more that I want to make sure
we slowly move in the direction of having the components (and their
authors) integrate more closely, as opposed to slowly becoming more
isolated. I suspect we're headed in the right direction, I just want to
make sure that good communication between teams stays on the radar if we
start to shuffle/split apart projects.
> To give one example of where this is a problem, our interactions
with
> Warehouse via API can be really slow, because we end up issuing a ton of
> queries to get what we need. (Although this problem is far worse in
> tests than in actual usage by our app, so it's not a serious problem for
> now.)
Conductor only really needs one thing - "given this cross-cloud image
reference, give me the list of cloud specific image references"
That's basically the main point of integration between Conductor and
"Composer".
I agree that our current iwhd model and iwhd's query interface doesn't
seem ideal for that. But (IMHO) it's an incremental improvement over
warehouse-sync, where we copied lots of stuff from iwhd and tried to
keep it in sync.
Yes, it's definitely an improvement, and I certainly didn't mean to
single it out. My point is really just that, in general, where two
components interact, it'd be swell if that interface could be optimized
somewhat for that use case. Honestly, I haven't dug too deeply into this
particular issue, so I don't know all of the considerations.
Ideas for further incremental improvement welcomed :)
> All this said, I still like the concept of having discrete components,
> but only if they are all designed with a common purpose and tightly
> integrated with the other components. When they become autonomous
> projects and lose sight of the overarching project direction, I think it
> becomes frustrating and perhaps detrimental to the project.
Yes, there's a balance to be struck between keeping the components
independent and loosely coupled vs keeping the components aligned on a
common direction.
> > 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.
>
> I like having both sections. They complement each other -- the mission
> gives the "what" and the "why," and the "Aeolus is"
provides the "how."
>
> > * 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.
>
> I think this section is good, but, in light of the above discussion
> about stand-alone components, this reminds me of something I was
> thinking about this weekend: if Conductor were removed from the project
> and used as a stand-alone app, what exactly is it meant to do?
You know, if keeping the projects better separated ensures that each of
us can better understand the usefulness of each project individually,
then I think we'd be in a better place.
It's an interesting way of thinking. I'm still struggling with some of
it, particularly around Conductor. It's something I'd like to pursue
further, though maybe not with the end of a sprint barreling down on us.
Conductor is about allowing an admin to set up a meta-cloud which
aggregates the resources of multiple clouds and giving users a
self-service interface and API for that meta-cloud.
The Conductor folks should be absolutely focused on proving out that
concept and making it a kick-ass project in its own right.
> For example, I have a Rackspace account with some VMs I started by hand.
> As things stand today, I can't use Conductor to manage them, because I
> didn't start them through Conductor / Factory / Warehouse. I think this
> is by design, but should it be? Would it be more useful if I could use
> it to consolidate my EC2 and Rackspace dashboards, even for things not
> launched through Conductor?
I think the reason we haven't done that is because of the admin/user
split.
If you, as admin, set up a pool using your EC2 account with some
instances running inside it then perhaps it makes sense for you to see
those instances in conductor.
However, how about the self-service users of that pool? Should they see
those instances? Who owns them? How about if the EC2 account is shared
by multiple pools.
Yes, I think there are actually a lot of fun issues here. An arbitrary
instance I have running in EC2 won't be part of a deployment or
explicitly belong in any pool, either, so we'll need to find something
smart to do here.
More challenging, we won't have a keypair that we generated in the
image, which will probably prevent us from monitoring these images as we
hope to do down the road.
These are hardly insurmountable problems, I'm sure, it'll just take a
fair bit of thinking.
Now, that's the background, but perhaps we're being a bit
myopic about
this admin/user split and we to put more effort into the case of a
single-user aggregating their EC2 and rackspace accounts.
I don't know how closely this matches what we have in mind. I do suspect
it would make the project more useful to a greater set of users, though.
Personally, I have no need to build custom images and push them to a
variety of clouds, but I do have a Linux VM at Rackspace hosting some
stuff, and I sometimes use EC2 for testing. It'd be pretty nifty to have
one tool that could let me manage both.
> > * Aeolus Composer: A way to build cloud-specific images
from
> > generic templates, so that users can choose clouds freely using
> > compatible images.
>
> This is good. If we go forward with this naming scheme, could we work on
> building a spiffy little table on a website somewhere that shows which
> components fit where?
>
> > * 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.
>
> On the above note, it's not clear to me what component(s) Orchestrator
> maps to. (Or maybe I just haven't had my coffee yet.) It sounds like
> this is a blend of Warehouse, Condor, and Conductor, though Conductor is
> already mentioned above.
This is definitely just a "conceptual split" at the moment.
I suggest it because the concepts of deployables, deployments, config
server and audrey are the part of the architecture that addresses this
"clumps of instances" problem.
If those pieces were together a more cleanly separated project, perhaps
we'd see the folks working on those pieces iterating on ideas a lot more
freely rather than worrying too much about integration issues.
I agree that some of these concepts definitely need work and/or
continued iteration, but some part of me wonders if there comes a point
at which we decide that we just need to run with whatever we have for
the sake of getting something in place and functional. I'm not really
intending to argue either way right here, as much as expressing a slight
frustration that there seems to be lots in flux, but not necessarily
lots of new functionality to match.
And also, if our solution is to become compelling, it should also be
compelling if you use it on top of a standalone deltacloud. There's no
particular reason why you shouldn't be able to just use it with EC2.
Yes, I definitely agree.
There's an obvious problem with this idea - the deployables and
deployments concepts are wedged pretty firmly in conductor. To separate
them out would mean making a separate app just for dealing with
deployables and deployments and then, much later, trying to figure out
how to bring that functionality back into a unified UI.
I actually think that's a sane idea, but not something we necessarily
need to rush into.
> > * Aeolus HA Manager (need a better name): A way to make instances or
> > clumps of instances in the cloud highly available.
>
> Backup Vocals? (This is a bit of a stretch, but I'm not sure that
> orchestras typically have stateful hot spares for musicians.)
>
> > All these things are possible because of the Deltacloud cross-cloud
> > abstraction library -- but Deltacloud itself is a separate project.
>
> We might want to give a little more mention of Deltacloud, as a sister
> project or whatnot. (Can we call the "abstraction library" an API?)
>
> > 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)
>
> Should this (long-term) support tracking of cost as well? In addition to
> showing how much time you've used, we could show how much it's cost you.
> (I know this is non-trivial to implement. I'm just wondering whether
> it's something we want to list here. It seems like it's something of
> interest to some people.)
Absolutely!
I think we've been seriously remiss in not tackling the accounting,
billing, chargeback, whatever problem to date.
e.g. if an admin sets up a pool with an EC2 and RHEV-M, I think he
should be able to set up a different cost basis for each one and the
self-service users should be able to choose a provider based on cost.
It'd be nice to use it in our matching, as well -- given two providers
that meet the requirements, we probably want to pick the cheaper of the
two. (I don't think it's actually nearly this simple, but we don't need
to solve this today.)
But in any case, we might want to update the bullet point for this to
read "lets a user easily check how much cloud time OR MONEY she has
burned up..." or so forth.
-- Matt