Hi Ethan,
Thank you for the review. My comments/questions inline...
Hi Sarah,
I looked at the updated design document, and focused mostly on the
AI aspect of the design.
page 21 and 22 - Did you mean to define the Configuraiton schema both
as one of the Common Application Schemas on page 21, and as its own on
page 22?
No, I didn't mean this. I meant to make it its own schema. I will remove
it from page 22. It is a common application schema.
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.
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?
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.
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.
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?
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.
page 42 - 7.1. eigth bullet - It seems auto-reboot has been moved to be
an AI specific attribute rather than part of the execution element, so I
think this bullet needs updating?
yes, it does. I will update this.
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'?
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
