On 01/20/11 03:51 PM, Karen Tung wrote:
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.
That makes sense.
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"?
That works for me.
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.
That also works for me. If the list grows longer in the future (and it
becomes more viable to package a large set of files in a .zlib), this
software.xml and the media transfer checkpoint can evolve to handle that
as needed.
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.
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?
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.
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.
As an alternative option, the implementation could allow for creating a
clean child node at some point in the DOC tree, and loading the manifest
into that child (effectively isolating it from any existing DOC nodes).
However, these are just ideas I'm tossing out there - I don't see any
major benefit or downside to either approach.
Thanks,
Keith
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
