On 08/07/2012 08:33 AM, Jason Guiditta wrote:
On 07/08/12 11:21 -0400, Mo Morsi wrote:
> On 08/07/2012 10:23 AM, Jiří Stránský wrote:
>> Hi guys,
>>
>> how do you prepare your development VMs? I've been talking with Mike
>> yesterday about a possibility of making a tool similar to
>> aeolus-configure, but for developers. Something to set up development
>> environment easily. Would anything like this be wanted?
>>
>> I was thinking something a bit more rake-style with the whole setup
>> thing decomposed into tasks. You could run a default scenario task
>> with the whole stack getting set up or just pick something like `rake
>> firewall:open_for_conductor` or `rake imagefactory:oauth` etc.
>>
>> Then today I saw Maros's kickstart-based solution [1] and I thought
>> something similar would be even nicer when doing dev env setup on a
>> VM, because it also takes care of OS installation.
>>
>> Mike and Jay also suggested such a tool could be useful for QE, so I
>> would be pleased to see Dave's and Ronelle's opinions as well.
>>
>> So I'm looking for ideas/feedback/anything related to this. First,
>> whether such thing would be wanted at all, and if so, any suggestions
>> and ideas how should the tool work.
>>
>> I imagine the tool could be useful to contributors outside of Red Hat,
>> who don't have Aeolus experts sitting in the same office to ask them
>> about stuff ;)
>>
>> Best wishes,
>>
>> Jirka
>>
>> [1]:
https://github.com/hacxman/spawnvm
>
>
> We used to use appliance-creator [1] to create software-appliances for a
> bunch of projects but this entailed additional resources during release
> cycles and thus often would get bumped down in priority / dropped.
>
> That being said, I'm all for this. Think pre-built appliances containing
> the latest versions of the application suite and/or the rake tasks would
> be useful.
>
> -Mo
>
> [1]
http://thincrust.net/
I'll reply in more depth later today, but for those wishing to develop
in a vm (which not everyone will want to do, plus you cant really do
it for factory very well, unless you do all snapshot builds, which is
a possibility), I woudl think the thing we should do here is use our
own tooling and build a vm with a tdl, and have oz generate the vm for
us. I had a cut of this already some time back, and it worked pretty
well, though I never got around to additional scripting, which would
ease setup even more.
-j
FWIW, I have been working on *Conductor* centric scripts here:
https://gist.github.com/3178181 which came out of the effort to write
https://github.com/aeolusproject/conductor/commits/master/README.md .
So, if you have a fresh FC16, FC17, or RHEL63+ machine, you can run
conductor-dev-root-prep.sh (as a superuser) followed by
conductor-dev-setup.sh (as a plain old user). This sets up Conductor
for development the Bundler way. They do *not* set up image factory or
deltacloud, but it would be nice if they did that too. I think ideally,
in the current developing-with-bundler case, imagefactory and deltacloud
should also be built/installed locally (upstream or stable?), so perhaps
there could be a flag in conductor-dev-setup.sh that does that.
Note, conductor-dev-setup.sh is meant to be unix/linux/macosx-agnostic
whereas currently conductor-dev-root-prep.sh assumes FC16/FC17/RHEL6.3+.
--Crag