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
