Hi Ethan.
Thanks for your comments. My replies inline below. But first, do you
have an answer to this:
1) Question: Can someone please clarify for me how systems will be given
a unique hostname during an install without derived manifest project
affecting the enhanced SMF profiles? Are we relying on DHCP, or is
there some other mechanism?
I want to make sure that the out of the box case works for multiple systems.
On 06/22/09 22:51, Ethan Quach wrote:
> Jack,
>
> Just a couple of comments ....
>
>
> 2.1
>
> How does the "Maintainability" statement actually fair when we
> take into account the fact that the AI service stores copies
> of added manifests internally rather then referencing the
> original files to get the content?
Yes, I will clarify that maintainability here applies to the sys-admin
more than to the code. Changed to:
"Manifest maintainability is another benefit of splitting sections into
separate files. When a section file that is used in many manifests is
changed, the change propagates to all manifests which include it. This
is helpful in places where there are multiple manifests with common
install bits, where installations are done frequently (as in a center
with weekly classes)."
>
>
> 5.1.3 - last paragraph
>
> I'm not quite sure what this "second set of criteria" or
> "setup criteria" means. But its certainly not defined in the
> derived manifest functional spec.
I meant to remove this paragraph... Setup criteria was criteria for
helping derived manifests do their derivation. I removed the references
to it since derived manifests didn't mention it in its spec, that I saw.
>
>
> 5.2
>
> As I expressed in the meeting, I would prefer that our tooling
> not have to construct the separate DTD formatted file from
> content in the single-file scenario so that it can then be
> validated as a DTD, just to support having a single-file
> format scenario. If we're designing what we've been calling
> this "configuration section" to just simply be an SMF profile
> file, then there are boundaries around that that we just shouldn't
> cross.
There is a lot of passionate interest in having a single manifest file
for the simple case. Splitting out the SMF profile should be easy to do
in code. ==> There is lots of bang for the buck here. I'd like to keep
a single file solution in our plans.
Thanks,
Jack
>
> thanks,
> -ethan
>
>
>
> Jack Schwartz wrote:
>> Hi everyone.
>>
>> Please find the latest version of the Manifest Inter-File
>> Organization functional spec. (It is attached as I had trouble
>> uploading the pdf to the website.)
>>
>> It is the result of our meeting last week. There is now one manifest
>> of three sections.
>>
>> There are a few issues still to be worked out or questions I have. I
>> would appreciate feedback by Monday 6/22 COB.
>>
>> 1) Question: Can someone please clarify for me how systems will be
>> given a unique hostname during an install without derived manifest
>> project affecting the enhanced SMF profiles? Are we relying on DHCP,
>> or is there some other mechanism?
>>
>> 2) Section 5.2 paragraph 2 talks about a potential issue of an XML
>> authoring tool rejecting a single file containing a section with a
>> DTD header in the middle of the document. Are there other issues or
>> aspects of this issue which need to be brought up?
>>
>> 3) I removed the section on criteria used exclusively by the derived
>> manifests project because I couldn't find anything about in the
>> derived manifests functional spec. The criteria I am talking about
>> were to help in the derivation process (e.g. use derivation X if a
>> system has criteria x and use derivation Y for systems with criteria
>> y), as opposed to selection of which manifest to use.
>>
>> Thanks,
>> Jack
>>
>> P.S. I've cc'ed Ethan and Ginnie who I think are the most
>> knowledgable people to answer questions 1 and 3.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090623/eb39825c/attachment.html>
