On 06/22/10 07:34, Sarah Jelinek wrote:
Hi Ethan,
On 06/21/10 05:13 PM, Ethan Quach wrote:
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.
Ok, I can make this change.
The only other thing I can think of is future support for archive
based install. Not sure if you'd considered this yet, but in those
cases, a repository might not be required to do an installation.
But if this element here is abstracted as a "source" as you've
noted, then it could probably still be marked required as it
could also encapsulate the location of where an archived is to
be fetched from?
OK. Looking at how facets are specified, they are not a simple string,
so those things themselves may need to be elements.
Ok, let me do some research on this and I will add the changes to the
software_spec schema.
OK.
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?
It would look like:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE target SYSTEM
"file:///export/home/sjelinek/work/doc/install_misc/xml/target.dtd">
<!--
This instance document shows the creation of a zpool, with
the full
disk specified for the mirror vdev, via the s2 slice which will
be labeled(created) for the use in the zpool, and use of
existing slices for the raidz vdev.
-->
<target>
<target_device>
<zpool name="sarahs_pool" action="create">
<vdev>
<mirror>
<!--
If no size is specified the slice
will
take up the full disk or partition.
-->
<slice name="c1t0d0s1">
<size val="1000"></size>
</slice>
<slice name="c1t1d0s1">
<size val="1000"></size>
</slice>
</mirror>
</vdev>
<vdev>
<raidz>
<slice name="c1t2d0s0"></slice>
<slice name="c1t3d0s0"></slice>
</raidz>
</vdev>
</zpool>
</target_device>
</target>
This looks good.
(Just a nit, but this is probably an unlikely example right? It seems
this example is creating a stripe of two vdevs, one being a 2-way mirror
and the other a 2-disk raidz)
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)
Ok, I will make this change.
Just to clarify, the addition of this change would make the above
example a little different now as well correct, since the <mirror>
element is now a 'type' attribute for the <vdev> element?
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 ?
Well.. perhaps my interpretation needs to be modified :-). I can see
the conflict you indicate, and if the user wants to use the existing
solaris 2 partition, but wants to delete other partitions we should
allow them to do this. I am wondering if my overloading the 'preserve'
attribute to include both 'preserve' and use_existing is wrong. Should
I keep the non-mention of any partition as simply preserve,
I think that would be logical.
and allow the user to additionally specify the use_existing?
That seems logical as well.
thanks,
-ethan
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'.
Ok, I will change.
thanks,
sarah
*****
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
_______________________________________________
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
