On 06/21/10 11:33, Sarah Jelinek wrote:
Hi Ethan,
Thank you for the review. My comments/questions inline...
page 23 - What do the "unknown" values for action and type mean?
Actually, the default value for action should be install, not unknown.
I put these in their to be a placeholder for any unknown values that
are specified for these attributes. They are strictly required since
the parser will catch any values that don't match. I will remove them.
OK
page 23/24 - Earlier in the doc, I thought there was mention that the
primary source (which is the equivalent of the default repo for type IPS
I'm presuming) should be required for both AI and DC usage, so is the
comment saying that its not required inaccurate?
I moved it to optional since at this time it is optional in AI. I
figured making it optional in DC would also make sense. In each case
we can clearly default to reasonable values. I initially had stated,
as you noted, on page 6 that this should be required for both. But, in
looking at this I changed my mind. I think optional is fine. Concerns
about this?
Not huge concerns, but to me, hardcoding http://pkg.opensolaris.org/release
into the ai program would be undesirable. I'd much rather for it to be
a required field and provide templates with such values in them instead.
Also, how does one specify mirror, origin, or facet information for the
repo? Mirrors are something we support today, and the latter two
specifications have been requested. Facets in particular are how
locales are to be specified so that is something we need to account
for. Perhaps the source attributes should be elements instead?
Maybe.. I didn't include the mirror, which I should have. I wasn't
aware of facets but if I move the source attributes to elements, I
could then add mirror and facets as attributes of these elements. let
me take a look this a bit more. At a minimum, I missed specifying the
mirror which needs to be included.
OK. Looking at how facets are specified, they are not a simple string,
so those things themselves may need to be elements.
page 30 - I'm not seeing the reason why we'd need the additional
<type> tag element layer. Can you explain?
I could remove the 'type' element and just do this:
<!ELEMENT target_device(partition|slice|zpool|vdev|dataset|disk)>
This would remove this extra layer of element. This might be cleaner.
I think that's along the lines of what I was I was thinking. What
would the example instance file snippet look like with this change?
The same comment for the <vdev> element. Would seem simpler if
the <vdev> element had a type attribute that was one of mirror|raid
I can certainly remove the 'type' element. As for the vdev, I could
make it either mirror or raidz as an attribute, but we also allow for
non-mirrored and raidz'd roots, right? I was trying to capture the
ability to do this. I suppose I could do something like:
<!ELEMENT vdev (partition|slice|file)>
<!ATT LIST vdev redundancy (mirror|raidz|none) "mirror">
none means no redundancy.
Is this what you were thinking?
Yes, that's seem reasonable. Though it should probably be:
(mirror|raidz|raidz1|raidz2|raidz3|none)
page 42 - 7.1 second bullet - Today an action type of 'preserve' allows
a user to specify that a single partition is to be preserved, not
that the
whole table is to be preserved. Any reason why you specified this
functionality usage to be different?
Right now with AI we only preserve slices, right? I didn't see
anything in the AI schema that dealt with preserving partitions, only
the ability to specify to use an existing Solaris 2 partition. What I
was trying to do was align these two actions under one, "preserve" and
keep the same behavior for slices as well as using existing Solaris 2
partition. So, in this case I felt if the user wanted to use the
existing Solaris 2 partition, that means we don't modify the partition
table at all.
Yes, you're right, that is true about partitions. Currently in AI (and
in jumpstart as well), is that the non-mention of any partition simply
implies don't touch, or preserve it.
However with your proposed interpretation of "preserve" used with
partitions, it seem there could be a conflict when there are two partition
directives. For example, if you had one saying delete partition one,
and then another saying preserve the solaris partition, do we or do
we not delete partition one ?
page 42 - 7.1. ninth bullet - I wonder if the default logic should be
reversed.
In the majority of cases, there will typically be existing data on
the devices
being specified to install onto, and users normally just want to
reinstall.
So, you are saying the default should be set to 'true'?
Yes. The current behavior in AI is also like that for slices. The element
is called 'on_existing', and the values are either 'overwrite' or 'error'.
The default is 'overwrite'.
thanks,
-ethan
thanks,
sarah
****
thanks,
-ethan
On 06/07/10 15:08, Sarah Jelinek wrote:
Hi All,
I hate replying to my own email, but in discussion with other folks
it has become clear to me that something I assumed isn't as obvious
to others as it is to me. Go figure :-).
The design proposal has two major parts in my thought process:
1) Schema elements and attributes. Basically the user interface in
XML that we want to present; It's form and content.
2) Schema language.
# 1 as outlined Section 5.3 is the user interface that we will
export. This is the first critical piece I need to be reviewed. I
need folks to look at the elements and attributes proposed, and the
XML instance documents associated with these(Starting on page 24,
listed after each schema definition). Key things to look at are:
-Are the elements sufficient to describe what we need to correctly
and fully represent the the user possibilities in AI and DC?
-Are their elements and/or attributes missing that are necessary?
-Are the elements and attributes defined in a way that allows ease
of use from a user perspective? Are they too nested, not nested
enough, not constrained enough, etc...
-Are the required and optional tags correct? That is are there
things that are required that are not specified that way, and vice
versa?
#2) The schema language is a secondary piece of the design. I
believe that if we have a good XML definition for our documents, one
that provides an easy to use and complete specification for users
then we can create a schema to match this. The schema language may
help provide a better definition in some cases, but there isn't a
1-1 relationship in the user interface design and the schema language.
Please review this proposal with these thoughts in mind.
Thank you for your time.
sarah
****
On 06/ 1/10 05:49 PM, Sarah Jelinek wrote:
Hi All,
A redesign effort has been under way for both the AI/DC schemas,
and as a result the manifests themselves. The documents listed
below are the first draft of the redesign proposal.
The documents are located in the caiman-doc repository both the
.odt and .pdf version of the AI/DC Schema and Manifest Redesign
document. You can get the docs here:
ssh://[email protected]/hg/caiman/caiman-docs
by pulling a clone.
I have also posted both versions on the opensolaris.org caiman
project page:
http://hub.opensolaris.org/bin/download/Project+caiman/WebHome/aidcmanifest.odt
http://hub.opensolaris.org/bin/download/Project+caiman/WebHome/aidcmanifest.pdf
Please send your feedback to the alias by 6/22/10.
If you plan to provide a review, please email me privately so I can
keep track of those who want to participate in the review. If you
need more time please let me know when you think you can complete
the review.
As always, thank you for your time and attention.
Regards,
sarah
_______________________________________________
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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
