[Ovirt-devel] [Patch] oVirt Autobuild

Mohammed Morsi mmorsi at redhat.com
Mon Jul 21 16:58:32 UTC 2008


Hugh O. Brock wrote:
> On Mon, Jul 21, 2008 at 11:52:23AM -0400, Mohammed Morsi wrote:
>   
>> Here is the patch I've been working on to get autobuild working w/  
>> oVirt. Its a two stage build process, the first occurs on the host and  
>> consist on running / testing the build process. The second occurs on the  
>> oVirt wui appliance itself and entails running the wui tests. It is done  
>> for the most part, except for 1. additional data and test cases 2. a  
>> test in auto-build.sh that validates a successful response from the  
>> newly created appliance 3. means to run the second stage on the newly  
>> created appliance (right now it is run on a fixed / pre-existing  
>> instance of the wui appliance named 'ovirt-autobuilder', since we need  
>> ssh keys and an auto-build.conf script on the appliance for the 2nd  
>> stage to run properly.)
>>     
>
> Good start, comments in-line below.
>
>   
>> >From e97424e7a985a3282fc6a8e0c8372fa6ca9d9116 Mon Sep 17 00:00:00 2001
>> From: Mohammed Morsi <mmorsi at redhat.com>
>> Date: Mon, 21 Jul 2008 11:44:16 -0400
>> Subject: [PATCH] settup autobuild script and made changes neccessary for autobuild to work
>>
>> ---
>>  autobuild.sh                           |   59 +++++++++++++++++++++++++++++---
>>  wui/src/app/controllers/application.rb |    6 +++-
>>  2 files changed, 59 insertions(+), 6 deletions(-)
>>
>> diff --git a/autobuild.sh b/autobuild.sh
>> index ccae050..50fbd2f 100755
>> --- a/autobuild.sh
>> +++ b/autobuild.sh
>> @@ -1,6 +1,55 @@
>> -#oVirt wui autobuild script
>> +#oVirt autobuild script
>> +echo "Running oVirt Autobuild"
>>  
>> -#run tests
>> -cd wui/src/
>> -rake db:migrate
>> -rake test
>> +# simple test to determine if were on the wui appliance or not
>> +#  (anyone know a better way?)
>> +if [ ! -f /usr/share/ovirt-wui/ovirt.keytab ]; then
>>     
>
> I agree, ^^^ seems pretty fragile. Checking for hostname =
> "management.priv.ovirt.org" might be better.
>   
Sounds good, done.

>   
>> +     # delete previous appliance, restart libvirt
>> +     if [ -f /etc/libvirt/qemu/ovirt-appliance.xml ]; then 
>> +     	rm -f /etc/libvirt/qemu/ovirt-appliance.xml
>> +     fi
>> +     if [ -f /var/lib/libvirt/images/ovirt-appliance.img ]; then
>> +        rm -f /var/lib/libvirt/images/ovirt-appliance.img
>> +     fi
>> +     /sbin/service libvirtd restart
>> +
>> +     # create appliance
>> +    ./build-all.sh -ac
>> +
>> +     # wait until the install is complete
>> +     status=`virsh domstate ovirt-appliance`
>> +     while [ ! -f /etc/libvirt/qemu/ovirt-appliance.xml -o "$status" != "shut off" ]
>> +     do
>> +         sleep 10
>> +         status=`virsh domstate ovirt-appliance`
>> +     done
>> +     
>> +     # start appliance
>> +     virsh start ovirt-appliance
>> +     
>> +     # wait until started
>> +     sleep 180
>>     
>
> Do we not want a similar loop around "virsh domstate" here waiting for
> the domain to start?
>
>   
I started to change this and remember why we can't use "virsh domstate". 
The problem is that as soon as the domain is started the state is set to 
"running". This is not indicative of wether or not linux is done booting 
and the wui is available. I need to delay until then in order to be able 
to test the wui's successful response and ssh into it to run the wui 
tests. Right now, I have simply timed the startup time and delayed for 
that long. Obviously this is not an optimal solution, but works until we 
find something else.


>> +     # TODO verify a successful response when trying to access the ovirt site
>> +     # TODO shutdown the appliance
>> +     
>> +     # connect to the pre-built appliance (which has our ssh keys)
>> +     # and run auto-build to checkout ovirt an run the wui tests
>> +
>> +     # verify its up / wait until started
>> +     status=`virsh domstate "ovirt-autobuilder"`
>> +     if [ "$status" != "running" ]; then
>> +          virsh start ovirt-autobuilder
>> +          sleep 120
>> +     fi
>>     
>
> Surely we don't want to keep trying to start the domain over and over
> again if it won't start. Er and moreover, wait, this never resets
> "$status"...
>   
This is an 'if' condition, not a loop as discussed. Also same reason we 
sleep here instead of using domstate as discussed above applies here.



>      
>   
>> +     # run the wui auto-build
>> +     echo 'Starting oVirt Wui Autobuild'
>> +     ssh root at 192.168.122.141 "auto-build-clean-root && auto-build --config /etc/auto-build.d/auto-build.conf"
>> +
>> +else
>> +     # enter wui dir and run tests
>> +     cd wui/src/
>> +     rake test
>> +fi
>> diff --git a/wui/src/app/controllers/application.rb b/wui/src/app/controllers/application.rb
>> index aa8fd7c..69e5f8f 100644
>> --- a/wui/src/app/controllers/application.rb
>> +++ b/wui/src/app/controllers/application.rb
>> @@ -34,7 +34,11 @@ class ApplicationController < ActionController::Base
>>    before_filter :authorize_admin, :only => [:new, :create, :edit, :update, :destroy]
>>  
>>    def get_login_user
>> -    user_from_principal(request.env["HTTP_X_FORWARDED_USER"])
>> +    if ENV["RAILS_ENV"] != 'test'
>> +    	user_from_principal(request.env["HTTP_X_FORWARDED_USER"])
>> +    else
>> +        'ovirtadmin'
>> +    end
>>    end
>>    
>>    def user_from_principal(principal)
>> -- 
>> 1.5.4.1
>>
>>     
>
>   
>> _______________________________________________
>> Ovirt-devel mailing list
>> Ovirt-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/ovirt-devel
>>     
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ovirt-devel/attachments/20080721/59c860f0/attachment.htm>


More information about the ovirt-devel mailing list