Alan Maguire wrote:
> Max Zhen wrote:
>> Hmm...maybe we can change the name like:
>> network/datalink:default --> network/datalink-management
>> network/ip:default --> network/ip-management
>>
>> So, we split the management services from individual datalink/ip
>> instances.
>> And we use the same name that Clearview is using now for datalink
>> management service.
>>
>>
> that separation would definitely help from an
> implementation perspective - the management
> services and datalink/interface instances will
> have different dependencies and exec methods -
> it would certainly make life easier if they could
> inherit these from the service level.
>
> so we'd have something like the following:
>
> 1. svc:/network/datalink-management:default
>
> with the present dependencies it has in the UV
> gate.
>
> 2. svc:/network/datalink:<name>
> ...
> each of which depend on datalink-management
> (i don't think they need to depend on policy
> engine as the methods are simply to create
> the underlying object, not configure it).
It depends on how do we want to define the states for these instances.
If we define online like:
online: the object (datalink or interface) was initialized and is
being managed by the active policy engine.
Then, I think, it would be better to make them depend on our policy engine.
So, if policy engine is not there, they will not go online (since they
are not managed by policy engine).
E.g., since NWAM does not support vlan, so I can explicitly make
network/datalink:vlan1
depend on network/physical:default. Thus, when network/physical:nwam is
on, network/datalink:vlan1
will go offline automatically and cannot be made online when nwam is the
policy engine.
>
> 3. svc:/network/ip-management:default
>
> which depends on datalink-management.
>
> 3. svc:/network/ip:<name>
> ...
>
> each of which depend on ip-management.
And also depend on corresponding datalink instances, right?
Thanks,
Max
>
> then network/physical:{default | nwam} need
> to depend on network/datalink-management
> and network/ip-management, as these
> are responsible for creating the entities
> they manipulate.
>
> alan
