|
Replies:
24
-
Last Post:
Jan 22, 2008 5:33 PM
by: bustos
|
Threads:
[
Previous
|
Next
]
|
|
Posts:
143
From:
Registered:
10/24/05
|
|
|
|
smf instance for temporary configuration
Posted:
Dec 13, 2007 11:04 PM
|
|
Hello,
We've been discussing this issue for some time within NWAM and Clearview
mailing alias. I think it's time to try to involve more people on this.
So, I'm writing this email to seek some suggestions from you :).
A little bit background:
We're trying to use smf instances to represent networking configuration
in a system. Our current design is that one data link, or IP interface
is represented by one smf instance. These individual instances look like
svc:/network/datalink:<Clearview-UV name> and
svc:/network/ip:<Clearview-UV name> respectively. They are spawned,
respectively, by two management service instances:
svc:/network/datalink-managment:default and
svc:/network/ip-management:default, in response to request coming from
sysadmin or kernel. And these individual instances are managed, after
their creation, by policy engine service instance, such as
svc:/network/physical:nwam.
As we moving forward, we see a problem with this design:
We found that it seems to be hard to follow this design when we try to
represent temporary configuration with smf instances.
Currently, all smf instances saved in repository are persistent, which
means that they exist across reboot. While, instances created for
"ifconfig" or "dladm -t create-xxx" should be considered as "temporary
smf instances", which means that they should go away after next reboot.
But, there seems to be no such concept as "temporary smf instance" in
current smf model.
So, if we do create these temporary instances, we have to explicitly
remove them from smf repository before they go online during next
reboot. We might be able to do this in those two management service
instances since each individual instance should be created with a
dependency on their management service. But, this does not sound like a
good plan, tho.
Or, for now, we choose not to create any smf instance for temporary
configuration. We only represent persistent configuration via smf
instances. Thus, we don't have to worry about removing them during next
reboot. And we'll add temporary configuration support later when we have
some support from smf framework to handle such temporary instance. But,
the questions here are that:
Is this an acceptable way to represent networking configuration?
Do we have any plan to add temporary instance support in smf framework?
Thanks in advance for your advice on this issue.
Max
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
Posts:
1,653
From:
GB
Registered:
4/27/05
|
|
|
|
Re: [smf-discuss] smf instance for temporary
configuration
Posted:
Dec 16, 2007 2:40 PM
in response to: cz147101
|
|
On Dec 14, 2007 7:04 AM, Max Zhen <Max dot Zhen at sun dot com> wrote:
> Hello,
>
> We've been discussing this issue for some time within NWAM and Clearview
> mailing alias. I think it's time to try to involve more people on this.
> So, I'm writing this email to seek some suggestions from you :).
>
> A little bit background:
> We're trying to use smf instances to represent networking configuration
> in a system. Our current design is that one data link, or IP interface
> is represented by one smf instance.
Does this include logical interfaces?
The idea that all network interfaces (especially logical interfaces)
be represented as individual services doesn't make any sense to
me. It makes administration much harder, and apart from the temporary
configuration problem isn't likely to scale.
Would it make sense to consider interface groups in the same way that
we have share groups managed by sharemgr?
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
143
From:
Registered:
10/24/05
|
|
|
|
Re: [smf-discuss] smf instance for temporary
configuration
Posted:
Dec 16, 2007 6:47 PM
in response to: ptribble
|
|
Peter Tribble wrote:
> On Dec 14, 2007 7:04 AM, Max Zhen <Max dot Zhen at sun dot com> wrote:
>
>> Hello,
>>
>> We've been discussing this issue for some time within NWAM and Clearview
>> mailing alias. I think it's time to try to involve more people on this.
>> So, I'm writing this email to seek some suggestions from you :).
>>
>> A little bit background:
>> We're trying to use smf instances to represent networking configuration
>> in a system. Our current design is that one data link, or IP interface
>> is represented by one smf instance.
>>
>
> Does this include logical interfaces?
>
Yes.
> The idea that all network interfaces (especially logical interfaces)
> be represented as individual services doesn't make any sense to
> me. It makes administration much harder, and apart from the temporary
> configuration problem isn't likely to scale.
>
> Would it make sense to consider interface groups in the same way that
> we have share groups managed by sharemgr?
>
Hmm...can you explain it in more detail?
Thanks,
Max
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
409
From:
US
Registered:
3/9/05
|
|
|
|
Re: [nwam-discuss] [smf-discuss] smf instance
for temporary configuration
Posted:
Dec 20, 2007 4:17 PM
in response to: cz147101
|
|
On Mon, Dec 17, 2007 at 10:47:03AM +0800, Max Zhen wrote:
>
>
> Peter Tribble wrote:
> > On Dec 14, 2007 7:04 AM, Max Zhen <Max dot Zhen at sun dot com> wrote:
> >
> >> Hello,
> >>
> >> We've been discussing this issue for some time within NWAM and Clearview
> >> mailing alias. I think it's time to try to involve more people on this.
> >> So, I'm writing this email to seek some suggestions from you :).
> >>
> >> A little bit background:
> >> We're trying to use smf instances to represent networking configuration
> >> in a system. Our current design is that one data link, or IP interface
> >> is represented by one smf instance.
> >>
> >
> > Does this include logical interfaces?
> >
> Yes.
Just to be clear here: the ip interface that's represented by an smf
service instance is per-link, not per-address. That is, one ip instance
can have many ip addresses, both v4 and v6.
> > The idea that all network interfaces (especially logical interfaces)
> > be represented as individual services doesn't make any sense to
> > me. It makes administration much harder, and apart from the temporary
> > configuration problem isn't likely to scale.
Can you give some specifics on how administration is harder with
this model?
One thing to consider is that we will continue to support the existing
tools that allow you to change persistent configuration (dladm), and
will also offer both a gui and cli for nwam configuration. Even with
the data being stored in the smf repository, we do not expect 'svccfg'
to be the primary way to go about creating network configuration (though
it will work if you choose to do that!).
-renee
> > Would it make sense to consider interface groups in the same way that
> > we have share groups managed by sharemgr?
> >
> Hmm...can you explain it in more detail?
>
> Thanks,
> Max
> _______________________________________________
> nwam-discuss mailing list
> nwam-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/nwam-discuss
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,653
From:
GB
Registered:
4/27/05
|
|
|
|
Re: [nwam-discuss] [smf-discuss] smf instance
for temporary configuration
Posted:
Dec 21, 2007 12:59 PM
in response to: okie
|
|
On Dec 21, 2007 12:17 AM, Renee Danson <renee dot danson at sun dot com> wrote:
> Just to be clear here: the ip interface that's represented by an smf
> service instance is per-link, not per-address. That is, one ip instance
> can have many ip addresses, both v4 and v6.
>
> > > The idea that all network interfaces (especially logical interfaces)
> > > be represented as individual services doesn't make any sense to
> > > me. It makes administration much harder, and apart from the temporary
> > > configuration problem isn't likely to scale.
>
> Can you give some specifics on how administration is harder with
> this model?
Ah right.
My problem was with a potentially large number of service instances
being created (which is what would happen if it were one per address)
simply being cumbersome. Anything that scrolls off a terminal window
isn't easily manageable. But if it's limited to the number of links rather
than addresses then it's much more manageable and I don't have
any problems with that.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
601
From:
Registered:
3/9/05
|
|
|
|
Re: smf instance for temporary configuration
Posted:
Dec 16, 2007 5:35 PM
in response to: cz147101
To: Projects » clearview » discuss
Cc: Projects » nwam » discuss
|
|
Peter Tribble wrote:
> On Dec 14, 2007 7:04 AM, Max Zhen <Max dot Zhen at sun dot com> wrote:
>> A little bit background:
>> We're trying to use smf instances to represent networking configuration
>> in a system. Our current design is that one data link, or IP interface
>> is represented by one smf instance.
>
> Does this include logical interfaces?
>
> The idea that all network interfaces (especially logical interfaces)
> be represented as individual services doesn't make any sense to
> me. It makes administration much harder, and apart from the temporary
> configuration problem isn't likely to scale.
>
> Would it make sense to consider interface groups in the same way that
> we have share groups managed by sharemgr?
>
In this proposal, what is the administrative model, when one
wants to administer, for example, a property of an underlying
physical interface for a logical interface?
--Sowmini
|
|
|
|
|
Posts:
3,083
From:
US
Registered:
3/9/05
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Dec 19, 2007 6:27 PM
in response to: cz147101
|
|
> Or, for now, we choose not to create any smf instance for temporary
> configuration. We only represent persistent configuration via smf
> instances. Thus, we don't have to worry about removing them during next
> reboot. And we'll add temporary configuration support later when we have
> some support from smf framework to handle such temporary instance. But,
> the questions here are that:
> Is this an acceptable way to represent networking configuration?
> Do we have any plan to add temporary instance support in smf framework?
FWIW, as I stated at the meeting, I fear this approach *is* unacceptable
in the long-term, because it means that the administrator (or tools) can
no longer rely on SMF to provide the current state of these system
services. The result is that the SMF representation of IP interfaces and
datalinks becomes only meaningful as an implementation convenience for
tools such as NWAM, which was one of the things that mws was vehemently
against in the original Clearview UV SMF proposal.
Put differently: if the intent is for each configured IP interface or
datalink to be represented in SMF, then that needs to be visible in SMF
regardless of whether it will persist across reboot. If that's not the
intent, then I'd like to understand what the intent is. If SMF doesn't
provide the functionality necessary to do what we need, then it should be
extended rather than compromised.
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
304
From:
Registered:
10/17/05
|
|
|
|
Re: [smf-discuss] [nwam-discuss] smf instance
for temporary configuration
Posted:
Dec 20, 2007 1:50 AM
in response to: meem
|
|
Peter Memishian wrote:
> > Or, for now, we choose not to create any smf instance for temporary
> > configuration. We only represent persistent configuration via smf
> > instances. Thus, we don't have to worry about removing them during next
> > reboot. And we'll add temporary configuration support later when we have
> > some support from smf framework to handle such temporary instance. But,
> > the questions here are that:
> > Is this an acceptable way to represent networking configuration?
> > Do we have any plan to add temporary instance support in smf framework?
>
> FWIW, as I stated at the meeting, I fear this approach *is* unacceptable
> in the long-term, because it means that the administrator (or tools) can
> no longer rely on SMF to provide the current state of these system
> services. The result is that the SMF representation of IP interfaces and
> datalinks becomes only meaningful as an implementation convenience for
> tools such as NWAM, which was one of the things that mws was vehemently
> against in the original Clearview UV SMF proposal.
>
>
my understanding of the current SMF model is that service instances
represent configuration intent (mostly this is persistent configuration
intent, but temporary property groups which disappear on reboot
can figure also). instance state informs if this intent was applied
(online/offline/disabled) and if it was applied (i.e. the instance was
enabled and its dependencies were satisfied), the state can also
represent the result of that application (maintenance/degraded/online).
assuming i have this right, my concern about introducing temporary
instances is how these will sit with the existing SMF administrative
model (there is already a concept of temporary state change,
but not of temporary existence as far as i know). for example, if an
instance is temporary, should administrator-driven changes which
would be normally assumed to lead to persistent state changes (e.g
"svcadm enable datalink:foo") change the status of the instance
too (from nonpersistent to persistent), since they implicitly assume
persistence of the instance in question?
i wonder if there are concepts in enhanced SMF profiles (perhaps
a mutable, temporary profile within which such instances could
live) that could help here perhaps? could temporary instances
live in a temporary enhanced profile that disappears on reboot in the
same way that temporary property groups do? there seems to
be a persistence property in such profiles in the latest design.
alan
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
143
From:
Registered:
10/24/05
|
|
|
|
Re: [smf-discuss] [nwam-discuss] smf instance
for temporary configuration
Posted:
Dec 20, 2007 6:17 AM
in response to: amaguire
|
|
Alan Maguire wrote:
> Peter Memishian wrote:
>> > Or, for now, we choose not to create any smf instance for temporary
>> > configuration. We only represent persistent configuration via smf
>> > instances. Thus, we don't have to worry about removing them during
>> next
>> > reboot. And we'll add temporary configuration support later when
>> we have
>> > some support from smf framework to handle such temporary instance.
>> But,
>> > the questions here are that:
>> > Is this an acceptable way to represent networking configuration?
>> > Do we have any plan to add temporary instance support in smf
>> framework?
>>
>> FWIW, as I stated at the meeting, I fear this approach *is* unacceptable
>> in the long-term, because it means that the administrator (or tools) can
>> no longer rely on SMF to provide the current state of these system
>> services. The result is that the SMF representation of IP interfaces
>> and
>> datalinks becomes only meaningful as an implementation convenience for
>> tools such as NWAM, which was one of the things that mws was vehemently
>> against in the original Clearview UV SMF proposal.
>>
>>
> my understanding of the current SMF model is that service instances
> represent configuration intent (mostly this is persistent configuration
> intent, but temporary property groups which disappear on reboot
> can figure also). instance state informs if this intent was applied
> (online/offline/disabled) and if it was applied (i.e. the instance was
> enabled and its dependencies were satisfied), the state can also
> represent the result of that application (maintenance/degraded/online).
> assuming i have this right, my concern about introducing temporary
> instances is how these will sit with the existing SMF administrative
> model (there is already a concept of temporary state change,
> but not of temporary existence as far as i know). for example, if an
> instance is temporary, should administrator-driven changes which
> would be normally assumed to lead to persistent state changes (e.g
> "svcadm enable datalink:foo") change the status of the instance
> too (from nonpersistent to persistent), since they implicitly assume
> persistence of the instance in question?
Yes, this has to be defined clearly in smf framework before we create
temporary smf instances in our system.
I think that one big benefit we get from smf framework is we have a way
to represent the configuration of the system and tools to interact w/ that
configuration *dynamically*. So, once we represent networking environment
as smf instances, we, then, get the above benefit from smf framework.
No matter how temporary an datalink/interface is, it is part of the
current configuration
applied in the system. So, it should be able to be configured by smf
tools dynamically.
But, if we don't represent that part of configuration as smf instances,
it's going to be hard
for them to be configured by smf tools. And w/ part of the configuration
(persistent part)
that can be configured by smf tools, we're likely to confuse sysadmins.
And yes, that is our long term goal. If we cannot find a good way to
represent temporary part
of configuration, I agree to hide them for now. Otherwise, we'll
probably confuse sysadmins
more...
Max
>
> i wonder if there are concepts in enhanced SMF profiles (perhaps
> a mutable, temporary profile within which such instances could
> live) that could help here perhaps? could temporary instances
> live in a temporary enhanced profile that disappears on reboot in the
> same way that temporary property groups do? there seems to
> be a persistence property in such profiles in the latest design.
>
> alan
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Dec 22, 2007 5:49 PM
in response to: meem
|
|
On Wed, Dec 19, 2007 at 09:27:40PM -0500, Peter Memishian wrote:
>
> > Or, for now, we choose not to create any smf instance for temporary
> > configuration. We only represent persistent configuration via smf
> > instances. Thus, we don't have to worry about removing them during next
> > reboot. And we'll add temporary configuration support later when we have
> > some support from smf framework to handle such temporary instance. But,
> > the questions here are that:
> > Is this an acceptable way to represent networking configuration?
> > Do we have any plan to add temporary instance support in smf framework?
>
> FWIW, as I stated at the meeting, I fear this approach *is* unacceptable
> in the long-term, because it means that the administrator (or tools) can
> no longer rely on SMF to provide the current state of these system
> services. The result is that the SMF representation of IP interfaces and
> datalinks becomes only meaningful as an implementation convenience for
> tools such as NWAM, which was one of the things that mws was vehemently
> against in the original Clearview UV SMF proposal.
>
> Put differently: if the intent is for each configured IP interface or
> datalink to be represented in SMF, then that needs to be visible in SMF
> regardless of whether it will persist across reboot. If that's not the
> intent, then I'd like to understand what the intent is. If SMF doesn't
> provide the functionality necessary to do what we need, then it should be
> extended rather than compromised.
>
> --
> meem
SMF should not support such temporary instances. SMF is not a replacement
for every kernel state machine. Creating temporary network mods is the
mental equivalent of starting a daemon outside of its smf instance -- it
works, you can do it, etc. but it is not reflects in your svcs output.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
143
From:
Registered:
10/24/05
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Dec 22, 2007 6:45 PM
in response to: Mike Shapiro
|
|
Mike Shapiro wrote:
> On Wed, Dec 19, 2007 at 09:27:40PM -0500, Peter Memishian wrote:
>
>> > Or, for now, we choose not to create any smf instance for temporary
>> > configuration. We only represent persistent configuration via smf
>> > instances. Thus, we don't have to worry about removing them during next
>> > reboot. And we'll add temporary configuration support later when we have
>> > some support from smf framework to handle such temporary instance. But,
>> > the questions here are that:
>> > Is this an acceptable way to represent networking configuration?
>> > Do we have any plan to add temporary instance support in smf framework?
>>
>> FWIW, as I stated at the meeting, I fear this approach *is* unacceptable
>> in the long-term, because it means that the administrator (or tools) can
>> no longer rely on SMF to provide the current state of these system
>> services. The result is that the SMF representation of IP interfaces and
>> datalinks becomes only meaningful as an implementation convenience for
>> tools such as NWAM, which was one of the things that mws was vehemently
>> against in the original Clearview UV SMF proposal.
>>
>> Put differently: if the intent is for each configured IP interface or
>> datalink to be represented in SMF, then that needs to be visible in SMF
>> regardless of whether it will persist across reboot. If that's not the
>> intent, then I'd like to understand what the intent is. If SMF doesn't
>> provide the functionality necessary to do what we need, then it should be
>> extended rather than compromised.
>>
>> --
>> meem
>>
>
> SMF should not support such temporary instances. SMF is not a replacement
> for every kernel state machine. Creating temporary network mods is the
> mental equivalent of starting a daemon outside of its smf instance -- it
> works, you can do it, etc. but it is not reflects in your svcs output.
>
So, we treat temporary network configuration differently than persistent
network configuration here.
If you create a temporary network configuration, you won't see the smf
instance for it, thus, you won't
be able to operate on it with any svc tools.
For example, if you create a persistent aggr, you can see
network/datalink:aggrx in the svcs output and
you can disable/enable it using svcadm command. But, if you create that
aggr temporarily, you won't be
able to see it in the svcs output. Thus, there is no way to
disable/enable it w/ svc tools during its life time.
I'm wondering if it is acceptable in the long term?
Max
> -Mike
>
>
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Dec 22, 2007 7:20 PM
in response to: cz147101
|
|
> >
> >SMF should not support such temporary instances. SMF is not a replacement
> >for every kernel state machine. Creating temporary network mods is the
> >mental equivalent of starting a daemon outside of its smf instance -- it
> >works, you can do it, etc. but it is not reflects in your svcs output.
> >
> So, we treat temporary network configuration differently than persistent
> network configuration here.
> If you create a temporary network configuration, you won't see the smf
> instance for it, thus, you won't
> be able to operate on it with any svc tools.
Correct.
> For example, if you create a persistent aggr, you can see
> network/datalink:aggrx in the svcs output and
> you can disable/enable it using svcadm command. But, if you create that
> aggr temporarily, you won't be
> able to see it in the svcs output. Thus, there is no way to
> disable/enable it w/ svc tools during its life time.
>
> I'm wondering if it is acceptable in the long term?
>
> Max
It is no different than any other system abstraction, as in my example
for daemons. SMF state represents the administrator's intent to
create some persistent settings, and thereby delegate management
of the corresponding abstraction to the associated SMF restarter.
But SMF is not a substitute for the underlying kernel subsystems:
people are permitted to start processes outside of SMF, instantiate
pools outside of SMF, type ifconfig outside of SMF, and so forth.
And those subsystems will always offer some underlying primitive
to create and manage their resources: such primitives are required
to implement the SMF code itself, and also for layered applications,
developers, debugging, and so on. That is as it should be.
Typing "svcs" asks SMF to tell you about the resources it owns: i.e.
the things you told it to do. This is not the same as typing
"ps" or "ifconfig", which are asking the kernel to tell you about
all of the processes or all of the net interfaces and so on.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,083
From:
US
Registered:
3/9/05
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 16, 2008 10:27 AM
in response to: Mike Shapiro
|
|
> SMF should not support such temporary instances. SMF is not a replacement
> for every kernel state machine. Creating temporary network mods is the
> mental equivalent of starting a daemon outside of its smf instance -- it
> works, you can do it, etc. but it is not reflects in your svcs output.
This is an interesting analogy and it makes some sense to me. However:
* The actions needed to start a daemon are quite different from
those needed to have SMF start a daemon, but here the only
distinction is whether the "-t" flag is passed to dladm.
Further, the semantics seem possibly surprising: if "-t" is not
used, then the dladm changes are immediately reflected in the
SMF configuration (along with the SMF configuration tied to
subsequent boots), so one might intuit that using "-t" will
still result in immediate changes to SMF configuration -- and
be surprised to discover no SMF changes were made at all.
* Following the daemon example, SMF will restart assassinated
daemons that are under SMF control to maintain the integrity
of the service. By analogy, that might mean that if one
"delete-vlan -t"'s a link that has an SMF service instance
associated with it, SMF would recreate the VLAN, which will
probably surprise the sysadmin (then again, the auto-restart
of pkill'd daemons surprised many too).
As I undertand Max's current prototype, he's wired the delete
-t functionality to temporarily disable the SMF service
instance, which seems a reasonable option. However, having
delete -t tied in with SMF and create -t not tied in seems
asymmetric and (to me, at least) illustrates the awkwardness
of handling -t.
* From a conceptual standpoint, it's unclear to me why it's
unreasonable to model temporary configuration using SMF. I
agree with your point above that not every state machine needs
to be represented by SMF, but here we've already chosen to
model IP interfaces and datalinks using SMF, so it doesn't
strike me as unreasonable to model temporary ones too.
From a pragmatic perspective, it would help me to know more of
the use-cases for the IP interface and datalink SMF instances.
Right now, the uses I'm aware of are (a) simplifying boot-up,
(b) providing a convenient high-level interface to the admin
through svcs et al., and (c) allowing NWAM to manage them.
For those cases, I agree that temporary datalinks are either
irrelevant or relatively unimportant. But without a more
complete understanding of how these SMF instances will be used,
it's hard for me to share your conviction.
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
409
From:
US
Registered:
3/9/05
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 17, 2008 6:18 PM
in response to: meem
|
|
On Thu, Jan 17, 2008 at 02:27:28AM +0800, Peter Memishian wrote:
> > SMF should not support such temporary instances. SMF is not a replacement
> > for every kernel state machine. Creating temporary network mods is the
> > mental equivalent of starting a daemon outside of its smf instance -- it
> > works, you can do it, etc. but it is not reflects in your svcs output.
>
> This is an interesting analogy and it makes some sense to me. However:
>
> * The actions needed to start a daemon are quite different from
> those needed to have SMF start a daemon, but here the only
> distinction is whether the "-t" flag is passed to dladm.
>
> Further, the semantics seem possibly surprising: if "-t" is not
> used, then the dladm changes are immediately reflected in the
> SMF configuration (along with the SMF configuration tied to
> subsequent boots), so one might intuit that using "-t" will
> still result in immediate changes to SMF configuration -- and
> be surprised to discover no SMF changes were made at all.
I think an important distinction here is configuration vs. state. "-t"
changes do not create new *configuration*; but they do create new state.
Most of what's stored in the repository for links and interfaces is
configuration, and we've tried to minimize the amount of state that is
represented there.
So given your example, if you think of what you're looking at in the
repository as primarily configuration data, it shouldn't be surprising
that "-t" changes don't appear there: those changes are not creating
persistent configuration, by definition.
That said, some amount of state clearly exists, with the service state
being the most obvious example. We do intend for that to communicate
information about the state of the link or interface. I think this
is why this is such a difficult question! The repository is serving
many different purposes here, and it's hard to fit all the pieces
together.
> * Following the daemon example, SMF will restart assassinated
> daemons that are under SMF control to maintain the integrity
> of the service. By analogy, that might mean that if one
> "delete-vlan -t"'s a link that has an SMF service instance
> associated with it, SMF would recreate the VLAN, which will
> probably surprise the sysadmin (then again, the auto-restart
> of pkill'd daemons surprised many too).
>
> As I undertand Max's current prototype, he's wired the delete
> -t functionality to temporarily disable the SMF service
> instance, which seems a reasonable option. However, having
> delete -t tied in with SMF and create -t not tied in seems
> asymmetric and (to me, at least) illustrates the awkwardness
> of handling -t.
I agree, this is definitely awkward. We could have temporarily enabled
instances as well; but I would rather see those completely go away,
than to linger in the disabled state. Going back to Mike's general
principle: they aren't things that will be managed within the smf
framework; no smf restarter will enable them.
I think the enhanced smf profiles project[1] might offer us a more
suitable model. It introduces precedence levels, which allow changes
to be layered on top of each other, allowing overrides of properties
without destroying the underlying settings. In particular, there will
be a system-override precedence level, designed specifically for the
purpose of publishing status. Data at this level is intentionally
non-persistent. We need to do more investigation, but I think this
might be a good way to model temporary links and interfaces.
-renee
[1] http://opensolaris.org/os/project/smf-profiles/Design/
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,083
From:
US
Registered:
3/9/05
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 20, 2008 2:26 AM
in response to: okie
|
|
> That said, some amount of state clearly exists, with the service state
> being the most obvious example. We do intend for that to communicate
> information about the state of the link or interface. I think this
> is why this is such a difficult question! The repository is serving
> many different purposes here, and it's hard to fit all the pieces
> together.
Agreed.
> I think the enhanced smf profiles project[1] might offer us a more
> suitable model. It introduces precedence levels, which allow changes
> to be layered on top of each other, allowing overrides of properties
> without destroying the underlying settings. In particular, there will
> be a system-override precedence level, designed specifically for the
> purpose of publishing status. Data at this level is intentionally
> non-persistent. We need to do more investigation, but I think this
> might be a good way to model temporary links and interfaces.
>
> [1] http://opensolaris.org/os/project/smf-profiles/Design/
Yes, that seems promising.
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 20, 2008 11:51 PM
in response to: meem
|
|
On Thu, Jan 17, 2008 at 02:27:28AM +0800, Peter Memishian wrote:
>
> > SMF should not support such temporary instances. SMF is not a replacement
> > for every kernel state machine. Creating temporary network mods is the
> > mental equivalent of starting a daemon outside of its smf instance -- it
> > works, you can do it, etc. but it is not reflects in your svcs output.
>
> This is an interesting analogy and it makes some sense to me. However:
>
> * The actions needed to start a daemon are quite different from
> those needed to have SMF start a daemon, but here the only
> distinction is whether the "-t" flag is passed to dladm.
>
> Further, the semantics seem possibly surprising: if "-t" is not
> used, then the dladm changes are immediately reflected in the
> SMF configuration (along with the SMF configuration tied to
> subsequent boots), so one might intuit that using "-t" will
> still result in immediate changes to SMF configuration -- and
> be surprised to discover no SMF changes were made at all.
This doesn't make sense to me: dladm -t should mean muck with the
abstractions but do nothing to the saved smf configuration.
That's the equivalent of what it means now. Or to make another
analogy, it's like running ifconfig without changing /etc/hostname.XXX
> * Following the daemon example, SMF will restart assassinated
> daemons that are under SMF control to maintain the integrity
> of the service. By analogy, that might mean that if one
> "delete-vlan -t"'s a link that has an SMF service instance
> associated with it, SMF would recreate the VLAN, which will
> probably surprise the sysadmin (then again, the auto-restart
> of pkill'd daemons surprised many too).
There should be no daemon running for networking instances. i.e.
they should be all marked transient since the kernel holds the state.
> As I undertand Max's current prototype, he's wired the delete
> -t functionality to temporarily disable the SMF service
> instance, which seems a reasonable option. However, having
> delete -t tied in with SMF and create -t not tied in seems
> asymmetric and (to me, at least) illustrates the awkwardness
> of handling -t.
As I say above that doesn't make sense to me.
>
> * From a conceptual standpoint, it's unclear to me why it's
> unreasonable to model temporary configuration using SMF. I
> agree with your point above that not every state machine needs
> to be represented by SMF, but here we've already chosen to
> model IP interfaces and datalinks using SMF, so it doesn't
> strike me as unreasonable to model temporary ones too.
You're misunderstanding my argument, then. The SMF state is not for a copy
of what is going on in the kernel. It is for the saved state of how the
admin wants the machine configured persistently. You will want to have
some way of manipulating the underlying abstractions without touching SMF
if for no other reason than to implement your per-instance start methods.
> From a pragmatic perspective, it would help me to know more of
> the use-cases for the IP interface and datalink SMF instances.
> Right now, the uses I'm aware of are (a) simplifying boot-up,
> (b) providing a convenient high-level interface to the admin
> through svcs et al., and (c) allowing NWAM to manage them.
> For those cases, I agree that temporary datalinks are either
> irrelevant or relatively unimportant. But without a more
> complete understanding of how these SMF instances will be used,
> it's hard for me to share your conviction.
Same as everything else in SMF: we want a standard way for representing
saved administrative configuration that can be used to simplify
programmatically manipulating it, and applying higher-level services
such as role-based access control, snapshot/rollback, auditing, fault
management stack connections, and so on. Without SMF, every single system
facility has to either re-implement all of that, or not provide them.
Looking at dladm and ifconfig today, we have none of those features.
If networking is converted to SMF, then we have all of them.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,083
From:
US
Registered:
3/9/05
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 21, 2008 12:27 AM
in response to: Mike Shapiro
|
|
> This doesn't make sense to me: dladm -t should mean muck with the
> abstractions but do nothing to the saved smf configuration.
> That's the equivalent of what it means now. Or to make another
> analogy, it's like running ifconfig without changing /etc/hostname.XXX
Yes. But in the case where the dladm -t request conflicts with the SMF
configuration, what happens? Should the service instance remain online
and pay no mind to the fact that the configuration is now different from
what it had configured?
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
143
From:
Registered:
10/24/05
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 21, 2008 1:12 AM
in response to: Mike Shapiro
|
|
Mike Shapiro wrote:
> On Thu, Jan 17, 2008 at 02:27:28AM +0800, Peter Memishian wrote:
>
>> > SMF should not support such temporary instances. SMF is not a replacement
>> > for every kernel state machine. Creating temporary network mods is the
>> > mental equivalent of starting a daemon outside of its smf instance -- it
>> > works, you can do it, etc. but it is not reflects in your svcs output.
>>
>> This is an interesting analogy and it makes some sense to me. However:
>>
>> * The actions needed to start a daemon are quite different from
>> those needed to have SMF start a daemon, but here the only
>> distinction is whether the "-t" flag is passed to dladm.
>>
>> Further, the semantics seem possibly surprising: if "-t" is not
>> used, then the dladm changes are immediately reflected in the
>> SMF configuration (along with the SMF configuration tied to
>> subsequent boots), so one might intuit that using "-t" will
>> still result in immediate changes to SMF configuration -- and
>> be surprised to discover no SMF changes were made at all.
>>
>
> This doesn't make sense to me: dladm -t should mean muck with the
> abstractions but do nothing to the saved smf configuration.
> That's the equivalent of what it means now. Or to make another
> analogy, it's like running ifconfig without changing /etc/hostname.XXX
>
>
>> * Following the daemon example, SMF will restart assassinated
>> daemons that are under SMF control to maintain the integrity
>> of the service. By analogy, that might mean that if one
>> "delete-vlan -t"'s a link that has an SMF service instance
>> associated with it, SMF would recreate the VLAN, which will
>> probably surprise the sysadmin (then again, the auto-restart
>> of pkill'd daemons surprised many too).
>>
>
> There should be no daemon running for networking instances. i.e.
> they should be all marked transient since the kernel holds the state.
>
>
>> As I undertand Max's current prototype, he's wired the delete
>> -t functionality to temporarily disable the SMF service
>> instance, which seems a reasonable option. However, having
>> delete -t tied in with SMF and create -t not tied in seems
>> asymmetric and (to me, at least) illustrates the awkwardness
>> of handling -t.
>>
>
> As I say above that doesn't make sense to me.
>
Yes, if we compare "ifconfig + /etc/hostname.xxx" with "dladm -t + smf
instances", it seems obvious that we should completely ignore changes
done by 'dladm -t' and keep smf instance intact. But, I'm not sure if
that comparison is fully valid... :-\
The problem I see here is that saving persistent configuration in a
plain file is somewhat different than saving it in an smf instance.
A plain file can save the configuration, no more, no less. You won't be
able to tell if that configuration has been applied, or not, by only
checking the file containing the configuration. So, no matter how many
times you run ifconfig, there is no point to modify /etc/hostname.xxx
since that file does not contain any information needs modifying.
But, we have a 'state' (online, offline, etc...) associated w/ each smf
instance for sysadmin to check any time he wants. Thus, we actually keep
more information in smf instance besides the configuration itself.
I'm wondering what is the best way to handle these extra information
(comparing w/ a plain file database)...for example, if the instance is
'online', should we view it as "the configuration has ever been
successfully applied, but whether it is still there is unknown"?
Max
>> * From a conceptual standpoint, it's unclear to me why it's
>> unreasonable to model temporary configuration using SMF. I
>> agree with your point above that not every state machine needs
>> to be represented by SMF, but here we've already chosen to
>> model IP interfaces and datalinks using SMF, so it doesn't
>> strike me as unreasonable to model temporary ones too.
>>
>
> You're misunderstanding my argument, then. The SMF state is not for a copy
> of what is going on in the kernel. It is for the saved state of how the
> admin wants the machine configured persistently. You will want to have
> some way of manipulating the underlying abstractions without touching SMF
> if for no other reason than to implement your per-instance start methods.
>
>
>> From a pragmatic perspective, it would help me to know more of
>> the use-cases for the IP interface and datalink SMF instances.
>> Right now, the uses I'm aware of are (a) simplifying boot-up,
>> (b) providing a convenient high-level interface to the admin
>> through svcs et al., and (c) allowing NWAM to manage them.
>> For those cases, I agree that temporary datalinks are either
>> irrelevant or relatively unimportant. But without a more
>> complete understanding of how these SMF instances will be used,
>> it's hard for me to share your conviction.
>>
>
> Same as everything else in SMF: we want a standard way for representing
> saved administrative configuration that can be used to simplify
> programmatically manipulating it, and applying higher-level services
> such as role-based access control, snapshot/rollback, auditing, fault
> management stack connections, and so on. Without SMF, every single system
> facility has to either re-implement all of that, or not provide them.
> Looking at dladm and ifconfig today, we have none of those features.
> If networking is converted to SMF, then we have all of them.
>
> -Mike
>
>
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 21, 2008 10:25 AM
in response to: cz147101
|
|
Max wrote:
> Yes, if we compare "ifconfig + /etc/hostname.xxx" with "dladm -t + smf
> instances", it seems obvious that we should completely ignore changes
> done by 'dladm -t' and keep smf instance intact. But, I'm not sure if
> that comparison is fully valid... :-\
>
> The problem I see here is that saving persistent configuration in a
> plain file is somewhat different than saving it in an smf instance.
> A plain file can save the configuration, no more, no less. You won't be
> able to tell if that configuration has been applied, or not, by only
> checking the file containing the configuration. So, no matter how many
> times you run ifconfig, there is no point to modify /etc/hostname.xxx
> since that file does not contain any information needs modifying.
> But, we have a 'state' (online, offline, etc...) associated w/ each smf
> instance for sysadmin to check any time he wants. Thus, we actually keep
> more information in smf instance besides the configuration itself.
> I'm wondering what is the best way to handle these extra information
> (comparing w/ a plain file database)...for example, if the instance is
> 'online', should we view it as "the configuration has ever been
> successfully applied, but whether it is still there is unknown"?
>
> Max
Peter wrote:
> Yes. But in the case where the dladm -t request conflicts with the SMF
> configuration, what happens? Should the service instance remain online
> and pay no mind to the fact that the configuration is now different from
> what it had configured?
These are the same question, so I'll answer once. First off, the state
isn't part of the configuration in SMF either: the config is what is saved
in the repository, the service state is what is saved in memory in svc.startd.
In terms of your question, I think all that is required here is decide on
some reasonable semantics for existing service instances. The one that
comes to my mind is temporary disable (equivalent of svcadm disable -t).
i.e. if I use dladm -t to modify something and an instance exists in SMF
for that and it is enabled, then dladm -t temporarily disables it.
The semantics of temporary disable already means that it will return
on next reboot, so that seems to fit. Anyway, think it through.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,083
From:
US
Registered:
3/9/05
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 21, 2008 9:24 PM
in response to: Mike Shapiro
|
|
> In terms of your question, I think all that is required here is decide on
> some reasonable semantics for existing service instances. The one that
> comes to my mind is temporary disable (equivalent of svcadm disable -t).
> i.e. if I use dladm -t to modify something and an instance exists in SMF
> for that and it is enabled, then dladm -t temporarily disables it.
> The semantics of temporary disable already means that it will return
> on next reboot, so that seems to fit. Anyway, think it through.
This approach is what Max has already done, as per my earlier email:
As I undertand Max's current prototype, he's wired the delete
-t functionality to temporarily disable the SMF service
instance, which seems a reasonable option. However, having
delete -t tied in with SMF and create -t not tied in seems
asymmetric and (to me, at least) illustrates the awkwardness
of handling -t.
... to which you responded "As I say above that doesn't make sense to me."
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 21, 2008 10:46 PM
in response to: meem
|
|
On Tue, Jan 22, 2008 at 01:24:34PM +0800, Peter Memishian wrote:
>
> > In terms of your question, I think all that is required here is decide on
> > some reasonable semantics for existing service instances. The one that
> > comes to my mind is temporary disable (equivalent of svcadm disable -t).
> > i.e. if I use dladm -t to modify something and an instance exists in SMF
> > for that and it is enabled, then dladm -t temporarily disables it.
> > The semantics of temporary disable already means that it will return
> > on next reboot, so that seems to fit. Anyway, think it through.
>
> This approach is what Max has already done, as per my earlier email:
>
> As I undertand Max's current prototype, he's wired the delete
> -t functionality to temporarily disable the SMF service
> instance, which seems a reasonable option. However, having
> delete -t tied in with SMF and create -t not tied in seems
> asymmetric and (to me, at least) illustrates the awkwardness
> of handling -t.
>
> ... to which you responded "As I say above that doesn't make sense to me."
Right. As in, the notion that this asymmetry is somehow an issue doesn't
make sense to me. -t means do stuff outside of smf. Max's idea is just
trying to be friendly there in a way that *is* consistent with what is
being presented. I see no problem there.
Personally, I don't even find that to be necessary -- I see no issue with
having svcs show the smf state yet have tools to mess with the underlying
thing. Because as a reminder, administrators don't ever need to run -t --
it's there for our use in building the method scripts or for development/
debugging/testing. (We have many other similar such options in our system
today in various utilities.)
But I also don't object to Max's approach of delete -t => disable -t.
As I said, this is extending the boundaries of what has been done, so
decide what seems reasonable and get input from others (as you're doing).
As we evolve the SMF mechanism to contain new abstractions, there will be
a natural evolution of the framework itself and how to use it. That is
all goodness, because it contributes to the overall leverage point.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,083
From:
US
Registered:
3/9/05
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 21, 2008 11:08 PM
in response to: Mike Shapiro
|
|
> Right. As in, the notion that this asymmetry is somehow an issue doesn't
> make sense to me. -t means do stuff outside of smf. Max's idea is just
> trying to be friendly there in a way that *is* consistent with what is
> being presented. I see no problem there.
Ah, OK. No problem then :-)
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
143
From:
Registered:
10/24/05
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 21, 2008 11:09 PM
in response to: Mike Shapiro
|
|
Mike Shapiro wrote:
> On Tue, Jan 22, 2008 at 01:24:34PM +0800, Peter Memishian wrote:
>
>> > In terms of your question, I think all that is required here is decide on
>> > some reasonable semantics for existing service instances. The one that
>> > comes to my mind is temporary disable (equivalent of svcadm disable -t).
>> > i.e. if I use dladm -t to modify something and an instance exists in SMF
>> > for that and it is enabled, then dladm -t temporarily disables it.
>> > The semantics of temporary disable already means that it will return
>> > on next reboot, so that seems to fit. Anyway, think it through.
>>
>> This approach is what Max has already done, as per my earlier email:
>>
>> As I undertand Max's current prototype, he's wired the delete
>> -t functionality to temporarily disable the SMF service
>> instance, which seems a reasonable option. However, having
>> delete -t tied in with SMF and create -t not tied in seems
>> asymmetric and (to me, at least) illustrates the awkwardness
>> of handling -t.
>>
>> ... to which you responded "As I say above that doesn't make sense to me."
>>
>
> Right. As in, the notion that this asymmetry is somehow an issue doesn't
> make sense to me. -t means do stuff outside of smf. Max's idea is just
> trying to be friendly there in a way that *is* consistent with what is
> being presented. I see no problem there.
>
> Personally, I don't even find that to be necessary -- I see no issue with
> having svcs show the smf state yet have tools to mess with the underlying
> thing. Because as a reminder, administrators don't ever need to run -t --
> it's there for our use in building the method scripts or for development/
> debugging/testing. (We have many other similar such options in our system
> today in various utilities.)
>
Will temporarily removal of a datalink configuration be involved in DR
process?
Say, if we have a vlan on top of bge0. If we DR out that bge0 card, will
that vlan be temporarily deleted?
Max
> But I also don't object to Max's approach of delete -t => disable -t.
> As I said, this is extending the boundaries of what has been done, so
> decide what seems reasonable and get input from others (as you're doing).
>
> As we evolve the SMF mechanism to contain new abstractions, there will be
> a natural evolution of the framework itself and how to use it. That is
> all goodness, because it contributes to the overall leverage point.
>
> -Mike
>
>
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 22, 2008 12:00 AM
in response to: cz147101
|
|
> >
> >Personally, I don't even find that to be necessary -- I see no issue with
> >having svcs show the smf state yet have tools to mess with the underlying
> >thing. Because as a reminder, administrators don't ever need to run -t --
> >it's there for our use in building the method scripts or for development/
> >debugging/testing. (We have many other similar such options in our system
> >today in various utilities.)
> >
> Will temporarily removal of a datalink configuration be involved in DR
> process?
> Say, if we have a vlan on top of bge0. If we DR out that bge0 card, will
> that vlan be temporarily deleted?
>
> Max
I think that causes it to go into the maintenance state. Because consider
the non-DR equivalent: I make an SMF config for datalink bge0, with VLAN
on top. It is saved. Now power off the box. Now remove bge0 card.
Now boot. At this point I will attempt to start bge0 datalink service,
but no bge0 device anymore -- so I should get maintenance state, telling
me to either fix or delete my config. So DR should be just like that.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
941
From:
Redwood City, CA
Registered:
3/9/05
|
|
|
|
Re: [nwam-discuss] smf instance for temporary
configuration
Posted:
Jan 22, 2008 5:33 PM
in response to: Mike Shapiro
|
|
Quoth Mike Shapiro on Sun, Jan 20, 2008 at 11:51:12PM -0800:
> On Thu, Jan 17, 2008 at 02:27:28AM +0800, Peter Memishian wrote:
> > > SMF should not support such temporary instances. SMF is not a replacement
> > > for every kernel state machine. Creating temporary network mods is the
> > > mental equivalent of starting a daemon outside of its smf instance -- it
> > > works, you can do it, etc. but it is not reflects in your svcs output.
I don't understand how temporary instances replaces the kernel's link
state machine. Can you explain please?
> > This is an interesting analogy and it makes some sense to me. However:
> >
> > * The actions needed to start a daemon are quite different from
> > those needed to have SMF start a daemon, but here the only
> > distinction is whether the "-t" flag is passed to dladm.
> >
> > Further, the semantics seem possibly surprising: if "-t" is not
> > used, then the dladm changes are immediately reflected in the
> > SMF configuration (along with the SMF configuration tied to
> > subsequent boots), so one might intuit that using "-t" will
> > still result in immediate changes to SMF configuration -- and
> > be surprised to discover no SMF changes were made at all.
>
> This doesn't make sense to me: dladm -t should mean muck with the
> abstractions but do nothing to the saved smf configuration.
> That's the equivalent of what it means now. Or to make another
> analogy, it's like running ifconfig without changing /etc/hostname.XXX
The current / post-boot behavior split embodied by daemon launching
/ init scripts and ifconfig / hostname files is, as far as I can tell,
born of implementation convenience and is something that SMF is trying
to abstract away by default. (That is, by default administrative
behavioral desires are enacted immediately and persist across reboot.
If the administrator truly desires behavior to change at reboot, then
that can be specified explicitly.) Otherwise, why does svcadm enable
start the daemon immediately? Why did we implement svcadm enable -t?
Why didn't we just tell each developer to document that the way to
initiate behavior which will not survive reboot is by launching the
daemon manually?
dladm -t creating instances may not make sense to you, but I think the
criterion should be whether it will make sense to users.
Since we've apparently already decided that the SMF tools are a valid
interface to link administration (since instance names must correspond
to link names), it seems to me that this decision (from a user
experience perspective, at least) boils down to whether the SMF
interface is as complete as the official interface (dladm). I think
most administrators will infer this (based primarily on the link name
correspondence), and would find the "it's not there because it doesn't
impact reboot" logic surprising. To do otherwise, it seems to me,
should require substantial supportability or implementation cost
arguments.
> > * From a conceptual standpoint, it's unclear to me why it's
> > unreasonable to model temporary configuration using SMF. I
> > agree with your point above that not every state machine needs
> > to be represented by SMF, but here we've already chosen to
> > model IP interfaces and datalinks using SMF, so it doesn't
> > strike me as unreasonable to model temporary ones too.
>
> You're misunderstanding my argument, then. The SMF state is not for a copy
> of what is going on in the kernel. It is for the saved state of how the
> admin wants the machine configured persistently.
SMF state (apart from configuration) is behavioral status. If the
kernel (or any other part of the system) is exhibiting behavior which is
contradicted by the status published by SMF, then that's a bug.
> You will want to have
> some way of manipulating the underlying abstractions without touching SMF
> if for no other reason than to implement your per-instance start methods.
Are you saying that all network interfaces must be documented for the
administrator, even if the networking team only introduces them to
implement the administrative interface?
David
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
