Sean McGrath wrote: > Jean McCormack stated: > >> Dave Miner wrote: >> >>> Sundar Yamunachari wrote: >>> >>>> Hi, >>>> >>>> The update to the the design document for the AI spring release >>>> based on comments, feedback and design considerations is at >>>> http://www.opensolaris.org/os/project/caiman/auto_install/Design_doc_delta_for_AI_Spring_2009.1.pdf. >>>> >>>> This can be also accessed from the Caiman documentation page at >>>> http://www.opensolaris.org/os/project/caiman/auto_install/Documentation. >>>> >>>> >>> 1.1 The service dependency descriptions here have been superceded, I >>> believe, by the results of discussion around jean's design note from >>> last week. >>> >> What we have is: >> svc:/network/dns/multicast:default optional restart_on restart >> svc:/network/tftp/udp6:default optional restart_on none >> svc:/network/http:apache22 required restart_on none >> > > Would it be restarting this appache fmri, svc:/network/http:apache22 ? > Our install server uses this fmri already. Others could be too or could > plan to. Perhaps creating svc:/network/http:apache22-ai instead. > Just my 2 cents. > No. This means that svc:/network/http:apache22 is required to be online or degraded before the installer/server:default service is started. That's the "required" part from above. The restart_on=none means the dependency is required only for startup. Our service restarts only if the dependency is fulfilled on startup.
Does that answer your question? Jean > Regards, > Sean. > . > >>> I have concerns about the service configuration file proposed here. >>> Was storing these in SMF property groups considered? The data seems >>> compatible with doing so. One of the points of SMF was to reduce the >>> need for lots of configuration file formats, each with their own >>> custom parsers. Are there other factors arguing against use of the >>> SMF repository? >>> >> Dave, >> >> The issue around using the SMF property groups, I believe, is the >> scalability factor. To do this we need to have a list of n sets of >> properties one for each possible install service. In our discussion last >> week you mentioned that SMF properties didn't scale very well. >> >> Or are you talking about starting up a new smf service for each install >> service? In that case the property groups would work very well. >> >> Jean >> >> >> >> >> >> >> >> >>> Dave >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>
