Aeolus Developer Conference Report. ACKS REQUIRED BY NOV 13.

Scott Seago sseago at redhat.com
Wed Nov 14 16:00:54 UTC 2012


On 11/14/2012 10:38 AM, Mo Morsi wrote:
> On 11/14/2012 09:00 AM, Scott Seago wrote:
>> On 11/13/2012 05:05 PM, Mo Morsi wrote:
>>> On 11/13/2012 10:05 AM, Scott Seago wrote:
>>>> On 11/13/2012 08:53 AM, Mo Morsi wrote:
>>>>> Responded privately, but Hugh suggested I send it to the general
>>>>> list so
>>>>> here it is
>>>>>
>>>>> On 11/10/2012 05:37 AM, Hugh Brock wrote:
>>>>>> * We split into teams, each of which came back with a proposed Aeolus
>>>>>>      mission statement. After much discussion we refined the four
>>>>>>      proposals into one which reads:
>>>>>>
>>>>>>      "Aeolus mission: to provide superior tools and workflows for
>>>>>> flexible
>>>>>>      construction, management, and monitoring of multi-instance
>>>>>> systems
>>>>>>      across clouds."
>>>>> Can we remove the words 'superior' and 'flexible'? IMO they don't add
>>>>> much.
>>>>>
>>>>> Also are we just focusing on 'multi-instance systems'? Isn't providing
>>>>> simple tools to build images and launch a single instance against any
>>>>> generic cloud provider part of Aeolus?
>>>> Yes, this came up in our discussions at the conference too. The
>>>> difficulty is that it quickly starts to get awkward when you start
>>>> adding a bunch of "or" clauses -- "single or multi-instance..." My
>>>> take is that, it's easy enough to assume that if you can handle
>>>> multi-instance systems, the degenerate case where "number of instances
>>>> == 1" is clearly included too.
>>> This isn't clear in the "multi-instance systems across clouds" mission
>>> statement. Forgetting instances, deployments, everything else, the end
>>> user is going to see "multi" and think: multi > 1.
>>>
>>> We have to look at the mission statement from the perspective of a
>>> completely new potential user who is encountering the website for the
>>> first time.
>>>
>>>     -Mo
>>>
>>>
>> Hmm. OK, I guess to me it's fairly clear that if we can handle >1, we
>> can handle 1 too, but I have no real objections to mentioning both, if
>> it can be done in such a way that everyone agrees to the wording. What
>> is essential, though, is that we do mention multi-instance systems,
>> since that's a huge part of what we do. In other words, by all means
>> lets make it clear that we handle "one or more instances" -- but not
>> at the expense of not making it equally clear that we handle complex
>> multi-instance systems well.
>>
>> Scott
>>
> I would argue the opposite. If its clear we can do 1 instance well, > 1
> is easily seen as a matter of parallelizing it after that. Most popular
> projects take the philosophy of doing one simple thing, but doing that
> thing really well.
It's easy to see "if we can do 1 instance we may be able to do >1 in 
the  future", sure -- but it does nothing to communicate that "we can do 
 >1 _now_"
Looking at it another way, if doing 1 well implied multi-instance 
deployments, then it wouldn't be a big deal for aeolus -- after all, all 
other providers would do that too right? Except most of them do not do that.

We took the approach a while back to focus more on multi-instance 
deployments as one of the differentiating factors here. Lots of people 
handle single instances. The two main reasons for Aeolus to exist seem 
to be this:
1) cross-cloud multiplexing -- launching in the appropriate cloud based 
on intelligent matching rules
2) Managing multi-instance deployments as a single unit, eventually 
including HA, auto-scaling, etc.

Although the "product" use case combines the two, upstream we can 
imagine users choosing either one or the other of these, or both 
together. The mission should indicate this in some way.

In any case, the obvious conclusion here is that the only way to please 
both of us here is to be explicit in stating that we can handle both 
single-instance and multi-instance deployments well. :-) We'll just need 
to make sure it's worded in a non-awkward way.

> Our most successful components up to this point take that approach.
> Deltacloud provides a generic cloud computational api, imagefactory
> provides a generic cloud image api, oz provides in-instance
> bootstrapping support, etc.
>
>
> Cutting to the chase, for Aeolus to be successful one of two things
> needs to happen:
>
> * we go back to the drawing board, develop more simple command line
> tools not dependent on external resources (other than the cloud
> providers themselves) to accomplish the goals we've been trying to
> achieve at this point. We develop these tools w/ specific communities in
> mind, addressing their cloud related needs.
Indeed we are trying to do that. More to the point, we're also working 
to separate the two items listed above (cross-cloud launching, and 
handling multi-instance deployments) in  ways that allow people to use 
one or the other without requiring both at once. The flexibility of 
using some subset of the stack is perhaps what you're getting at here.

Making use of multi-instance deployments isn't a requirement, but it is 
a feature.
Making use of transparent cross-cloud launching isn't a requirement, but 
it is a feature.

Scott

> * we offer our current stack as a hosted service (even if its just
> internal for the time being). Obviously this entails alot of
> complexities, but if we choose this route, we need to start working
> towards it (if we can't host our own thing, who is going to host our
> stuff on their network)
>
> My vote is for the former, but would be fine w/ the later. All the
> developers should weigh in as your time and efforts is at stake here. If
> anyone has an additional solution please present it, but justify how it
> would grow the visible user base more quickly than those already
> presented as that is the most important factor here.
>
>    -Mo
>
>




More information about the aeolus-devel mailing list