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.
>
>
> 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
