On 01/18/11 13:28, Keith Mitchell wrote:
Hi Karen,
I have some comments and questions. Overall, I really like the concept
(it will most certainly simplify the netboot text installer path, and
eliminate some failure scenarios for those use cases).
5.2: Under destination, are you proposing that "/a" be hard-coded? I
would think that the temporary mountpoint used by the installers
should be controlled by the installers, and that we wouldn't want DC
to have knowledge of that.
Yes, that's a good point. I will make it a variable that will be filled
in by the installers before calling the transfer checkpoint.
For other values in the sample, (such as "dev" as an install dir),
when this file is generated at DC build time, will they be pulled from
an XML template? Coded as part of the checkpoint ('constants' in the
Python file)? Or pulled dynamically from somewhere else?
Those will be hard coded as part of the checkpoint. DC checkpoints that
we provide have hard coded knowledge
about the layout of the image. So, it makes sense that they also
contain the knowledge about exactly
what need to be copied to the installed system. If people decide to
change the layout of the image for
whatever reason, they might also need to change what gets installed in
the system. I will either make them as constants in the
Python file, or put all the logic in a function or something so that
people can easily find the code to modify, if needed.
For "{cdrom.mountpoint}", since for some scenarios (net-booted text
install primarily), it's not really a "CDROM", would a different name
for the variable be more appropriate? Alternatively, would it make
sense to diverge physical media from netbooted media here (i.e.,
create a separate .zlib of items that would have been on .cdrom for
the net-booted case)?
What about calling it "media.mountpoint"?
Personally, I don't think it is necessary to diverge the physical media
from netbooted media. As you have
found from doing the netboot text installer project, the only thing
that's really needed from the
/.cdrom for the installed system are those files in the /.cdrom/save folder.
Now that we will have the list of needed files from the .cdrom populated
in the DOC, the
netboot prepare transfer checkpoint can just go through that list and
download the necessary files.
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.
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.
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.
5.5: For step 4, would it make sense instead to enhance manifest
reader to support this use case? Or is a separate DOC instance better?
Is this process done by the installer, or by a checkpoint, or as part
of registration?
If we enhance the manifest reader to support this case, that means we
want to add
the ability for the manifest reader to instantiate a DOC with 2 input
manifest files.
We will need to add logic in the manifest reader to deal with duplicate
entries
or conflicting entries, to take care of all cases.
With this particular case, for the Text/GUI installer, since the DOC
manipulated
by the Text/GUI installer is not currently instantiated by input
manifests, we
know for a fact that when we "merge" in the software.xml file containing
the list of files/directory to cpio, we can safely assume that there's
no duplicate
entry already existing in the DOC. We can just add our entries there.
For simplicity, I think it is better to just load the software.xml into
a separate DOC instance,
and copy the objects over.
As discussed above, loading the software.xml information into the
installer's DOC
can be done in the execute() function of the PrepareMediaTransfer
checkpoint.
Thanks,
--Karen
- Keith
On 01/14/11 10:55 PM, Karen Tung wrote:
Hi,
Please review my proposed design of cpio-based transfer for
the GUI and Text Installer.
I checked the file into the caiman-docs gate under media-transfer
directory.
You can also access the design doc directly here:
http://src.opensolaris.org/source/xref/caiman/caiman-docs/media-transfer/media-transfer.pdf
Please provide your comments by next Friday 1/21/2011.
Thanks,
--Karen
_______________________________________________
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
