Hi Keith,
thank you very much for clarifying that point,
please see my response in line.
Jan
On 09/ 1/10 08:50 PM, Keith Mitchell wrote:
Hi Jan,
I will respond to your questions about the content of the images.
On 09/ 1/10 05:20 AM, Jan Damborsky wrote:
Hi Chris, Andrew,
please see my response below. I skipped points
which Clay already mentioned.
Thank you,
Jan
ai_sparc_image.xml, ai_x86_image.xml
------------------------------------
To be honest, I am not quite convinced that modifying existing AI images
to serve network text installer is going to meet our requirements.
The reason is that AI image contains just a subset of text install image.
This is intentional, since it allows to minimize memory footprint in
case of network AI (which is the main AI scenario) when solaris*.zlib
compressed archives reside in memory. And since AI installs from IPS
repository, content of AI image does not limit what is installed on
target system.
On the other hand, text installer just copies media content to the
target,
so there is currently 1:1 relationship between what is on media and what
gets installed. This is why text install image contains additional
bits comparing
to AI image.
[...]
I have two answers to this concern. The first answer is that such
considerations are intentionally being ignored with this initial
changeset, with the intent of addressing them later. It was felt that
it would be better to enable the functionality first, keeping the
focus on the code, and then worry about the image content issues
later. For now, I believe that the added versatility of having an
interactive, network booting installer justifies adding the text
install packages to the default AI images (even though it results in a
slight increase in image size; again I think that size increase is
acceptable for now, until we determine the final solution - see
below). Even though the installed target wouldn't have as much as an
official, text install media would, that's relatively easy to remedy
after installation using IPS to deliver whatever additional content is
desired.
I see. From your explanation, my understanding is
that this is proof of concept with next steps being
considered. That addresses my concerns.
The second answer is that there definitely should be some discussion
in this area. A few thoughts along those lines:
* The DC manifests should (and will) be updated to consume specific
"clusters" (rather than listing a full set of packages). These
clusters would probably be something like "auto_install,"
"minimal_install," and "server_install." In this example, auto_install
would define the set of packages need to boot via AI, and the other
two packages would be owned by RE and define "payloads" for the
install target.
That sounds reasonable.
* Expanding on the clusters and their usage, we can see that the
assumption that "contents of media" == "desired payload" do not
necessarily coincide. For AI, they definitely are different -
"auto_install" is the media contents, but babel_install is the
(default) payload. For liveCD and text install, they are currently the
same (babel_install and the "server_install" list of packages,
respectively).
* With the above points in mind, it becomes a bit clearer that it's
now a question of how to handle the limitation that a CPIO based
install can only ever deliver a payload that is equivalent to the
media contents. Is that an acceptable limitation?
I believe that no need for access to IPS repo in case of CPIO-only
installation
is the advantage which justifies existence of self-contained install media.
Of course it will never satisfy all install scenarios, but it could
satisfy bunch
of them if content of 'server_install' cluster targets desired audience.
If so, then we should define a set of default DC manifests with that
in mind (text, AI, text+AI, etc.). If not, then obviously the GUI and
text installers will need to be expanded to pick up additional payload
(via IPS).
Installing additional payload from IPS is something which is on the virtual
list of potential enhancement for interactive installers.
Currently low priority mostly due to the lack of business needs in that
realm.
Thanks,
Keith
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
