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