We don't allow properties with the same name and different property types. So if if a profile sets a value in an existing property but with a different value, we replace the existing property with the configuration in the profile. It may be part of configuration to change the type of a particular property to a compatible type. If the type is unintentionally changed to an incompatible one, the consumer will fail with SCF_ERROR_TYPE_MISMATCH. Replacing an existing property is the obvious action. Anything beyond that, would be guess work.
Similarly, with property groups, we cannot have pgs with same name and different types. However, we don't change the pg type because it is unclear what that should mean. Should we discard existing properties in that pg and apply only the properties defined in the profile? Should we copy the existing properties over to the newly typed pg? Keeping the existing pg type is the sensible approach here. Antonello Tony Nguyen wrote: > Looks good. Just one comment. > > --- svccfg.man1m.original Tue Jun 16 10:47:31 2009 > +++ svccfg.man1m Fri Jun 19 16:53:08 2009 > @@ -103,14 +103,20 @@ > Service Profile Subcommands > apply file > > - If file is a service profile, then service instances > - specified within the file are enabled or disabled > - according to it. See smf(5) for a description of service > - profiles. This command requires privileges to modify the > - "general/enabled" property of the service instances. See > - smf_security(5) for the privileges required to modify > - properties. If file is not a service profile, the sub- > - command fails. > + If a file is a service profile, properties, including > + general/enabled, which are specified in the file are > + modified in the repository. Non-existing properties and > + property groups will be created. The type of > + pre-existing property groups will not be changed by the > + profile. Existing properties can have their type > + changed by the profile. > > Why do we allow changing property type and not property group? I'd think > type is part of definition and not configuration. Is there a use case > where we'd want to override existing property type? > > -tony > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org
