On Tue 08 Mar 2011 at 03:40PM, Brock Pytlik wrote: > 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 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.
If the zone that's being attached includes one or more publishers that is not also defined in the global zone, I don't think the system repo will help. Let's take the hypothetical situation in which a company was acquired and the sweep from the acquiring company's IT department upset the IP/DNS config a fair amount. Pre-cutover images that include application-specific repos are much more usable if the admin has control over how the origins are altered without having to configure inappropriate repos in the GZ. > 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. Currently we allow people to extract then "install -d" or "attach -d". Providing a more automated extraction mechanism may be helpful with upcoming enhancements. > > >>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 -- Mike Gerdts Solaris Core OS / Zones _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
