Ah, we want to support more than just setting values in profiles. Our views differ in whether property or property group type should be considered configuration. I see type as definition delivered by service developer and should be modified only with updated manifests. If profiles is meant to deliver configuration customizations then changing type shouldn't be supported.
Anyhow, the difference is minor so I'm ok with your current proposal. -tony Antonello Cruz wrote: > 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 > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org
