[Rocks-Discuss] Conditional edges in kickstart graph

[Ventre, Brian D.]

All,

I'm having problems with conditional edges in my custom roll (Rocks 5.4.3). I'm trying to do 2 things: enable X11 on login nodes by default, and if GNOME is installed, make modifications via gconf to lock it down (screen saver, etc). My files are as follows (no access to source from email, so this is from notes):

Base.xml (default 5.4.3 install):
<edge from="client" to="x11" cond="x11"/>

apl-roll.xml:
<edge from="x11" to="apl-lock-gconf"/>
<edge from="login" to="x11"/>

The problem is that the login node does not get the packages specified in the x11 node, but both compute & login nodes run the post commands specified in apl-lock-gconf. So two things are happening:

1. The unconditional edge from login to x11 is not overriding the conditional edge from client to x11.
2. The condition on the x11 node is not propagating to apl-lock-gconf.

I see a log message from 2010/04/24 01:01:43 by anoop that says the "a--(cond)-->b---->c" problem was fixed, and only "a" should be installed, not "a,c", but I'm seeing a regression of that behavior. The kickstart graph on my frontend shows both new edges as expected (without any conditions).

Are there any workarounds that can be suggested? Thanks.

Brian Ventre
JHU/APL

[Anoop Rajendra]

Hi Brian,

Your observation about overriding is correct. The rocks graph parsing
does not support overrides.

To solve your particular problem, on the frontend, run

# rocks set appliance attr login attr=x11 value=true

and then re-install the login appliances.

-a

[Ventre, Brian D.]

Setting the attribute does enable x11 on the login node; I will use a post section during install of the front-end to make that the default for login appliances & remove the edge from login to x11.

As a possible bug, base.xml does this for a devel-appliance (edge to x11 and edge to client), so the same issue should happen with it.

However, I still have the problem where apl-lock-gconf runs even on the compute nodes (which have no x11 attribute in the database). Shouldn't it be pruned out? According to the graph, the only node linked to apl-lock-gconf is x11.

Brian V

-----Original Message-----
From: npaci-rocks-dis...@sdsc.edu [mailto:npaci-rocks-dis...@sdsc.edu] On Behalf Of Philip Papadopoulos
Sent: Tuesday, April 03, 2012 13:21
To: Discussion of Rocks Clusters
Subject: Re: [Rocks-Discuss] Conditional edges in kickstart graph

On Tue, Apr 3, 2012 at 9:52 AM, Ventre, Brian D. <Brian....@jhuapl.edu>wrote:

> All,
>
> I'm having problems with conditional edges in my custom roll (Rocks
> 5.4.3). I'm trying to do 2 things: enable X11 on login nodes by default,
> and if GNOME is installed, make modifications via gconf to lock it down
> (screen saver, etc). My files are as follows (no access to source from
> email, so this is from notes):
>
> Base.xml (default 5.4.3 install):
> <edge from="client" to="x11" cond="x11"/>
>
> apl-roll.xml:
> <edge from="x11" to="apl-lock-gconf"/>
> <edge from="login" to="x11"/>
>

Remove this ^^^^^^^^^^^^^^^^
it is both duplicative and could be causing issues in the graph processing
having a link that is both conditional
and non-conditional. Instead
rocks set appliance attr login x11 true

after you rebuild your distro
check with
rocks list host profile <name of login node>

and see if both packages and post are being called.

-P

>
> The problem is that the login node does not get the packages specified in
> the x11 node, but both compute & login nodes run the post commands
> specified in apl-lock-gconf. So two things are happening:
>
> 1. The unconditional edge from login to x11 is not overriding the
> conditional edge from client to x11.
> 2. The condition on the x11 node is not propagating to apl-lock-gconf.
>
> I see a log message from 2010/04/24 01:01:43 by anoop that says the
> "a--(cond)-->b---->c" problem was fixed, and only "a" should be installed,
> not "a,c", but I'm seeing a regression of that behavior. The kickstart
> graph on my frontend shows both new edges as expected (without any
> conditions).
>
> Are there any workarounds that can be suggested? Thanks.
>
> Brian Ventre
> JHU/APL
>
>
>

--
Philip Papadopoulos, PhD
University of California, San Diego
858-822-3628 (Ofc)
619-331-2990 (Fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20120403/11cafb34/attachment.html