Alan Maguire wrote:
> hi meem
>
> Peter Memishian wrote:
>
>> > > But I personally think that temporary datalinks should also be
>> > > represented as SMF instances, as they do provide datalink services.
>> > >
>> > yeah, i can see that there's a reasonable argument to do this. i think
>> > the key question is whether we expect the SMF representation
>> > to be complete regarding what is configured on the system,
>> > versus being complete about what is _persistently_ configured
>> > on the system. the latter is probably less intuitive to administrators,
>> > but i don't know that that is such a big problem - my assumption
>> > is they'll be using dladm to query link status rather than
>> > "svcs datalink/*". the problem i see with exhaustively
>> > representing temporary configuration is having to undo the
>> > temporary portions of the configuration explicitly (i.e. the
>> > instances that were created via temporary commands) on
>> > reboot.
>>
>> I thought SMF already had a way to mark e.g. property groups as being
>> temporary? Is that functionality insufficient?
>>
>>
>>
> temporary property groups will work fine (they disappear
> on reboot) but the problem is they need to be stored in instances,
> which are always persistent across reboot. this is a problem because
> such temporary instances would need to be torn down
> explicitly on reboot as a result. while this is doable, it does
> stray somewhat from the SMF model which is geared towards
> storing configuration intent,
So, the "configuration" does not include whether this set of
configuration data should be enabled (or even exist) after the next
reboot? I think they're all sort of "configuration" that is fine to
be saved in instances...
> and i'm concerned about the
> knock-on effects of having SMF representations for such temporary
> entities, e.g. the GUI would likely then have to determine
> the nature of the object represented (temporary or persistent),
> and likely not display such temporary instances.
>
I think maybe we can make this determination fairly easy for GUI to do?
> since it appears that the temporary information we need to
> store maps to data that dlmgmtd needs to retain (but not
> across reboot) for restart purposes - i.e. the linkid-linkname
> mappings - my suggestion is to store that data locally
> within the datalink-management instance in a
> temporary property group.
>
> the motivation for this distinction is that the methods
> for these persistent instances could potentially simply
> instantiate the object they represent temporarily,
> e.g. in the case of an aggregation instance start method,
> we'd have: "dladm create-aggr -t ...". the benefit of this
> approach is that the existence of the aggregation is
> predicated on the state of the instance, as opposed
> to having to modify "dladm up-aggr" say to correlate
> configuration data with instance state (i.e. the only
> persistent aggregations that are created on boot are
> those that have instances that are enabled).
>
According to my current prototype, I'm removing 'dladm up-aggr' from
network/physical:default to the start method of each aggr datalink
instance (something like 'dladm up-aggr <linkid>').
>> FWIW, I agree with Cathy that temporary datalinks should be represented as
>> SMF instances, for the same reason that temporarily enabling a service
>> still causes that service to show up in `svcs'.
>>
>>
>>
> right, but consider the consequences of representing
> temporary entities as SMF instances - the semantics
> of enabling an instance imply that the enable action
> is persistent, i.e. the service instance will be enabled
> at next boot also. if we support an instance representation
> for temporary entities (which can be manipulated by
> svcadm), my fear is that it will set expectations in this
> direction.
>
I think that smf supports temporarily enable/disable an smf instance.
So, the question here is not about enabling or disabling an instance.
Maybe the consequences are that it will set expectations for admin to
think that once an smf instances is created in the system, it should
not disappear after next reboot when it is not explicitly deleted by
admin ('svccfg delete ...')?
Max
> alan
>
> _________________________________
> clearview-discuss mailing list
> clearview-discuss at opensolaris.org
>
