Jack Schwartz wrote: > Ethan Quach wrote: >> 5.3 >> >> > If the Sysmap Manifest contains no criteria, it will serve as a >> > default, and will ?match? all systems for which no Sysmap >> > Manifest with explicit matching criteria exist. >> >> What if there are two Sysmap Manifests added which have no >> criteria, which one acts is the default manifest for this install >> service? > Good point. >> Have you looked at section 1.4 of >> http://www.opensolaris.org/os/project/caiman/auto_install/Design_doc_delta_for_AI_Spring_2009.pdf >> >> >> >> This documents the design decisions we made regarding AI >> manifest usability in the spring. Not everything in that document >> applies to this project, and some things might have changed >> or don't apply anymore because of all this redesign going on. >> But leverage whatever you can from it. All of that stuff was >> discussed and agreed upon in the open, with Frank's input. >> > I like the idea of mapping a default manifest to each service.
By definition all install services have a default manifest. (unless the services redesign project has changed this.) > I'm envisioning a default manifest which would validate to a schema > containing no criteria sets, and a non-default manifest which would > validate to a schema which would be like the no-criteria-set-schema > except that it would include criteria sets. If its legal to have a manifest with no criteria, why would we need two distinctly defined schemas? > (Here's where the sub-schema thing can work well: have the > no-criteria-set schema be a subschema to the with-criteria-set schema. Fyi, I looked at the current criteria_schema.rng and it appears we already do this subschema thing. The ai_manifest.rng is ref'ed inside the criteria_schema.rng > > default manifest non-default manifest > > non-default schema (includes criteria set defs) > / > (subschema to) > / > default schema > > Then, new default manifests would have to validate to the default > schema before being installed as the new default manifest. The two > kinds of manifests are kept as separate entities. There would need to > be special commands for installing new default sysmap manifests, as > layed out in section 1.4.4 of the delta design document. I'll CC Sue > to be sure she sees this. > > I'll add the file layout and its reasoning to the functional > specification. >> >> 6.1 >> >> > XXX I assume here that derived profiles can be used for SC >> > manifest (as well as AI manifest) >> >> The SC manifest has not been in the scope of the Derived >> Manifests work. Though, I suppose it could be considered. > I could be wrong, but I think we need it... Here's my reasoning... > > Hostnames are to be set up via SMF, per the doc Sundar sent out. If > you are installing multiple systems with the same bits on a single > network, how would each be given a unique hostname to live on the same > network together? (Or maybe DHCP is a requirement?) > > Let me know if I am incorrect and I'll remove the following from my doc: The statement above sounds correct, but that doesn't necessarily mean the derived manifest mechanism is what's going to drive that. We need to discuss this some more, but for now, I wouldn't assume derived manifests is going to derive the SC manifest. thanks, -ethan > > - - - > > Derived Profiles can dynamically generate parameters values which are > unique to each system, allowing similarly-installed systems to > co-exist on the same network. > > XXX I assume here that derived profiles can be used for SC manifest > (as well as AI manifest) > > - - - > > Thanks for your review. > > Updated doc with your and Sarah's comments is posted at: > http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_2_func_spec.3.pdf > > > > Thanks, > Jack >> >> >> thanks, >> -ethan >> >> >> Jack Schwartz wrote: >>> Hi everyone. >>> >>> Here is a link to a "functional specification" for solving the XML >>> parsing problem of "Current AI manifests are not easy to use." It is >>> a rough draft, and I'm posting it to verify that I am on the right >>> track. >>> >>> It deals with XML problem statement 2: >>> >>> Current AI manifests are not easy to use. >>> >>> Its scope is inter-file organization of the manifests (naming, >>> high-level structure, inter-relatedness), which is quite a limited >>> scope for a functional specification. Other redesign tasks (XML and >>> others) will tackle the fields inside the manifests. >>> >>> Please send comments / feedback by lunchtime tomorrow. >>> >>> http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_2_func_spec.pdf >>> >>> >>> >>> Thanks, >>> Jack >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
