Ovirt devel - May 2008 - [PATCH] split ovirt-wui into separate scripts

Hi ovirt,

The attached patch attempts to split the ovirt-wui initrd script into
5 separate scripts, one for each ovirt daemon.

Bullet points:
0) names scripts ovirt-host-browser, ovirt-host-keyadd, ... , ovirt-taskomatic
1) adds 'status' option for init scripts
2) %post section of rpm spec now removes legacy /etc/init.d/ovirt-wui
script if present
3) edited rpm spec to handle 5 scripts instead of one where appropriate
4) added new service names to the ENABLE_SVCS list in the
ovirt-wui-install script

The new rpm specfile assumes that the install is a fresh install (i.e.
it doesn't attempt to deal with any legacy issues from this patch),
with the exception of the convenience removal of the previous
ovirt-wui script.

Thanks for all you do,
Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: daemonsplit.patch
Type: text/x-patch
Size: 10574 bytes
Desc: not available
URL:
<http://listman.redhat.com/archives/ovirt-devel/attachments/20080507/6763dd32/attachment.bin>

steve linabery wrote:
> Hi ovirt,
> 
> The attached patch attempts to split the ovirt-wui initrd script into
> 5 separate scripts, one for each ovirt daemon.
> 
> Bullet points:
> 0) names scripts ovirt-host-browser, ovirt-host-keyadd, ... ,
ovirt-taskomatic
> 1) adds 'status' option for init scripts
> 2) %post section of rpm spec now removes legacy /etc/init.d/ovirt-wui
> script if present
> 3) edited rpm spec to handle 5 scripts instead of one where appropriate
> 4) added new service names to the ENABLE_SVCS list in the
> ovirt-wui-install script
> 
> The new rpm specfile assumes that the install is a fresh install (i.e.
> it doesn't attempt to deal with any legacy issues from this patch),
> with the exception of the convenience removal of the previous
> ovirt-wui script.
This looks reasonable, but I have one question.  All of the services are 
at runlevel 97/03.  Are there any dependencies between these services such 
that they should start in a predefined order?  If not, then having them 
all at 97 should be fine.  But previously in the combined ovirt-wui they 
did start in a specific order.

Perry

"steve linabery" <slinabery at gmail.com> wrote:
...
> diff --git a/wui/conf/ovirt-mongrel-rails b/wui/conf/ovirt-mongrel-rails
> new file mode 100755
> index 0000000..0e5687b
> --- /dev/null
> +++ b/wui/conf/ovirt-mongrel-rails
> @@ -0,0 +1,72 @@
> +#!/bin/bash
> +#
> +#
> +# ovirt-mongrel-rails       startup script for ovirt-mongrel-rails
> +#
> +# chkconfig: - 97 03
> +# description: ovirt-mongrel-rails is an essential component of the ovirt
VM manager.
> +#
> +
> +OVIRT_DIR=/usr/share/ovirt-wui
> +MONGREL_LOG=/var/log/ovirt-wui/mongrel.log
> +MONGREL_PID=/var/run/ovirt-wui/mongrel.pid
...
> +    if [ $RETVAL -eq 0 ] && touch /var/lock/subsys/ovirt-wui ;
then
...
> +stop() {
...
> +    if [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/ovirt-wui ;
then
Hi Steve,
I know this is mostly just moving existing code around, but this is
probably as good a time as any to factor out that repeated lock file name.