> 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.
My understanding is that command line arguments should be replaced by Application Properties which may then be processed using scf_simple_app_props_next(3SCF) and the like. Within the manifest these are stored as options/<name> within each instance. > > what i'm wondering is how to approach moving > configuration from > a set of commandline parameters to (VIsual > Panels-friendly) properties. Each property has a type associated with it making it Visual friendly. > 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 > is 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? > The idea is not to map properties to command line arguments within a script, but rather have the server read the properties directly. > would this type of solution work? or is there a > better way maybe? > thanks! > > alan Stacey Marshall This message posted from opensolaris.org
