Sarah, just a couple of follow-up points.
7.1, 7.2: Both of the AI and DC schema definitions seem to rely on the
software_spec entity being included by the configuration entity.
Should it be that way?
The reason it is done this way is the zones configuration needs. Which
may point to a case to make the zones configuration as separate.
Although, the minute I use the manifest_text for the zones, which is
really a software_spec, we have it embedded in a schema. So, the minute
we include the zones configuration schema for the AI schema we have the
same issue. The only other thing I can do is not reuse the software_spec
schema as type for the manifest_text element in the zones configuration
schema. I had hoped to reuse what was already defined, that is the
software_spec, rather than reinventing something else. Maybe I can't
really do this.
We can't just have a direct reference to it in the main schema?
- I wonder if the live_im element name is overly associated with a
live CD.
ok.. any suggestions on a name?
- Relatedly, I wonder if we really need the separate live_im vs.
vm_img (there's some inconsistency in the schema between vm_im and
vm_img, it seems) elements. They appear to be identical, so how is the
usage envisioned to be different (there isn't a use case for a VM
construction shown so I'm not clear)? Would an attribute on another
element be sufficient?
I didn't have this initially, that is if we need separate image types,
but although they are the same today in DC, it seemed as if we wanted
these two image types as elements, in case the format of the image
element would become different between the two. That's why I stuck with
this in the schema.
OK, I'll buy keeping them separate. Maybe "media_img" and "vm_img" (or
just media_image and vm_image) as element names?
- I think the compression element for the overall images should
default to lzma so that developers get default behavior that's closest
to our standard images. boot archives obviously need to default to
gzip, though. However, as I think about this, I really wonder whether
these elements should be moved to arguments to the respective
checkpoints.
It could be args to the respective checkpoints. Let me look at this a bit.
I think it's relatively unusual to modify, and I think putting it at the
top level actually creates confusion between this compression and the
boot archive's compression, so I think moving it down is appropriate.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
