Sarah,
Completing my review of v2.0.
6.1: Something that caught my eye once I spent more time with the
example manifests in section 9 is that the software_spec high level
element's name seems odd in comparison to the other high-level elements:
execution, target, configuration. What about just switching "software"
and "software_spec" in the schema (possibly coming up with a better name
for software_spec too, though I don't have one yet)?
6.4: If the configuration type is implied, we default to user?
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? Also, wondering if http_proxy should be part of the DC
schema as well. I know it's easily set as an environment variable and
that could be appropriate for DC, but that also implies that we'd need
to consume that variable in the application, and it also implies that
many DC users might need/want to unset it for just DC runs, which is
easy to forget to do; putting it in the manifest would seem to improve
reproducibility.
Several other things in 7.2:
- Did you consider using "distribution" as an element rather than
dc_instance? That's the current element in the relaxng schema and I
kind of like it.
- I wonder if the live_im element name is overly associated with a live CD.
- 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 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.
- Are the existing GRUB menu customizations that are specified at a high
level expected to move to arguments to the checkpoint that consumes them?
page 34, 8.3: When do we plan on addressing the version publishing issue?
page 35, 9.1: A couple of points about the configuration discussion
around the default instance. First, there's a third possibility:
interactive configuration occurs on first boot, which is what would
happen if no configuration is supplied. Second, I think it's unclear
whether there's any actual security difference between the two choices
presented for transporting configuration. This seems like something
best left to the AI design, not here.
page 37: Nit: the mirrored pool example here seems unreal; I can't
imagine actually configuring a mirror on two partitions of the same
device. Also appears on page 39.
9.4, 9.5: The software_spec in the generated manifests of this example
isn't quite what I expected; I anticipated that these would record the
package publisher & package set that is embodied in the media, since
that's more truly reproducible, not to mention useful to the
administrator using this as a basis to get started with AI.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
