Aeolus Community Assessment

Scott Seago sseago at redhat.com
Thu Jun 7 18:36:57 UTC 2012


On 06/07/2012 02:29 PM, Scott Seago wrote:
> On 06/07/2012 12:49 PM, Mark McLoughlin wrote:
>> On Wed, 2012-06-06 at 11:47 -0400, Jason Guiditta wrote:
>>> We also have in the incubator[1] the new rails engine that acts as a
>>> reusable client for factory
>>> [1] https://github.com/aeolus-incubator/image-management-engine
>> Am I roughly correct in saying that this is?
>>
>>    - An image registry API which exposes the mapping of an image
>>      identifier to cloud provider specific images, perhaps also tracking
>>      multiple versions/builds of an image
>>
>> Your "client for factory" description makes it sound like you can submit
>> a build request through image-management-service, but I don't see that
>> in the code?
>>
> One thing -- the 'engine' name here may be confusing people again. 
> this is not a separately-running service like 'system engine' or 
> 'cloud engine' but a "rails engine" -- essentially a plugin. When we 
> use the image management engine as part of conductor, it's pulled into 
> the conductor application - we integrate with its model so we get 
> fully-integrated permissions, internal database assocaitions among 
> resources, etc.
>
> But, since it's a separate rails engine, some other application or 
> client can also incorporate the codebase and interact with factory for 
> non-conductor use cases. However, I don't imagine you'd be able to 
> spawn off a separate "standalone" image management service to interact 
> with the _same_ dataset as that managed by a conductor instance, since 
> when it's pulled into conductor the image-management-engine model will 
> be extended with conductor-specific things, such as permissions, 
> connections with conductor environments, etc.
>> Whatever ... this kind of effort is exactly the way to be moving
>> forward. Kudos to you and Martyn.
>>
>> One suggestion I'd make for this would be to concentrate 100% on a nice
>> API and CLI for it. Make it easy to integrate with it. Make it so you
>> can go and promote this and image factory together completely
>> independent of conductor and all the rest.
>>
> But, yes, this last part is the goal, as I mentioned above.
>
> Going back to some of the original points about splitting up conductor 
> into something less monolithic and more consumable by other users, I 
> think the model here with the image management engine may be a better 
> one to follow than the idea of trying to shoehorn it all into 
> deltacloud modules/plugins. Otherwise we run the risk of deltacloud 
> itself being overcomplicated and obscuring its stated purpose.
>
> I guess my issue is if we're going to have a place where we're 
> plugging in separate smaller components that work together for 
> something larger, it seems that the conductor side would be the 
> logical starting point, since 1) that's where we already have this 
> sort of functionality and 2) most of the things we're discussing doing 
> here seem to have a lot more to do with the overall goals of the 
> aeolus project than they are to the conductor project.
                                                              
s/conductor/deltacloud/ here         ^^^^^^^^^

> Also, if we take conductor as the starting point, it's actually 
> possible to get to the end goal by little steps, so we don't have a 
> long period of breakage/destabilization where we come out at the end 
> with fewer things than we started with (even if they are better 
> designed).
>
> So conductor includes several features that we'd like to separate into 
> smaller chunks that can be used independently. In all cases, once we 
> identify something to separate, we need to decide whether it's being 
> separated into a completely separate service/process that will (in the 
> fully-integrated use case) communicate with conductor via API, or 
> whether it will be more of a plugin which (again in the 
> fully-integrated use case) will be more of a callable library 
> (possibly even extended) within the conductor rails application.
>
> Among these features:
> 1) image authoring and building service (already separated as 
> imagefactory)
> 2) image management component (originally separated as iwhd, being 
> rewritten as a plugin (image-management-engine)
> 3) multi-instance deployment with service configuration, dependency 
> handling, etc
> 4) cross-cloud launching (i.e. take a user request to launch 
> something; figure out where to place it based on resource availability 
> and other business logic)
> (and possibly more)
>
> From the other replies to the thread I've seen various proposals that 
> essentially amounted to trying to take either 3) or 4) out and make it 
> a deltacloud plugin. I would suggest we start on the other side -- 
> again largely to allow incremental progress and to avoid a big 
> de-stabilizing massive integration which would inevitably result from 
> a ground-up rewrite. Basically we'd pick 3) or 4) and rewrite the 
> existing functionality using a rails engine. Create something 
> self-contained that would work on its own, but would still lend itself 
> to a fully-integrated conductor application much like we have now -- 
> but with two separate (smaller) codebases, one of which can be used 
> independently of the other. If there's something that conductor uses 
> internally now that we _also_ need as a deltacloud plugin, that could 
> be done too -- but again I'd say we should _start_ by making the 
> conductor component pluggable, and then refactor the plugin such that 
> it could be used in both deltacloud _and_ conductor.
>
> Most important in the above is that we avoid a ground-up rewrite all 
> at once. We take individual bits that already work in conductor and 
> refactor them to create a pluggable component and (possibly in some 
> cases) refactor to the point it can be used by deltacloud as well -- 
> but if we go the other way (starting with a new deltacloud plugin for 
> something that wasn't done in deltacloud before), then the integration 
> effort on the conductor side will be much more difficult.
>
> Scott
>




More information about the aeolus-devel mailing list