Sundar Yamunachari wrote: > 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.
Let me try to clarify what you're saying here: you're saying you sent out the requirement just to note it, and if what's doing the validation comes from something else, like svccfg, then that fulfills your requirement. Is that correct? thanks, -ethan > > - 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 > > > ------------------------------------------------------------------------ > > Subject: > Re: [caiman-discuss] Please send XML parsing reqts to XML Parsing > Rework Team > From: > Sundar Yamunachari <sundar.yamunachari at sun.com> > Date: > Fri, 22 May 2009 10:22:29 -0700 > To: > Dave Miner <dave.miner at sun.com> > > To: > Dave Miner <dave.miner at sun.com> > CC: > caiman-discuss at opensolaris.org, Sundar Yamunachari > <Sundararajan.Yamunachari at sun.com> > > > Dave Miner wrote: >> Jack Schwartz wrote: >>> Hi Sundar. >>> >>> On 05/21/09 16:01, Sundar Yamunachari wrote: >>>> Jack Schwartz wrote: >>>>> Hi AI rework project teams, >>>>> >>>>> Please send your XML parsing requirements to the XML Parsing >>>>> Rework Team so that we can give you what you need. (Or, please >>>>> let us know that your team's requirements are already being >>>>> handled, if that is the case.) Please get the list to us as soon >>>>> as you can, by Thursday COB latest. >>>>> >>>>> For context, please have a look at the problem statements we are >>>>> solving, and have a look at the strawman proposal for an idea of >>>>> where we are going. The strawman proposal will be revised >>>>> according to your needs. Both can be found at: >>>>> >>>>> http://opensolaris.org/os/project/caiman/XML_Parsing/ >>>>> >>>>> Thanks, >>>>> Jack >>>> Jack, >>>> >>>> This requirements are from system configuration redesign task: >>>> >>>> - Should handle manifests that conforms to SMF DTD specifications >>>> - Should be able to take the system configuration manifest and >>>> validate against the schema >>>> >>>> - Sundar >>> These SC redesign requirements for XML parsing are no problem. >>> However, I was thinking that the SC manifest would just be passed >>> through the installer without interpretation, for SMF to process, >>> but I guess that is not the case. >>> >> >> Actually, I think it should be the case. Sundar, why would it not be? >> >> Dave > That will be the case. I am stating the obvious just to capture the > information. In my previous mail to Jack's strawman proposal, I even > suggested to make the SMF profiles as an element or pointer rather > than a separate manifest. > > - Sundar > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
