On 03/ 8/11 03:30 PM, Mike Gerdts wrote:
On Tue 08 Mar 2011 at 03:00PM, Brock Pytlik wrote:
On 03/ 8/11 12:34 PM, Mike Gerdts wrote:
[snip]
The system repo work introduces a distinction between user
configured publishers and publishers which the system provided for
the zone.
In the specific case of p2v, the following will happen. On attach,
the (now) zone, will be told to use the system repo to get its
publisher configuration. The publishers it finds there will be (as a
group) higher ranked than the publishers previously configured for
the image. The system publishers will also be in the same ranked
order as the global zone is. The user configured publishers (ie,
those that were configured in the physical image prior to the p2v)
will remain, but will be ranked behind all system publishers. If any
publisher is in both the system publishers and the user publishers,
the origins will be merged and the publisher will be at the system
publisher rank.
So, in your example, zone would end up with a "local" publisher with
two origins, one .sun.com and one .oracle.com.
The sysrepo will not disable publishers except in the case where a
publisher was previous a system publisher has disappeared from the
GZ, but packages were installed from that publisher.
The sysrepo will delete system publishers when they're removed from
the GZ, unless packages are installed from them.
The sysrepo will make enforce that publishers match on stickiness
between the GZ and NGZ.
The sysrepo will not change or remap origins of any user publishers
as I can't imagine how this could be done safely and regularly
without user intervention. The sysrepo will change, remove, and add
origins to any system publishers in order to make them match the
GZ's configuration.
The zoneadm p2v and v2v process is a non-interactive process and we have
no way to allow the sysadmin to "fix" anything with the image between
extracting it from an archive and the actual attach process. If the
attach process fails, it deletes everything that was extracted and tells
the user that the install/attach failed. Thus, the options for getting
past this are limited and non-trivial.
Given the situation that I ran into, I'm imagining that customers will
come up with other scenarious where they need to alter the
publisher/origin config to allow the attach to succeed. Initially I was
thinking that being able to provide some sort of a mapping file that
would be used by zoneadm attach would be helpful. The more I think
about it, I think that a more general solution may be to add an
install/attach option that says "extract the archive in the right place,
mount the active BE, but leave it as detached".
Could you elaborate on why they'd need to modify publishers to allow the
attach to succeed? In the situation you described, you'd end up with a
publisher with two origins, one functional, one not. Our transport
should be resilient to that situation. I haven't thought of any
situation yet where a user would have to be able to modify the zone
prior to attaching it, but it may be that I just haven't thought of it yet.
I think it's a separate question whether a user wants to modify the zone
prior to attaching it and whether we want to support that.
I think that covers everything asked about, but please let me know
what I missed or needs clarification.
Very helpful, thanks.
Glad I could help,
Brock
Thanks,
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
