Jack Schwartz wrote: > Hi Ethan. > > Ethan Quach wrote: >> Jack, >> >> 2.2 >> >> If the SC manifest is an enhanced smf profile then I don't see a >> need for the install tools (our parser) to understand how to >> parse and validate them. We've requested from the smf team >> the ability to use svccfg(1M) to validate a profile, which will >> do basic syntactical validation. We don't own the form of this >> file, so beyond that I don't see much more we could or should do. > I also asked about this when given the request, but our SMF enhance > profiles team said they wanted it. I didn't know about the svccfg > validation request from us. CC'ing Sundar, Evan and Joe to get their > response on this. We had a similar discussion when Jack sent the strawman proposal. I have attached the message. I have send this requirement just to capture that we need a parser to validate the enhanced SMF profile.
- Sundar >> >> >> 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. 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. (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. > > 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: > > - - - > > 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 > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss -------------- next part -------------- An embedded message was scrubbed... From: Sundar Yamunachari <[email protected]> Subject: Re: [caiman-discuss] Please send XML parsing reqts to XML Parsing Rework Team Date: Fri, 22 May 2009 10:22:29 -0700 Size: 6815 URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090528/b62a69ac/attachment.nws>
