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:
>>>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  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 ;)
>>We used to use appliance-creator  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
>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.
FWIW, I have been working on *Conductor* centric scripts here:
which came out of the effort to
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+.
This is excellent Crag. Can you work with Dave and Ronelle to keep
building this out so that they can test upstream for real?
I'm perfectly happy to have Factory and Deltacloud install from
packages in the "I want to test conductor" case, if that makes things
easier. I just want to make sure Conductor itself can be easily and
repeatably installed and configured from source.
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."