On 08/18/2012 12:17 AM, Crag Wolfe wrote:
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.
It sounds like a good plan.
Actually I think a script for "fedora rpms + upstream conductor" setup
would be useful anyway even if the developer tooling proposed by Jay had
already existed - both QA and RH CloudForms developers will need this
setup for development/testing.
The developer tooling would be useful for upstream community, ideally
this tool wouldn't depend on distribution-specific requirements (e.g.
using "yum install") and it would fetch projects from its source
repositories. I'm not sure if it would be easier to tweak it for "fedora
rpms + upstream conductor" setup than tweak aeolus-configure.
--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
Jan
