On Tue 08 Mar 2011 at 04:22PM, Brock Pytlik wrote: > On 03/ 8/11 04:16 PM, Mike Gerdts wrote: > >[snip] > >>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. > > > > Why wouldn't the zone be allowed to have publishers that are not > defined in the global zone? I agree that providing the admin a way > to modify publishers is useful, it's less clear to me why that would > need to happen on attach, as opposed to prior to attaching or after > the zone has been attached and booted.
You have it backwards. Suppose the central IT group installs stuff in the global zone and has strict standards around which publishers can be set in the GZ image. An application team that owns a zone and maintains images of "golden zones" has their own repo(s). The way things work today, I'm pretty sure that if pkg is unable to reach any of the publishers during a "pkg update entire@$version" it will error out even if the unreachable repo doesn't contain any packages that are in the entire@$version dependency chain. This means that a DNS change that is outside of the application team's control makes the p2v/v2v archives unusable unless the GZ admin backs down and adds the application team's publishers. Suppose, however, that there were two application teams that followed the same cookbook while creating their repos. The publisher on each of them is called "myrepo" even though they contain different (and possibly conflicting) things. The origin is what determines the uniqueness of their content. These groups don't talk to each other, don't want to, and frankly, they talk to the central IT guys as little as possible. Aside from having two groups that adopt the same solution that integrates well with the OS, this seems to be a somewhat typical situation in large companies. In this situation the GZ admin is not able to define "myrepo" in the GZ to help one app team or the other as it would break p2v/v2v for the other. I suspect that with linked images in place, it stands a strong chance of breaking one of the conflicting app team's zones during the next GZ pkg update. I don't think that this is a problem that we have to solve today, but we should be thinking about it to be sure that we don't make it an impossible problem to solve with future udpates. As you described the system repo, it looks like it will handle the great majority of my concerns. > > In any case, I agree that, unless the repos in questions were > configured via the system publisher prior to the network cutover, > the system publisher doesn't help you here. > > Brock > > >>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. > > > [snip] > _______________________________________________ > 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
