Peter Tribble wrote:
> So just for my own personal opinion, I do not want the model where everything
> I do is tagged as persistent. Non-persistent should be the default. If
> I'm typing
> commands, normally it's because I'm in experimental or debugging mode. If I
> want to make persistent changes then I'll automate or script or just go behind
> the back of the commands and edit the config file.
From a behavioral perspective that is what you would get; the issue is
the model by which the temporary/persistent is exposed to the
administrator, and then how it is implemented (some undo log being a
possible example).
> What *would* be really useful is a way of saying "hey, this is just perfect,
> now
> save the current configuration".
I think that is how routers and switches work (but I could be off on
that one). Basically all the config changes would be made to the running
configuration, and then at some point the admin can decide to update the
persistent configuration to be the same as the running one.
That is intuitive for single-purpose systems with a single admin. But
does it fall apart when there are separate admins for separate
subsystems? For instance one is handling ZFS and another the network
configuration.
If it turns out that one needs to have per-subsystem "save the current
configuration" then things suddenly become a lot more complex. If the
granularity is small (e.g., datalink administration is a different
subsystem than the IP administration), then you'd end up with dangling
references to temporary objects in an example like
dladm -t create-foo foo3 # create foo3 - non-persistent
ipadm -t create-bar -link foo3 bar7 #bar7 depends on foo3
ipadm save-current-config # oops - need to do dladm
save-current-config
yet to avoid the reference to the non-persistent object
I guess it is true that all the models have pluses and minuses.
The fundamental difficulty I see is that the mixture of persistent and
temporary objects, and how to copy with dependencies between them.
One approach we haven't discussed is just letting those dangling
references live (akin to symlinks to non-existent files).
Thus after boot in the above example ipadm would show bar7 depending on
foo3, but with a warning that foo3 is currently missing. (And if bar7 is
an IP interface, it would never have IFF_RUNNING set.)
I summary, the strict models I can think of are:
- save current config (applied for some subsystem and no dependencies
allowed between objects in different subsystems)
- if you try to create a persistent object that depends on a transient
object you get an error
- if you try to create a persistent object that depends on a transient
object we make that object persistent (that was actually written between
the lines in the "undo log" idea I floated)
I think in all of the above there is an implicit assumption that I can't
delete an object which has dependents (i.e., in the above example I
would not be allowed to delete foo3 since bar7 depends on it.)
The weak model (aka symlinks) might have some warnings when creating
dependencies on an object which does not (yet) exist, and when an object
with depedants are removed, but would otherwise deal with dangling
references to objects.
Erik
