Hi Ethan, Apologies for being late to this party :-).
My comments below. I did not review others comments, so there may be repeats in mine. I wanted to get this reviewed so decide to take the fastest route. If you have answered any of my questions previously, just point me at the thread. > 2. a metadata file > - containing data describing what's been shipped over via > this service. This includes the distinction of what > type of manifest #1 is -- manifest instance, or script. > - (*** metadata from the service -> client could have other usages > - if and where to push its remote logging / progress reporting. > - validation (hash values) of everything the client's downloaded > from this service? > - in anticipation of the system configuration work using SMF > profiles as the specification, a service will have to handle > this file as a separate entity from the AI manifest. Why do we need a metadata file? Seems to me that with the service choosing engine, if a dynamic script is specified as part of the AI service, which I assume it would have to be to create the metadata file, then we simply download what the service points at, right? I am concerned about introducing yet another file that we have to maintain and possibly add to later. The system configuration work using eSMF profiles doesn't seem to require this either, since these will be pointed to in the AI manifest, it seems that the AI client would get the location of these and download them as it, without additional metadata. Or, we could include in the schema a tag that represents the dynamic manifest script, so we always download only one manifest. This manifest could be the default manifest, or not, and the script should only update those things that the user is interested in getting dynamically. The script always trumps anything specified in the manifest. Seems to me that this scheme, in particular without the metadata file, would work whether the AI microroot was booted, or on a live system. Also, this is a general question.. Is there any need for dynamic manifest capability for DC? I am asking only because you are introducing this new command, /usr/sbin/aimanifest, for manipulation of the ManifestServ(or its replacement as part of the architecture work), which might also be interesting to DC since it uses the same mechanism to parse and populate objects from the DC Manifest. With the manifest rework the AI and DC data portions of the manifests will be the same, so this could be generally useful. I am not sure if there is a need, but it could be useful. One thing I can think of that might be useful to DC for a derived manifest is perhaps to query the repo it is downloading packages from and create a dynamic list based on availability. > With this proposal, the grammar of the AI manifest is also being visited > to shorten element/tag names where possible. Because we're proposing the > usage of dynamic manifest scripts to reference nodepaths from the AI manifest, > having shorter, simpler names makes this easier to use. In addition to this > reason, there are currently elements who's names unneccessarily include its > heirarchical parent element name again. For example, > > <ai_target_device> > <target_device_name> > <target_device_type> > <target_device_vendor> > <target_device_size> > ... > .. > > could be simplified to > > <target_device> > <name> > <type> > <vendor> > <size> I like this. I will keep this in mind with the AI/DC Manifest schema rework I am doing. This would translate well to use for both DC and AI. A general comment... I would look at zonecfg as an example of a cli for interactively modifying or creating a manifest. Essentially, a manifest is a configuration specification for an AI install(not system configuration) and they do a good job with this for zones. thanks, sarah **** Ethan Quach wrote: > caimanians, > > Below is a strawman for how derived manifests could work. Would > appreciate comments/thoughts by 1/13. > > > thanks, > -ethan > > > > ------------------------------------------------------------------------ > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
