John Forte wrote: > steve peng wrote: > >> John Forte wrote: >> >>> David Powell wrote: >>> >>> >>>>> A follow on question is do I need to call scf_pg_create on the >>>>> instance? It appears that property groups and properties are not >>>>> really inherited, they're somehow inherited for list purposes via >>>>> svcprop (and I assume the library get interfaces but I haven't tried >>>>> that yet) such that I would need to create the property group on the >>>>> instance in addition to the parent service if properties on that >>>>> instance only were expected to be modifiable by the admin. >>>>> >>>>> >>>> You do not need to call scf_pg_create on the instance. You do need >>>> to refresh the instance after making the change to the service for it >>>> to take effect, though. We require this so that if you were to make >>>> several changes to the service or instance, you don't run the risk of >>>> the instance seeing an incomplete or inconsistent configuration. >>>> >>>> >>>> >>> Okay. So does that imply that once I issue a refresh on the service, >>> either via libscf or svcadm, I should see the property group(s) I >>> created on the parent service using listpg? As you indicated, I do >>> indeed see the property group I created via 'svcprop <service-name>' >>> after issuing refresh and using 'svcprop -c <service-name>' before >>> the refresh , but after the refresh I still cannot modify the >>> property group/property as the error message returned indicates the >>> property group does not exist on the instance nor does listpg show >>> it. Sorry if I'm still missing something obvious here. >>> >>> >> Which level are you at when you run listpg? If you are at instance >> level then you may not see the pg >> at service level. >> > Yes, I'm viewing it at the instance level. > >> As David mentioned, any pg created at service level is inherited by >> its instance but I doubt you >> can mod it at instance level. >> > Then I'm not understanding why you cannot change it. I thought that was > the one of the points of having instances, so that they can be > individually managed at the property level, not just the method level. > > Dave's comment above seems to imply that changes can be made at the > instance level anyway. > General smf guidance is all props that would not be changed by a diff copy of service (instance) should be defined at the service level, otherwise at the instance level. So if you have props defined at the service level then they should not be modified by the instance. If you want something that can be override by instance then it should be defined at the instance level. For example:
svc:/system/system-log:default> listpg general framework restarter framework svc:/system/system-log:default> You can mod props on the list of general and restarter but you can't mod props on the list of listpg of svc:/system/system-log. Steve >> >>> And if it matters at all, this particular service does not have a >>> refresh method defined in the manifest as it cannot effectively >>> support refresh but I am assuming that there is some default behavior >>> defined for start, stop and refresh when a method is not declared. >>> Maybe this is part of my problem as well. >>> >>> >> 'refresh' method is optional. >> > Yes, that I read. I was mentioning it because I wanted to ensure that > not having it defined in the manifest would not have any impact on the > behavior I'm seeing. > > - John > >> Steve >> >>> - John >>> >>> >>>> Dave >>>> >>>> >>>> >>> _______________________________________________ >>> smf-discuss mailing list >>> smf-discuss at opensolaris.org >>> >>> > > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org >
