[Ovirt-devel] Appliance Building using thincrust

[Bryan Kearney]

Mohammed Morsi wrote:
> bkearney at redhat.com wrote:
>> Two patches. The first pulls in the appliance recipe from thincrust. The second modifies the kickstart file to use hte new rpms from the first. Note that most "flat files" from the kickstart files are now acutal files in the first patch.
>>
>> _______________________________________________
>> Ovirt-devel mailing list
>> Ovirt-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/ovirt-devel
>>   
> Hey Brian,
>    I started reviewing these patches this morning. Obviously with the
> repo refactoring  some changes will need to be made, as well as some
> terminology updates ('wui' should probably be renamed to 'server' in a
> few locations), but for the most part this all looks good. Other than
> some directory layout tweaks due to the repo refactoring, a few things I
> noticed that need to be changed is the removal of the firefox profile
> from the appliance (firefox is no longer installed on the appliance
> since we now support password-based / simple kerb auth); as well as the
> removal of the build-all script (this functionality is mostly handled
> via make / rpmbuild). Other than that, this looks to be good to go
> (though I won't know for sure until I can apply the patch against a
> ovirt-appliance checkout and test it).
> 
> In the meantime, just to make sure I'm understanding how this all
> works,  you are removing all the cruft from the ovirt-appliance
> kickstart, besides the bare essentials; eg. setting up the necessary
> host resolution, iSCSI / NFS disc configuration, the ovirtAppliance
> package to be installed (which I'm assuming will be in the oVirt repo
> when this is all committed), and starting the ace init service on
> startup. On the ovirtAppliance rpm side you've moved most of the
> configuration previously in the kickstart to the
> /usr/share/ace/appliances/ovirt directory which will be loaded and used
> by ace when the service is started.

Yes, the goal is to use the kickstart file to only describe the packages 
which are laid down. Any other configuration is moved to the control of 
puppet. The main change is to move all of the "file creation" items into 
  one of the two locations under //usr/share/ace/appliances/ovirt

- the files directory is used to house files which are copied as is to 
their final location.
- the templates directory allows for erb driven templates. The variables 
are defined by the appliance recipe and what is in facter.

- Updates can be done either to the puppet recipe, or to an updates 
file.. which ever you prefer.


> 
> Overall it all makes sense and looks great. One last thing I'm trying to
> figure out is the best way to add some minor changes to configure the
> appliance to run in a test / demo mode, for example when autobuild is
> going through the build process and setting up the appliance. These
> changes include implanting the host's public ssh key onto the appliance,
> delaying sshd to start as one of the last services, and setting the
> rails environment to 'test'. Looking at your patches, perhaps one
> approach (feel free to suggest an easier and/or better one) would be to
> create a 'ovirt-test' ace configuration, residing in
> /usr/share/ace/appliances/ovirt-test, which would be identical to the
> 'ovirt' one save the aformentioned changes, and use the autobuild.sh
> script in the ovirt-appliance repo to sed ovirt-appliance.ks (previously
> wui-appliance/wui-devel.ks) to change  "echo ovirt >>
> /etc/sysconfig/ace/appliancename"  to  "echo ovirt-test >>
> /etc/sysconfig/ace/appliancename". Since it has to do w/ autobuild I can
> take care of this last part once your changes are in, but wanted to get
> your feedback on the best approach.

We have two options. The "correct" way would be a seperate recipe. We 
could also look to an augseas-command which sets the value based on the 
exisence of a control value in some other value. Either would work.

-- bk