Thanks for detailed explanation. It is definitely something we can
looking into.
-Sanjay
On 09/22/10 03:08 PM, Kyle McDonald wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
That simple case wouldn't - Unless you knew that the machines
this manifest applied to both had at least 2 disks and that they
were compatible, but the device names arne't always the same
Derived manifests should help here
Yes. But why force the user to setup derived manifest just to be able
to configure mirroring across many machines with a slightly different
HW config?
What is more useful for mirroring root is if AI could have logic
to pick a disk that is 'compatible' with 'boot_disk' and allow
you to reference it through 'boot_mirror'.
Interesting thought. What do envision the use case for this
functionality ?
So that one manifest could be reused and enable mirroring on many
clients without having to know the cXtYdZ device specifics.
Right now, if I don't want mirroring, I can use 'boot_disk' to select
the disk that AI has picked for the root disk and I don't have to know
anything else about the disk config of the target machines. I might
have 100 machiens that are all different.
But if I want to setup mirroring on all 100 machines, then I can't (as
I understand it) reuse the same manifest. I now have to generate 100
manifests with the specific device name of the main root disk and root
disk mirror.
If a second symbolic name were allowed in the manifest XML
(boot_mirror was my example) then I could continue to use one manifest
to install all 100 machines with mirroring enabled, and AI would pick
a suitable second disk on each machine with out me having to
pre-configure it.
In addition (whether 'boot_mirror' is possible or not) having
symbolic names for 'disk0' through 'diskN' would also be useful
in many cases.
Agreed, but that is part of vanity naming for disks which is
outside installs' scope. Admittedly this is something that is
desired given that disk names are getting very long.
I'm not talking about permanently naming each disk on the machine
after it's installed (vanity naming.)
I'm only talking about being able to create AI manifests that can
reference 'diskX' with out knowing exactly what the cXtYDz is. For
example I might have 10 machines that all have 10 disks, but the
devices aren't all numbered the same. I don't want to be forced to
collect up all the device names, and create 10 different manifests,
when I could just use 1 manifest that referenced the symbolic names
'disk1' through 'disk10'. This would be different than the
'boot_mirror' idea above, in that AI wouldn't have any logic for this,
it would just number the disks as it found them.
(Though it might be useful if it made 'disk1' the disk already
selected as 'boot_disk'.)
This both of these cases are things that Derived profiles can do. The
question is: "If this feature is added, how many users will be able to
avoid derived profiles altogether?"
If most users will still need derived profiels for other reasons, then
maybe it's not worth it, but if a significant number of users will be
saved from using derived profiles from either or both of these (and I
think the 'boot_mirror' one will help many people) then I think it's a
huge win.
-Kyle
-Sanjay
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (MingW32)
iQEcBAEBAgAGBQJMmnBCAAoJEEADRM+bKN5ww/QIAJKktez2Y8Td79d3T8vn7YzQ
qkAjaIBAb2Xv7gJFqrM+gMkYpAdNZYdl5aF2Cx0Cg72W5k63Lbl6/aaGaEcLcL7G
cjbj9uQtWm4ULa4Jdrs99kVKzL0xtt5RG2Q1dB2+jGYJVAGt1XSDUmjL7pzgQKyX
Rh/sze0cFjXlPVTrWUUhLrK7aHkO091g4NxNhgfMcHRvIcfsbPaqFptHfbKy+1eI
YeVWRTeGYilY++TiDZ5xZrfWJTmK3e8a+PhdDJmPsClrTRdd9SjoKl01vvW90ivQ
Sq2xVJbd3vJZeuo0+LzwLkw14JhuYwA/foyMSumKm9YEPpf8XNykX7+I3MM4vWk=
=qfxO
-----END PGP SIGNATURE-----
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
