hi Liane
i have a quick question relating to one of the policy
guidelines (i know the document isn't intended to
be a HOWTO, but i thought this thread would be a good
place to ask).
the guideline is this one:
"Service configuration stored in the repository must be represented using
distinct,
documented properties. Catch-all properties for things like command line
arguments are not allowed."
in the particular case i'm dealing with, i need to upgrade from
configurations that specify daemon program and commandline arguments
to same (see routeadm (1M). the way we were doing this was to
migrate daemon arguments to a daemon-args property in the upgraded
service instance, obviously that doesn't fit with the guidelines.
what i'm wondering is how to approach moving configuration from
a set of commandline parameters to (VIsual Panels-friendly) properties.
one thought i had is the start/refresh methods of the service could carry out
the mapping, i.e. they would
- read the daemon-args property
- migrate each parameter to it's specific property
- blank the daemon-args property
this would mean if a user sets the daemon-args property again
later, the setting would be reflected in how the daemon was run.
should i "hide" the daemon-args from the user by not associating
them with the other application properties maybe to avoid
users setting them?
would this type of solution work? or is there a better way maybe?
thanks!
alan
This message posted from opensolaris.org
