On 06/23/10 06:24, Matt Keenan wrote:
On 06/22/10 10:15 PM, Dave Miner wrote:
On 06/22/10 04:51 PM, Ethan Quach wrote:
On 06/22/10 13:06, Dave Miner wrote:
On 06/22/10 11:53 AM, Matt Keenan wrote:
On 06/22/10 04:42 PM, Dave Miner wrote:
On 06/22/10 11:36 AM, Matt Keenan wrote:
Dave,
Thanks for the review :
On 06/15/10 05:06 PM, Dave Miner wrote:
Overall a pretty complete spec. A few items:
3.2.1.1 - Section could use some reformatting, as there are
bullets
shown as parallel that are actually sub-bullets of a previous one.
Consider using some numbering here, maybe.
Yep, noticed this after I had sent out document, corrected now.
3.2.2.1 - What impact does this have on validation of the new
elements
introduced here?
Xmllint will do the required relaxng syntax checking, any other
validation required will be done within auto_install client code
itself,
manually.
Do you think I should be adding validation values in here ? as
according
to Ethan this file is being obsoleted, and I'd like to limit the
amount
of throw away code written.
No, I don't, just wanted to understand the impact.
3.2.2.4 (last bullet on page 15) - This phrasing is confusing:
"Pool
name does not exist. If pool name is specified in manifest, then
this
pool will be overwritten." I'm not sure what to expect - will an
existing, named pool be overwritten automatically?
Yes, if the the manifest contains a user specified pool name of
"my_new_pool", and this pool already exists on the target being
installed to then this pool will be overwritten.
That seems... dangerous. Wouldn't it be better to require a
specific
directive to overwrite an existing pool?
Ethan and myself discussed this very issue, and came to the
conclusion
that if the user specifically states the pool name they inherently
realize that this pool is going to be destroyed as we only support
the
"create" action for "zpool" elements.
Future development iterations could allow for "preserve" actions for
"zpool" elements which would cater for this.
I would normally error on the cautious side and not destroy existing
layouts, however as it is a create action I think this may be the
correct approach. I'm open to persuasion though.
One requirement that we haven't addressed yet is installing into an
existing pool. I'd like to ensure that whatever we do here is not in
conflict with meeting that requirement, and that's what concerns me
about this default behavior.
I would think that wanting to install into an existing pool must
be explicitly specified, so an additional attribute to the zpool tag
saying "use_existing" or something like will be what notes that
intent. Installing into an existing pool is akin to preservation or
saving of data, and hence it needs to be declared rather than
assumed, given explicitly selected devices and the notion of a
fresh install. By default, I think fresh installs need to behave
as fresh installs.
As an example, if I had a simple manifest that specified the
following (pseudo spec):
diskname c0t0d0s0
rootpool rpool
and if I were to use that manifest to install a system several times,
over and over again, when I finally boot and log into the system, I
would expect to see a freshly installed system with a clean rpool
and one clean BE. I wouldn't expect to see a potentially dirty rpool
with serveral aptly named BEs. For that result, one should have to
specifically note that with, for example, the following:
diskname c0t0d0s0
rootpool rpool use_existing
Let me know if you feel otherwise though, as getting on the
same page with this is important to do now.
Ethan, so are you suggesting I add this item as an attribute now ? or
can this wait until a later date when "preserve" will be supported ?
No, I'm not suggesting we have to add that now.
cheers
Matt
I think I agree, so long as the semantics of "use_existing" are such
that a non-existent pool means that the action reverts to "create the
pool".
Dave, yes, I think that semantic meaning should be the case.
thanks,
-ethan
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
