I was poking around in the network/physical service manifest
(usr/src/cmd/svc/milestone/network-physical.xml) this afternoon, and
stumbled across something odd. I'm wondering if anyone can shed some
light on it. That is, who did this and why? :-) I have some ideas
on why it was done, but I'd like to confirm.
In the on gate, the *service* has a dependency on network/loopback,
defined outside of the individual instance definitions:
<service
name='network/physical'
type='service'
version='1'>
<!-- ifconfig needs loopback for IPC with dhcpagent -->
<dependency
name='loopback'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/network/loopback' />
</dependency>
<instance name='default' enabled='true'>
...
</instance>
<instance name='nwam' enabled='false'>
...
</instance>
</service>
But in the version of this file in the phase 1 project gate, the
dependency is defined inside each instance, along with a note about
preventing it from being inherited:
<service
name='network/physical'
type='service'
version='1'>
<instance name='default' enabled='true'>
<!--
ifconfig needs loopback for IPC with dhcpagent.
This dependency is defined here rather than
at the service level to prevent NWAM-generated
instances inheriting it.
-->
<dependency
name='loopback'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/network/loopback' />
</dependency>
...
</instance>
<instance name='nwam' enabled='false'>
<!--
ifconfig needs loopback for IPC with dhcpagent.
This dependency is defined here rather than
at the service level to prevent NWAM-generated
instances inheriting it.
-->
<dependency
name='loopback'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/network/loopback' />
</dependency>
...
</instance>
</service>
Anurag committed the changeset that introduced this; but the changeset in
question was the initial one for the hg cutover--so this change likely
happened earlier than that.
Mostly I want to work out what we really need here. I'm thinking that
this might have been from the time when we were expecting nwam to create
instances to represent the different profile objects. But since we're
not planning to do that now (and I suspect that if/when we do, they won't
be instances of the network/physical service), I don't think we need this
split, and the dependency should go back to being declared at the service
level.
Thoughts?
-renee
