Ethan Quach wrote: > > > 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? Yes. I wanted to make sure that there is a way to validate SC manifest. If it comes from svccfg, that is fine with me.
Thanks, Sundar > > > 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
