Sarah,
A couple more comments I missed initially
6.3 Target schema - The disk element needs to support more than just
a name attribute. The current AI manifest supports a few other items
for users to be able to identify the disk they want to use. They are:
name (which you already have)
volname
devid
devpath
type
vendor
size
These should probably be additional optional attributes to the disk
element. The first four must be mutually exclusive. The last three
are optional. I am not sure if you can define into the schema that
certain attributes can only be specified exclusive from another, but
if it is not, I suppose we can just document that, and make the ai
program semantically check for that validity.
I'm not understanding the relationship of the disk element and
the zpool/slice/partition elements. It doesn't seem to be referenced
by them, or them by it.
Under the zpool element, shouldn't dataset_options be a subelement
of dataset, and not zpool?
On 06/22/10 13:45, Sarah Jelinek wrote:
On 06/22/10 11:43 AM, Ethan Quach wrote:
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?
Yes, that is how I planned this to work. I have accounted for an
archive based install. If you look at the software_spec type I have
"archive" as one of the types and I point to the archive with the
primary source.
Ok. so it sounds like keeping primary source as a required
field is still a viable choice then?
I'll admit, I'm a bit wishy washy now. Might we one day support
some transfer mode for automated install outside of IPS and archive
based that doesn't require a source?
thanks,
-ethan
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)
Yes, that is what this example is showing. It's possible to do this
with zfs, and I wanted to be sure that I could support the zfs vdev
options.
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?
Yes, it would change the example. I will post a new example with these
changes in an updated design document.
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.
Ok, let me make this change and make sure it still works as I expect.
thanks,
sarah
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
_______________________________________________
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
