Aeolus Community Assessment

Jason Guiditta jguiditt at redhat.com
Thu Jun 7 19:11:38 UTC 2012


On 07/06/12 20:32 +0200, Jan Provazník wrote:
>On 06/07/2012 08:44 AM, Jan Provaznik wrote:
>>What I don't agree with is doing some architecture changes because of
>>hoping we attract some ppl. First, I'm not convinced that the Aeolus
>>would become simpler and second I don't believe this is a blocker. I
>>would say that most people don't even get to this level (where they look
>>at Aeolus architecture). True is that some architecture changes
>>mentioned in your list are already happening as mentioned in other replies.
>>
>
>I should probably clarify my opinion about conductor's architecture 
>and redesign:
>I'm not saying that current architecture is perfect and I bet we will 
>change it sooner or later. What I meant is that the fact there is no 
>community around this project is not a reason for starting 
>architecture redesign.
>
>If we convince people to at least try this app, then there could be 
>some feedback from them and they can tell us what they don't like so 
>redesign can be done based on this feedback then.
>
>Jan

I agree with part of this sentiment, but also with what sseago
suggests in another reply; better compartmentalizing the various
features conductor provides will lay an excellent groundwork for
further shuffling of modules later on as needed, without destabilizing
what we have now.  This approach would, I think, help us to achieve
the more modular architecture most people here seem to realize is a
good goal, while similtaneously making things easier for potential
contributors and users (everyone remember them, the original topic of 
this thread?).

I see a few steps we could take here to address 2 of the themes I
have seen in this thread:

* Improve setup experience for users

** Make the app more easily cross-platform installable.

   This is already underway, and conductor itself should actually be
   there already.  A roadblock to runnign fully on, say, OSX, is the
   kvm portion of image building.  So as things stand right now, you
   could install condcutor, and maybe configure could help set up your
   real server running linux to do that actual image building?  Not
   sure of a good way out of this one, unless there is a simple way to
   get factory working on OSX (I would love to be wrong here). 

   The other big piece is some cleanup and possible conditionalizing of
   things in configure.  Since we use puppet, this is already
   abstracted such that it should be expected to run cross-platform.
   If it does not, then I would hope the changes needed would be fairly
   minor.

** Make it easier to configure providers (RHEV and VMware, I am
    looking at you). As I mentioned in another reply, perhaps this
    would be a good place to remove the files/template we currently
    use, and move everything to using proper APIs instead.

* Improve the modularity and scope of our components.

** For existing features, the sections already discussed should be
    evaluated and rethought with an eye toward making them more loosely
    coupled.  This will allow future refactorings to be easier to
    accomplish, as well as set the stage for pulling out any components
    that appear to be reusable in their own right (or combined with
    something else outside of conductor).

** For new features, the above concepts should be kept in mind as the
    feature is designed.  IOW, make every effort to build something
    that is encapsulated and loosely coupled.  Whenever possible,
    writethe feature in such a way that is can easily be extracted into
    a small library or module (whether that be a rack app/rails engine
    or something else).  Sometimes I go so far as to create my entire
    codebase _outside_ of the conductor tree, tests and all.  Once I
    have this working, I drop it into conductor and wire it up.  I
    realize this is not entirely feasible for all features, but it
    demonstrates how I think we should be designing our code and
    architecture.

-j



More information about the aeolus-devel mailing list