Re: [zones-discuss] Update on attach and upgrades
Henrik Johansson wrote: The easiest way would probably be to identify packages that are not to be updated, in my experience packages do not differ that much between local zones in production environments, but that is only based on the system I have worked with. I always keep zones as similar as possible, but full zones still leaves the possibility to make some changes to the packages and patches in case its necessary. Unfortunately we have no way to know which pkgs you deliberately want to be different between the global and non-global zone and which you want to be in sync. Thats why a list where the user could control that would be needed. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
On Thu, Nov 6, 2008 at 8:16 AM, Jerry Jelinek [EMAIL PROTECTED] wrote: Henrik Johansson wrote: The easiest way would probably be to identify packages that are not to be updated, in my experience packages do not differ that much between local zones in production environments, but that is only based on the system I have worked with. I always keep zones as similar as possible, but full zones still leaves the possibility to make some changes to the packages and patches in case its necessary. Unfortunately we have no way to know which pkgs you deliberately want to be different between the global and non-global zone and which you want to be in sync. Thats why a list where the user could control that would be needed. Isn't that the purpose of pkgadd -G? -G Add package(s) in the current zone only. When used in the global zone, the package is added to the global zone only and is not propagated to any existing or yet-to-be- created non-global zone. When used in a non-global zone, the package(s) are added to the non-global zone only. This option causes package installation to fail if, in the pkginfo file for a package, SUNW_PKG_ALLZONES is set to true. See pkginfo(4). A package added to the global zone with pkgadd -G should not be upgraded in the non-global zone. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
Mike Gerdts wrote: On Thu, Nov 6, 2008 at 8:16 AM, Jerry Jelinek [EMAIL PROTECTED] wrote: Henrik Johansson wrote: The easiest way would probably be to identify packages that are not to be updated, in my experience packages do not differ that much between local zones in production environments, but that is only based on the system I have worked with. I always keep zones as similar as possible, but full zones still leaves the possibility to make some changes to the packages and patches in case its necessary. Unfortunately we have no way to know which pkgs you deliberately want to be different between the global and non-global zone and which you want to be in sync. Thats why a list where the user could control that would be needed. Isn't that the purpose of pkgadd -G? -G Add package(s) in the current zone only. When used in the global zone, the package is added to the global zone only and is not propagated to any existing or yet-to-be- created non-global zone. When used in a non-global zone, the package(s) are added to the non-global zone only. This option causes package installation to fail if, in the pkginfo file for a package, SUNW_PKG_ALLZONES is set to true. See pkginfo(4). A package added to the global zone with pkgadd -G should not be upgraded in the non-global zone. The problem is when you look at a zone, how do you know what to sync with the global zone? For example, if you have a whole-root zone, that means you've explicitly decided you want the ability to manage pkgs in /usr, etc. independently of the global zone. With a true upgrade, those pkgs that are part of the release are upgraded anyway. What do we do with a zone migration? What pkg metadata do we have inside the zone to tell us which pkgs to sync and which not to? Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
anyone know when the brandz for s10 will be out? e.g. running s10 with opensolaris zone? Jerry Jelinek wrote: Mike Gerdts wrote: On Thu, Nov 6, 2008 at 8:16 AM, Jerry Jelinek [EMAIL PROTECTED] wrote: Henrik Johansson wrote: The easiest way would probably be to identify packages that are not to be updated, in my experience packages do not differ that much between local zones in production environments, but that is only based on the system I have worked with. I always keep zones as similar as possible, but full zones still leaves the possibility to make some changes to the packages and patches in case its necessary. Unfortunately we have no way to know which pkgs you deliberately want to be different between the global and non-global zone and which you want to be in sync. Thats why a list where the user could control that would be needed. Isn't that the purpose of pkgadd -G? -G Add package(s) in the current zone only. When used in the global zone, the package is added to the global zone only and is not propagated to any existing or yet-to-be- created non-global zone. When used in a non-global zone, the package(s) are added to the non-global zone only. This option causes package installation to fail if, in the pkginfo file for a package, SUNW_PKG_ALLZONES is set to true. See pkginfo(4). A package added to the global zone with pkgadd -G should not be upgraded in the non-global zone. The problem is when you look at a zone, how do you know what to sync with the global zone? For example, if you have a whole-root zone, that means you've explicitly decided you want the ability to manage pkgs in /usr, etc. independently of the global zone. With a true upgrade, those pkgs that are part of the release are upgraded anyway. What do we do with a zone migration? What pkg metadata do we have inside the zone to tell us which pkgs to sync and which not to? Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org begin:vcard fn:Dr. Hung-Sheng Tsao (LaoTsao) n:Tsao;Hung-Sheng org:GEH;Sun GEH East adr:;;400 Atrium Dr;Somerset;nj;08873;usa email;internet:[EMAIL PROTECTED] title:Sr. SE tel;work:1877319-0460 tel;fax:1877-319-0460 tel;pager:1973-495-0840 tel;home:1973495-0840 tel;cell:1973-495-0840 x-mozilla-html:TRUE url:http://blogs.sun.com/hstsao version:2.1 end:vcard ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
On 6 nov 2008, at 15.16, Jerry Jelinek [EMAIL PROTECTED] wrote: Henrik Johansson wrote: The easiest way would probably be to identify packages that are not to be updated, in my experience packages do not differ that much between local zones in production environments, but that is only based on the system I have worked with. I always keep zones as similar as possible, but full zones still leaves the possibility to make some changes to the packages and patches in case its necessary. Unfortunately we have no way to know which pkgs you deliberately want to be different between the global and non-global zone and which you want to be in sync. Thats why a list where the user could control that would be needed. Yes, what I ment was that the operator should identify these packages. So what we would get is something like an upgrade but with optional control of packages that do not need to be in sync between the zones. Henrik http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] slow transfer to branded zone
Hi, Customer has S-10 server with a branded zone (S8) He tells me that rcp - or ftp transfers into the zone are extremely slow. The same transfer direct to the S10 global zone is fine, from the global zone to the branded zone is fine. From the branded zone outbound to another server is fine, it is only when transferring files from another host into the branded zone. Are there known issues here? There is a kernel task open on this that states when the problem is happening cpu 0 of a 4 cpu system is at 100%. - kernel is 127127-11 Mark -- Mark ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
On Thu, Nov 06, 2008 at 10:20:43AM -0500, Dr. Hung-Sheng Tsao (LaoTsao) wrote: anyone know when the brandz for s10 will be out? e.g. running s10 with opensolaris zone? No target has been set for this. We cannot reasonably manage such a project until s10 begins taking less change. The current understanding is the need for such a feature will co-incide with the release of an enterprise version of opensolaris, or an early update (6 months?) to an enterprise opensolaris-based release. -Steve L. Jerry Jelinek wrote: Mike Gerdts wrote: On Thu, Nov 6, 2008 at 8:16 AM, Jerry Jelinek [EMAIL PROTECTED] wrote: Henrik Johansson wrote: The easiest way would probably be to identify packages that are not to be updated, in my experience packages do not differ that much between local zones in production environments, but that is only based on the system I have worked with. I always keep zones as similar as possible, but full zones still leaves the possibility to make some changes to the packages and patches in case its necessary. Unfortunately we have no way to know which pkgs you deliberately want to be different between the global and non-global zone and which you want to be in sync. Thats why a list where the user could control that would be needed. Isn't that the purpose of pkgadd -G? -G Add package(s) in the current zone only. When used in the global zone, the package is added to the global zone only and is not propagated to any existing or yet-to-be- created non-global zone. When used in a non-global zone, the package(s) are added to the non-global zone only. This option causes package installation to fail if, in the pkginfo file for a package, SUNW_PKG_ALLZONES is set to true. See pkginfo(4). A package added to the global zone with pkgadd -G should not be upgraded in the non-global zone. The problem is when you look at a zone, how do you know what to sync with the global zone? For example, if you have a whole-root zone, that means you've explicitly decided you want the ability to manage pkgs in /usr, etc. independently of the global zone. With a true upgrade, those pkgs that are part of the release are upgraded anyway. What do we do with a zone migration? What pkg metadata do we have inside the zone to tell us which pkgs to sync and which not to? Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
