[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Ovirt-devel] Appliance Building using thincrust

Mohammed Morsi wrote:
bkearney 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 redhat com
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 separate recipe. We could also look to an augseas-command which sets the value based on the existence of a control value in some other value. Either would work.

-- bk

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]