Hi Dave,
Thanks for the review. My comments inline...
Sarah,
e
Thanks for the updated spec. This review only covers section 6, but
there were a few items that I thought worth raising, apologies if they
duplicate others, I didn't compare with other comments. I'll look at
the rest tomorrow.
page 20: Should the image element also include support for image type
(full, user, zone) and properties ("pkg property")?
Good point, I will add this.
page 21: I'm still troubled about primary_source and secondary_source
in the software spec. It doesn't seem that the schema allows for
multiple secondary sources, does it? Would it make sense to merely
have a list of source elements and either make primary an attribute or
imply it based on order of appearance? One thing I brought up
previously that doesn't seem resolved is handling repositories that
require key & cert for authentication.
Yes, you are right, I didn't handle the key and cert stuff. I had it on
my list and forgot. Sorry about that. As for secondary source, no I
don't currently allow for multiples of these. I can make this possible,
and for each publisher multiple origins can be defined. I will change
this and add the key and cert.
Certainly I could have one source element which could be used, with an
attribute to specify primary or not, or allow the order to dictate. I
think if I did it this way the order should dictate primary and
secondary, since if primary is an attribute the instance document would
pass validation even if multiple sources were defined as primary. The
check in the client should fail, but the user wouldn't know this until
later. I will rework this.
page 26: I think the schema could use comments in each case where the
"options" element appears on the expected format of the options for
that usage.
Yes, I will add that.
page 28: I hadn't reviewed the config section before this version, but
I'm wondering whether zones really should be a distinct element, as it
appears to be fairly distinct from the other ones (and likely to grow
more complexity that might not translate well). Thoughts? A second
issue here is what the use case is for a "network" configuration type,
as well as "user"? None of the examples show one.
I could make zones configuration a distinct element. I can see that it
does have more complexity even now, with the manifest_text portion of
its definition. No other configuration element has this. However,
configuration is configuration. We could make a case that more complex
networking configuration might need additional things as well. It is
hard to predict and pulling out something now because it is more complex
than the other cases we know of seems premature.
To answer your other questions...
The network configuration is to allow for more complex networking
configuration, such as crossbow provides and allow a serialization of
this network configuration to be used during an install. The
serialization format would be something provided by the networking team,
much like the zonecfg export format is specific to zones and not
something we care about.
The user configuration is a placeholder to allow users to add user
specific configuration that isn't one of the standard configurations the
system supports. In particular this could be used for things like a
first boot service where the user has specified the configuration
properties and their user defined service makes use of these.
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
