|
Replies:
10
-
Last Post:
Dec 13, 2007 3:59 AM
by: cz147101
|
Threads:
[
Previous
|
Next
]
|
|
Posts:
304
From:
Registered:
10/17/05
|
|
|
|
UV temporary configuration data storage question
Posted:
Dec 7, 2007 12:58 AM
|
|
hi folks
i'm a bit confused about the need to store temporary configuration
data in the link id management API, and i was wondering if you could
help me understand the need to do this.
are there other reasons that temporary data is stored in
/var/run/datalink.conf
other than that cited in section 2 of the Link Id Management Design -
i.e. that this data is needed in the case of a restart of dlmgmtd?
(i'm assuming in this case the temporary data is needed in order to
apply all
the temporary changes again rather than reverting to persistently-configured
state - have i got this right?).
the reason i'm asking is we're trying to figure out the what/how of
the SMF representation, and representing temporary data there
is quite complex (our hope had been that temporary configuration
was represented by kernel state, as would be the case with the
interfaces i'd plumbed and configured non-persistently).
thanks!
alan
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
Posts:
768
From:
US
Registered:
6/14/05
|
|
|
|
Re: UV temporary configuration data storage
question
Posted:
Dec 7, 2007 1:06 AM
in response to: amaguire
|
|
Alan Maguire wrote:
> hi folks
>
> i'm a bit confused about the need to store temporary configuration
> data in the link id management API, and i was wondering if you could
> help me understand the need to do this.
>
> are there other reasons that temporary data is stored in
> /var/run/datalink.conf
> other than that cited in section 2 of the Link Id Management Design -
> i.e. that this data is needed in the case of a restart of dlmgmtd?
yes, that is the reason, and the temporary file is
/etc/svc/volatile/network-datalink-management.cache.
> (i'm assuming in this case the temporary data is needed in order to
> apply all
> the temporary changes again rather than reverting to persistently-configured
> state - have i got this right?).
>
Note that the only temporary configuration saved in the
/etc/svc/volatile/network-datalink-management.cache file is the <linkname,
linkid> mapping, that those are only information need to be recovered. It
includes <linkname, linkid, class, media> of the active links. All other
configuration (e.g. ports of the aggregation etc.) will not be saved at all.
Thanks
- Cathy
> the reason i'm asking is we're trying to figure out the what/how of
> the SMF representation, and representing temporary data there
> is quite complex (our hope had been that temporary configuration
> was represented by kernel state, as would be the case with the
> interfaces i'd plumbed and configured non-persistently).
>
> thanks!
>
> alan
>
> _________________________________
> clearview-discuss mailing list
> clearview-discuss at opensolaris dot org
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
304
From:
Registered:
10/17/05
|
|
|
|
Re: UV temporary configuration data storage
question
Posted:
Dec 7, 2007 8:30 AM
in response to: yun
|
|
hi Cathy
thanks for the quick response!
Cathy Zhou wrote:
> Alan Maguire wrote:
>> hi folks
>>
>> i'm a bit confused about the need to store temporary configuration
>> data in the link id management API, and i was wondering if you could
>> help me understand the need to do this.
>>
>> are there other reasons that temporary data is stored in
>> /var/run/datalink.conf
>> other than that cited in section 2 of the Link Id Management Design -
>> i.e. that this data is needed in the case of a restart of dlmgmtd?
>
> yes, that is the reason, and the temporary file is
> /etc/svc/volatile/network-datalink-management.cache.
>
>> (i'm assuming in this case the temporary data is needed in order to
>> apply all
>> the temporary changes again rather than reverting to
>> persistently-configured
>> state - have i got this right?).
>>
> Note that the only temporary configuration saved in the
> /etc/svc/volatile/network-datalink-management.cache file is the
> <linkname, linkid> mapping, that those are only information need to be
> recovered.
hmm, so the linkname-linkid mapping information for temporary
links is stored in the cache so that dlmgmtd can pick up all the temporary
mappings on restart, and if the user creates any new datalinks, we avoid
linkid clashes by having a stored (but not persistent-across-reboot)
list of linkname-linkids. is that right?
the reason i ask is in the SMF model, we'll have SMF instances for
datalinks, and it seems a bit heavyweight to create an instance
for a temporary datalink (we'd have to flag such instances
to be deleted on reboot). i wonder if we could simply
store the linkname/linkid mappings under temporary property
groups (which disappear on reboot) under the datalink-management
service instance? thanks!
alan
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
768
From:
US
Registered:
6/14/05
|
|
|
|
Re: UV temporary configuration data storage
question
Posted:
Dec 7, 2007 9:09 AM
in response to: amaguire
|
|
> hmm, so the linkname-linkid mapping information for temporary
> links is stored in the cache so that dlmgmtd can pick up all the
> temporary
> mappings on restart, and if the user creates any new datalinks, we avoid
> linkid clashes by having a stored (but not persistent-across-reboot)
> list of linkname-linkids. is that right?
That is correct.
>
> the reason i ask is in the SMF model, we'll have SMF instances for
> datalinks, and it seems a bit heavyweight to create an instance
> for a temporary datalink (we'd have to flag such instances
> to be deleted on reboot). i wonder if we could simply
> store the linkname/linkid mappings under temporary property
> groups (which disappear on reboot) under the datalink-management
> service instance? thanks!
You mean to store the temporary linkname/linkid mappings under temporary
proptery groups, and persistent linkname/linkid mappings should still be
persisted, right? I don't see a problem of that, as long as those
information can be easily looked up.
But I personally think that temporary datalinks should also be
represented as SMF instances, as they do provide datalink services.
Thanks
- Cathy
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
304
From:
Registered:
10/17/05
|
|
|
|
Re: UV temporary configuration data storage
question
Posted:
Dec 7, 2007 12:33 PM
in response to: yun
|
|
hi Cathy
Cathy Zhou wrote:
>
>> hmm, so the linkname-linkid mapping information for temporary
>> links is stored in the cache so that dlmgmtd can pick up all the
>> temporary
>> mappings on restart, and if the user creates any new datalinks, we avoid
>> linkid clashes by having a stored (but not persistent-across-reboot)
>> list of linkname-linkids. is that right?
> That is correct.
>>
>> the reason i ask is in the SMF model, we'll have SMF instances for
>> datalinks, and it seems a bit heavyweight to create an instance
>> for a temporary datalink (we'd have to flag such instances
>> to be deleted on reboot). i wonder if we could simply
>> store the linkname/linkid mappings under temporary property
>> groups (which disappear on reboot) under the datalink-management
>> service instance? thanks!
> You mean to store the temporary linkname/linkid mappings under
> temporary proptery groups, and persistent linkname/linkid mappings
> should still be persisted, right?
exactly.
> I don't see a problem of that, as long as those information can be
> easily looked up.
>
> 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.
thanks!
alan
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,083
From:
US
Registered:
3/9/05
|
|
|
|
Re: UV temporary configuration data storage
question
Posted:
Dec 10, 2007 6:49 PM
in response to: amaguire
|
|
> > 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?
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'.
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
304
From:
Registered:
10/17/05
|
|
|
|
Re: UV temporary configuration data storage
question
Posted:
Dec 11, 2007 2:44 AM
in response to: meem
|
|
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, 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.
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).
> 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.
alan
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,205
From:
US
Registered:
3/9/05
|
|
|
|
Re: UV temporary configuration data storage
question
Posted:
Dec 11, 2007 8:26 AM
in response to: amaguire
|
|
Alan Maguire wrote:
> 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.
svcadm doesn't seem to have such stringent semantics when enabling a
service instance with the "-t" option.
> 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.
But if temporary data-links are not represented as SMF instances, how
will the rest of the NWAM stack (IP and above) cope with these? Doesn't
the entire design hinge on IP instances depending on data-link instances?
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
304
From:
Registered:
10/17/05
|
|
|
|
Re: UV temporary configuration data storage
question
Posted:
Dec 13, 2007 1:50 AM
in response to: seb
|
|
Sebastien Roy wrote:
> Alan Maguire wrote:
>> 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.
>
> svcadm doesn't seem to have such stringent semantics when enabling a
> service instance with the "-t" option.
>
but once an instance exists in the repository,
whether our intent is for it to be temporary or not,
it'll be legal to carry out the various svcadm options on
it, including persistent enable. in the case of a temporary
instance, what would that mean? (in other words, running
"dladm create-foo -t" followed by "svcadm enable" without
the "-t" flag). to me it would imply that the instance should
be persisted rather than removed at next boot (since running
"svcadm enable/disable" without the -t flag obliterates
prior temporary state specification). if we could distinguish
such persistent enabling/disabling events, and respond
to them by marking the instance as persistent across
reboot in such a way that dlmgmgtd knows not to remove it,
that might be a reasonable way to go. but this conflates
the concepts of instance existence and instance state somewhat,
since temporarily enabling an instance means it'll still be
there on next boot, merely disabled.
perhaps we don't need all this complexity, but
my worry is that this concept of temporary instances
doesn't exist in SMF at present, and once an instance
exists in the repository, the service tools should
be able to interact with it in a way that is consistent
with existing conventions. i can't think of an easy
way to do this. perhaps the SMF team might have
some suggestions here.
>> 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.
>
> But if temporary data-links are not represented as SMF instances, how
> will the rest of the NWAM stack (IP and above) cope with these?
> Doesn't the entire design hinge on IP instances depending on data-link
> instances?
>
the configuration managed/created by NWAM via the
GUI/nwamcfg will be persistent. we have to catch
certain events such as interfaces acquiring addresses (in order
to evaluate profile predicates), and sometimes these will occur
for non-persistent links/interfaces that are not managed directly
by NWAM, but we wouldn't require the SMF representation
of those entities to do this.
alan
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
143
From:
Registered:
10/24/05
|
|
|
|
Re: UV temporary configuration data storage
question
Posted:
Dec 13, 2007 3:59 AM
in response to: amaguire
|
|
Alan Maguire wrote:
> Sebastien Roy wrote:
>
>> Alan Maguire wrote:
>>
>>> 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.
>>>
>> svcadm doesn't seem to have such stringent semantics when enabling a
>> service instance with the "-t" option.
>>
>>
> but once an instance exists in the repository,
> whether our intent is for it to be temporary or not,
> it'll be legal to carry out the various svcadm options on
> it, including persistent enable. in the case of a temporary
> instance, what would that mean? (in other words, running
> "dladm create-foo -t" followed by "svcadm enable" without
> the "-t" flag). to me it would imply that the instance should
> be persisted rather than removed at next boot (since running
> "svcadm enable/disable" without the -t flag obliterates
> prior temporary state specification). if we could distinguish
> such persistent enabling/disabling events, and respond
> to them by marking the instance as persistent across
> reboot in such a way that dlmgmgtd knows not to remove it,
> that might be a reasonable way to go. but this conflates
> the concepts of instance existence and instance state somewhat,
> since temporarily enabling an instance means it'll still be
> there on next boot, merely disabled.
>
Yes, it is quite confusing if you take an persistent action based on a
temporary configuration.
With representing temporary configuration via smf instances, we seem to
add one more way
to confuse our customers :(.
So, if we really don't want to create temporary instances, I think we
also should avoiding storing
temporary configuration data into smf instances, in order to make the
restriction less confusing - smf instances
are all persistent and only stores persistent configuration data.
Current implementation of dlmgmtd is doing the same thing. Only
persistent data go to /etc/dladm/datalink.conf.
Non-persistent data is stored in kernel (non-persistent name-linkid
mappings are stored in a temporary file).
Max
> perhaps we don't need all this complexity, but
> my worry is that this concept of temporary instances
> doesn't exist in SMF at present, and once an instance
> exists in the repository, the service tools should
> be able to interact with it in a way that is consistent
> with existing conventions. i can't think of an easy
> way to do this. perhaps the SMF team might have
> some suggestions here.
>
>
>>> 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.
>>>
>> But if temporary data-links are not represented as SMF instances, how
>> will the rest of the NWAM stack (IP and above) cope with these?
>> Doesn't the entire design hinge on IP instances depending on data-link
>> instances?
>>
>>
> the configuration managed/created by NWAM via the
> GUI/nwamcfg will be persistent. we have to catch
> certain events such as interfaces acquiring addresses (in order
> to evaluate profile predicates), and sometimes these will occur
> for non-persistent links/interfaces that are not managed directly
> by NWAM, but we wouldn't require the SMF representation
> of those entities to do this.
>
> alan
>
> _________________________________
> clearview-discuss mailing list
> clearview-discuss at opensolaris dot org
>
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
143
From:
Registered:
10/24/05
|
|
|
|
Re: UV temporary configuration data storage
question
Posted:
Dec 11, 2007 9:26 PM
in response to: amaguire
|
|
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 dot org
>
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
