On 01/24/11 02:27 PM, Karen Tung wrote:
Hi Keith,
Please see a few responses inline. I removed all the items that I
have no further comments on.
On 01/20/11 16:56, Keith Mitchell wrote:
5.3: Can you clarify why this belongs under
/.cdrom/.media-transfer/ vs. other potential locations, such as,
for example, the vendor-packages directory? For net-boot, I'm
concerned about being reliant on files not in the boot archive or
existing .zlibs.
I suggested /.cdrom/.media-transfer because I think it will be good
to centralize all the media transfer related things in 1 directory.
I decided to not put it in boot archive, since boot archive should
only have files that's required for booting. Even though these
2 files are very small, they are not required for booting, so, it is
against the "rules" to put it there.
I didn't put it in the .zlibs because everything in the .zlibs are
copied to the installed system. Yes, we can
filter them out, but again, it is kinda against the philosophy.
Most things that's currently in /.cdrom
are things that is created for live media only. Since this fits in
that category, I decided to have it under /.cdrom.
You have a good point about things not being in the boot archive or
existing .zlibs. However, if
the directory is an exported interface, we can always have the
installers download it as necessary.
As we discussed in person just a moment ago, since this checkpoint
belongs to the installers (as opposed to DC), it's probably packaged
in pkg:/system/library/install (along with, among other things, the
actual transfer checkpoint), so it shouldn't need any special
handling - it'll show up in vendor-packages with the other python
libraries.
I am thinking to deliver the checkpoint in the same directory as other
transfer checkpoint related files, since
it is used by both GUI and Text Installer. It will probably be named
something like:
/usr/lib/python2.6/vendor-packages/solaris_install/transfer/prep_media_transfer.py.
The function that will get registered with the engine, as well as the
2 checkpoints will
reside in that file.
5.3.2: Rather than splitting the registration path; can we leverage
the registration path? We have support for registering *functions*
as well as *classes* - so long as whatever it is returns an
instance of a checkpoint, whether it's a class constructor or
function doesn't matter. So, would it make sense to register a
function that will decide which kind of checkpoint to return?
Are you suggesting to register a function instead of a class because
you want to isolate the knowledge of whether
we are running a net-booted installer or a media booted installer
from the installer application?
I think this is a great idea. Going through how things will work if
we register a function, I have the following
algorithm in mind. Let me know if this is not what you have in mind
as well.
When the registered function is executed, it will determine whether
we are net booted or media booted.
If net booted, the special /.cdrom/.media-transfer directory will be
downloaded from the server,
and the NetPrepareMediaTransfer checkpoint will be instantiated and
returned. If booted from media,
the media's prepare transfer checkpoint will be instantiated and
returned.
The execute() of either NetPrepareMediaTransfer or PrepareMediaTransfer
will populate the DOC with the content of software.xml that's
downloaded or from media
accordingly. In the current version of my spec, populating the DOC
is done by the installer app,
but I think the above is better.
That sounds more or less like what I was thinking. Out of curiosity,
are you planning on using the dot-files to determine boot method
(.livecd, .textinstall, .autoinstall), or a different method?
By the time the installers are run, I believe I can determine the boot
method without relying on
on the .livecd, .textinstall and .autoinstall files.
I am planning to determine how we are booted based on how the zlibs
are mounted.
For example, if we are booting from media, solaris.zlib will be
mounted from /.cdrom/solaris.zlib
However, if we are booting from net, solaris.zlib will be mounted from
/tmp/solaris.zlib.
This creates a 'contract' of sorts between how the .zlibs are mounted
and how the installers run. While both are contained within slim_source,
perhaps the concept could be expanded one more level: check which SMF
services are enabled/disabled, perhaps. If filesystem/root:media is
enabled, it's a media-boot; if filesystem/root:net is enabled, it's a
net-boot.
- Keith
5.4.3: For similar reasons to my comment on 5.3, does this
software.xml actually belong in the boot archive or an existing .zlib?
Please see my answer above.
More importantly, as you noted to me in person a moment ago,
software.xml, being a derivative of the .livecd-cdrom-contents file,
can't be generated until just before the ISO is created, so it won't
end up in the .zlibs. However, as long as this is the single point of
"special hard-coded" knowledge that an installer checkpoint will
need, that seems acceptable.
Also, since we have decided to deliver the PrepareMediaTransfer
checkpoints in vendor_packages, we really don't need
a directory to store just the software.xml file. The software.xml
file will be stored directly in /.cdrom.
Also, the name of the file will be media_transfer.xml so it will be
more clear to others what the file contains.
Thanks,
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
