Michael Hunter wrote:
> As an aside because of the fact that links can come and go and because
> of the need to build config for other systems the user needs to be able
> to specify what to do with links that don't exist at configuration time
> on the system. We've discussed this before when talking about the GUI
> but I don't know if its written down anywhere.
I think we are talking about two different levels. One is
working in the NCP and the other is using link/interface
as selection criteria in an Env. We've talked about doing
this in NCP, as mentioned above. We've not talked about
using non-existing link/interface as Env selection conditions.
I think it is OK. But we need to provide the rationale.
Note that the above issue is not the main question I asked.
I asked how a NCP may be updated automatically, and the pros
and cons. We need to describe the rationale behind this
decision.
>> The action of restoring a setup will remove this modification.
>> I think this action is easy to understand to a user.
>>
>
> Really?! Wholesale removal of body parts seems move obvious to me then
> exchanging the diamonds for cubic zirconia (of course the later might
> cause the former...).
Really. For example, I think it is easy for a user to
understand the following
> cp foo.old/* foo/
So changed files in foo will be "restored" to their old
back up. But new files in foo will not be touched. The
cp command may alert (with -i) the user that some files
will be overridden. Similarly, we can log the overridden
actions NWAM do (or NWAM can ask if a user wants that).
"Complete" restoration is like
> rm -r foo/
> mv foo.old/ foo/
This is certainly an action which a user wants to do in
some cases. But what is the reason we must only provide
this action?
> I think this is all well and good when the links and interfaces
> specified by the NCP don't overlap those manipulated by the ENA
> (although I think it might be common for the user to want to make sure
> those interfaces are in the NCP so they build an environment dependent
> on them).
>
> In the case where we get ripped out of the ground and restart say we lay
> out the NCP ignoring "other" links and interfaces. After that we match
> an environment. If we've managed to make the tunnel unusable but the
> link is still there we are likely to match an environment which
> contains name servers, etc. which are unreachable.
Why? If an interface or link is unusable, should it be used
as a selection criterion? This does not seem intuitive to
me. For example, suppose a user specifies a wireless card
NCU and it is not available (meaning unusable) but it is in the
NCP. Should an Env which depends on this wireless card NCU be
chosen? I suggest not.
> OTOH if the tunnel
> is still usable but we don't match on it we are likely to create an
> equally unusable configuration (bump in the stack which we don't remove?).
Why does NWAM not use the tunnel to select Env? This is exactly
the case in the first paragraph. I think we've agreed that it
is OK to use non-existing (in the context of NCP) link/interface
as selection conditions. So NWAM will use the usable tunnel to
do Env selection. I think this is consistent with what we've
discussed so far.
--
K. Poon.
kacheong.poon at sun.com
