Hi Sanjay,
Hi Sarah,
One more thing on the target schema. It is possible that I may be
misunderstand the schema. But, the proposed approach does not order
physical and logical elements. that is define the logical elements
and then physical. Your example on page 36 (Multiple Zpool use cases)
suggests such an ordering and it would nice to formalize that in the
schema.
This approach would also be really helpful for TI.
The schema does enforce an ordering within the elements that can be
specified as a target_device. So, a target device can be a disk or zpool
or swap or dump. Within these an ordering is set based on the element
definition.
I think the issue you are referring to is the fact that a user can
specify a disk as a top level device. The schema(modified based on
comments) only allows the user 1 disk as a top level target_device. The
reason for this is that we want to allow the user to specify a disk in
some way that is the root device and that doesn't require a zpool
encapsulation. AI will by default create a root zpool for the root
device if the root zpool isn't specified.
After the initial disk specification, all the other target_device types,
zpool, swap and dump do have a forced ordering based on their element
definitions. Attributes don't have to be specified in order, but
elements do within an element definition.
thanks,
sarah
***
-Sanjay
On 07/12/10 04:37 PM, Sarah Jelinek wrote:
Hi Dave,
On 07/ 7/10 06:20 PM, Sarah Jelinek wrote:
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.
I'd thought of the problem with having primary as an attribute as
well and, yeah, I agree that order is probably sufficient.
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.
I understand the concern. The flip side is whether these things
really are similar enough to be essentially subclasses of a common
superclass (which is how I tend to think about this aspect, perhaps
oddly :-). From that point of view I'm somewhat skeptical that they
belong together, but I also see that the overall extensibility is
more difficult if they're separated. Zones still seems an order of
magnitude more complex to me than the others, though.
Well... in looking at this I decided that zone configuration might
need to be separate. Beyond the possibility complexity of zones
configuration(which I think we can handle with a single schema), I
realized I needed to account for security concerns with regard to the
system configuration portion of the zone specification. So, I will
have to take a closer look at the zones configuration requirements
and propose either an additional schema or modifications to the
configuration schema if it makes sense to fit it in there.
I will be deferring this for a bit, but this doesn't hold anyone up
at this point. I will be starting work with the zones team on
defining the inputs required and the validation offered soon so I can
better define this schema.
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.
OK. I hope upcoming discussions with the networking team will help
clarify the need for this.
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.
One thing I was wondering is whether this is (or could be) the
generic hook to support 3rd-party configuration management systems
like puppet, bcfg2, cfengine.
Sure.. there is no reason it could not be.
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
_______________________________________________
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
