Hi Dave,
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)?
fair point. I can move software as the high level element, and come up
with something for software_spec.
6.4: If the configuration type is implied, we default to user?
We would default to user, yes. I will add this in the comments section.
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.
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;
Seems reasonable, I can add this to DC.
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.
ok, that seems ok. I will change this to distribution.
- 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.
- 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.
- Are the existing GRUB menu customizations that are specified at a
high level expected to move to arguments to the checkpoint that
consumes them?
That's what I was thinking. I figured that this would be easier. I
didn't want to clutter the schema with this. If the user wants
modifications it seems as if they could provide this on the checkpoint
line as args. However, if others think it should be in the schema I am
open to that.
page 34, 8.3: When do we plan on addressing the version publishing issue?
I think that this is really up to AI and DC applications. DTD enables
versioning, but the applications have to decide how they publish the
versions they support. I don't think that this is required for the
schema design. I get that we need to get this versioning designed but
that is a separate design effort.
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.
ok, I will add the third possibility. In talking with Ethan he felt that
the reference to the system configuration wouldn't be secure based on
the fact that we cannot transport the system cannot transfer the SC spec
with the AI manifest together securely. The reference means that the
client must download the SC spec independently of receiving the AI
manifest. I agree it is left to the AI design, so can remove the
reference to security.
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.
Ok.. I will update the example to not do this :-).
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.
Fair enough. I think you are right, this would be more useful. It
shouldn't be an issue from the installer->manifest perspective. We have
to generate the package list and publishers from the installer media and
store this in the DOC for use in the output in the manifest. I will
rework these examples and add this as a note.
thanks,
sarah
****
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
