Direction for Conductor development scripts/tooling

Crag Wolfe cwolfe at redhat.com
Fri Aug 17 22:17:52 UTC 2012


Currently, getting a conductor development environment up and running
is non-trivial for most of the mortals among us.

   Aside #1: It actually is pretty trivial at least on fc16 if you
   follow these steps as mentioned by Matt Wagner on Freenode in
   #aeolus: "I do the RPM install [yum install aeolus-all], run
   aeolus-configure, and then copy the generated database.yml and
   oauth.json into a new checkout of the source."

I had taken a first cut at easing some of the pain with the conductor
README[1] and associated gist scripts[2].  Jiří Stránský has also
extended the scripts[3].

The scripts "just work" in fc16/fc17/rhel63+ in that they install
needed libraries, setup postgres, clone the github Conductor repo and
execute the usual rails development steps.

   Aside #2: The README describes how to set up a development
   environment the Bundler way (using conductor-dev-root-prep.sh and
   conductor-dev-setup.sh), but setting up a development environment
   with *system-wide* gems and dependencies is also easy.  One would
   first run aeolus-install-all-dependencies.sh before running the
   other two scripts (where $using_bundler=no in
   conductor-dev-setup.sh).

The glaring issue right now is that they don't attempt to do anything
with respect to setting up Image Factory, Deltacloud, etc. which means
the user isn't going to get very far in the Conductor WUI when it
comes to adding provider accounts, building images, etc.  As pointed
out in #aeolus, aeolus-configure does this (and more) so grabbing a
subset of this puppetry should do the trick.

Now, here is where the conversation typically flies off the rails
*cough* because there is the potential for all sorts of
scripts/tooling.

I think the short-term goal (and at this point it feels like
low-hanging fruit by using part of aeolus-configure) is to modify the
existing scripts to install and configure all the needed components.
I.e., just follow these two steps to set up a development server with
a sandbox based on the upstream Conductor code base.  This is
primarily about helping new developers (who may or may not already be
rails or linux experts).  And it would also be a boon to QA by
providing a simplified way to test the upstream Conductor code base.

*But* Aeolus has a slew of components (Conductor, Oz, Image Factory,
Image Warehouse, Audrey) plus a dependency on deltacould.  It would be
nice if the scripts/tooling could download, build and
configure-with-reasonable-defaults upstream versions of all of the
components, not just "yum install" stable versions as is currently the
case (it would be nicer still if this could be done not-as-root) which
is roughly what Jason proposed with "developer tooling"[4].

I like the idea of developer tooling as a longer term goal.
Obviously, if the tooling were completed, the Conductor development
setup scripts/instructions could be adapted to leverage it.  However,
at this point I would just like to reach consensus around the
shorter-term goal regardless of whether we decide to proceed with
developer tooling down the line.

--Crag

References:
[1] https://github.com/aeolusproject/conductor/blob/master/README.md
[2] https://gist.github.com/3178181
[3] https://github.com/jistr/aeolus-devel-setup
[4] http://etherpad-aeolusproject.rhcloud.com/p/feature-developer-tooling





More information about the aeolus-devel mailing list