Hi Sue,
Thanks for the reviewing, and the additional comments ...
On 07/01/10 11:10, Sue Sohn wrote:
On 06/24/10 17:12, Ethan Quach wrote:
>
> I have posted an updated revision to the derived manifests design.
>
>
http://hub.opensolaris.org/bin/download/Project+caiman/DerivedManifests/DerivedManifestsDesignSpec.pdf
>
>
>
> Deltas from the previous version are interspersed throughout, but
> the relevant areas of change are Section 5.
>
> Also note, I am taking a look a the ManifestParser/Writer design to
> understand how the Manifest Input Module proposed in this design
> would fit in with that, so further changes there may occur. However,
> majority of the document should be reviewable. In particular, I would
> like to get any additional feedback on the AI server changes (Section
> 5.3) sooner than later.
>
>
> Comments by 7/1 appreciated.
>
>
> thanks,
> -ethan
>
> _______________________________________________
> caiman-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
Hi Ethan,
5.2.3.1
o Says script is copied to /var/sadm/system/logs/derived/manifest_script
Does this mean that the actual filename will be "manifest_script" and
that you won't be retaining the name of the user's script? If the
original filename is retained, then I'd suggest using
<manifest_script> in the doc. Ditto for /tmp/derived/manifest_script.
No, I actually meant the former.
o will log file inform user where to find manifest.xml and
manifest_script after reboot?
For cases where a derivation process occurred, yes.
o Here's an alternative for the first couple of sentences, feel free
to use or not:
For success to be considered, the script must exit with a return code
of '0', and the DMM must be able to syntactically validate the
resultant manifest. Upon this being successful, the DMM will consider
the derivation process successful and the derived manifest file
instance will be passed along to the next phase of the installer.
->
For the derivation process to be considered successful, the script
must exit with a return code of '0', and the DMM must be able to
syntactically validate the resultant manifest. At that point, the
derived manifest file instance will be passed along to the next phase
of the installer.
Thanks. I think I'll take your suggestion.
5.2.5 During the review of the previous version, you wrote the
following in a response to Jan:
> Something that's probably not obvious is that each individual
> call to aimanifest will end up writing out to file. Because each
> call is executed as a separate process and has to finish and
> return back to the script, the in-memory resultant manifest in
> the manifest input module library has to be written out to real
> storage each time. So for example, a single call to "aimanifest set
..."
> would internally have to call the following methods
>
> init()
> load() [to load the current state of file]
> set() [set whatever is being requested to be set]
> commit() [to write out current state of file]
>
> As a result, at the end of the script, the file will already be there.
> This also means that if the script died anywhere in the middle,
> the resultant file upto that time is also available for inspection.
This would be good information to include in this section. It is
hinted at a bit, but spelling it out clearly as above would be useful.
OK I'll add this explanation to the appropriate section.
5.3.2
o <manifest> -> <manifest/script>
o If no manifests have been added to a service, then the standard
manifest for the service would be designated at the default, I assume.
Might be worth noting that.
This behavior isn't changed from the current so I didn't bother, but
I'll add verbiage to be clear.
5.3.3
o Is there a backward compatibility story or does a user with existing
criteria manifests have to start over?
The server will support existing criteria manifests for older install
services. Support for this will be there for a certain number of builds
that is tbd. But new services will have to have their criteria specified
the new way.
o From the syntax specified for set-criteria, it looks like you can't
append the criteria in an XML file to existing criteria. Any reason
why not? That seems like something that might be desirable.
It was intentionally left out. The assumption was that written XML
files wouldn't be desirable to piecewise append to the already set criteria.
Having said that, we can add that functionality later if needed.
o if you use -a to append criteria and the same/similar criteria
already exists for the manifest, what is the result? For example, if
current criteria is MEM="2048-unbounded" and then the appended
criteria is MEM="1024-4096"?? Or if current criteria is
IPV4=”10.0.2.100-10.0.2.199” and appended criteria is
IPV4=”10.0.5.100-10.0.5.199”??
An error occurs. This would generate the same error as if
you specified the conflicting criteria when the manifest was
originally added.
And my usual list of nits/typos that I noticed:
5.2.3.1 the file are available -> the files are available
5.2.4
o intance_file -> instance_file
o get(xpath...) -> get(path...)
5.2.5 second bullet, XML file intance -> XML file instance
5.2.6 could also loaded -> could also be loaded
5.2.6.1 Its harder -> It's harder
5.2.7 (table, SI_MANIFEST_SCRIPT)
where manifest script was gotten -> where manifest script was obtained
5.3.3.1 SUNW,Sun-File-880 -> SUNW,Sun-Fire-880”
5.3.3.2 exmple -> example
5.3.3.3 It's -> Its
5.3.3.4 be in the form on -> be in the form of
5.3.4 leaving the any already -> leaving any already
All these are taken.
thanks,
-ethan
Thanks,
Sue
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
