Re: [zones-discuss] Update on attach and upgrades
Le 6 nov. 08 à 20:30, Steve Lawrence a écrit : 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. Enterprise version of OpenSolaris ? Could anybody explain what does it mean ? smime.p7s Description: S/MIME cryptographic signature ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
* Nicolas Dorfsman [EMAIL PROTECTED] [2008-12-08 16:46]: Le 6 nov. 08 à 20:30, Steve Lawrence a écrit : 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. Enterprise version of OpenSolaris ? Could anybody explain what does it mean ? If Sun were to produce an enterprise version of OpenSolaris, it would mean a release that had a 10+ year support lifetime. (And presumably some form of periodic updates for newer hardware, etc.) - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
Nicolas Dorfsman writes: Enterprise version of OpenSolaris ? Could anybody explain what does it mean ? It doesn't exist yet, so it's unlikely that a complete answer is available ... at least until something's announced by Sun. My guess would be at least an OpenSolaris distribution including the currently-missing enterprise features (likely something akin to jumpstart, flash archives, and SPARC) and an offer of contract-based support. Perhaps also more repositories. That's just my guess, though. Other than the eventual introduction of new features (the ones now missing in Indiana), I don't think it's something that would need to be discussed here, any more than any other entity offering to provide commercial support on existing open source code. (If what you might be expecting here is someone to take the code private somehow, then I very much doubt that.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
James, Thanks for your answer. Le 8 déc. 08 à 18:07, James Carlson a écrit : (If what you might be expecting here is someone to take the code private somehow, then I very much doubt that.) I'm just really surprised to see OpenSolaris and Enterprise in the same idea. I thought...no, I'm sure Enterprise OpenSolaris is just called Solaris. Nicolas ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
Nicolas Dorfsman writes: I'm just really surprised to see OpenSolaris and Enterprise in the same idea. I thought...no, I'm sure Enterprise OpenSolaris is just called Solaris. I agree that what you're suggesting would seem simpler and more obvious (it does to me), but it's up to marketing to determine what those words actually mean, and I'm not in marketing. Fortunately, I don't think the issue has any substantial impact on opensolaris.org. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
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
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
[zones-discuss] Update on attach and upgrades
Hi all, Some thoughts regarding update on attach, and why I don't think it will be as useful as it could be. Perhaps Jerry or someone could enlighten me or give me some feedback. This mainly applies to whole root zones, since they do not have any inherited package directories. The update to the local zone only updates packages that have the SUNW_PKG_ALL_ZONES set to true or are in a package inherited directory. This means it is not similar to an upgrade performed by the installation system or live upgrade. One useful scenario for update on attach was to have one node upgraded without zones and then migrate the zone one after the other to the upgraded host and have them upgraded on attach (quite useful when you have 20+ zones in one machine). This will leave the zone in a supported state, however the zone will have a mix of packages from the old and new machine, depending on if they are required to be consistent between all zones. Since many installations using local zones keeps the local zones in sync with the global zone, this is not an optimal situation. If we use update on attach today, that zone will be different from the other zones created after the upgrade or zones that have been upgraded at the same time as the global zone. In the case of one machine being upgraded to a later update of Solaris, that will be quite a few packages with different versions. This is not an acceptable solution for many environments. Shouldn't it be possible to implement the functionality to update all packages that have newer versions in the global zone? That could perhaps be an additional flag to attach -u, maybe -a? I know packages could be of different version on purpose, but then this option should not be used, or implement an option to supply a list of packages to upgrade or leave alone. Regards Henrik http://sparcv9.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
Henrik Johansson wrote: Hi all, Some thoughts regarding update on attach, and why I don't think it will be as useful as it could be. Perhaps Jerry or someone could enlighten me or give me some feedback. This mainly applies to whole root zones, since they do not have any inherited package directories. The update to the local zone only updates packages that have the SUNW_PKG_ALL_ZONES set to true or are in a package inherited directory. This means it is not similar to an upgrade performed by the installation system or live upgrade. One useful scenario for update on attach was to have one node upgraded without zones and then migrate the zone one after the other to the upgraded host and have them upgraded on attach (quite useful when you have 20+ zones in one machine). This will leave the zone in a supported state, however the zone will have a mix of packages from the old and new machine, depending on if they are required to be consistent between all zones. Since many installations using local zones keeps the local zones in sync with the global zone, this is not an optimal situation. If we use update on attach today, that zone will be different from the other zones created after the upgrade or zones that have been upgraded at the same time as the global zone. In the case of one machine being upgraded to a later update of Solaris, that will be quite a few packages with different versions. This is not an acceptable solution for many environments. This is a correct observation and is why I always try to distinguish between a true upgrade and zone 'update on attach'. Shouldn't it be possible to implement the functionality to update all packages that have newer versions in the global zone? That could perhaps be an additional flag to attach -u, maybe -a? I know packages could be of different version on purpose, but then this option should not be used, or implement an option to supply a list of packages to upgrade or leave alone. I think that just updating the non-global zone for every pkg that is installed in the global is probably not quite right since you want to be able to have different software in different zones, including the global zone. It would be possible to leverage the solution we have today so that the list of pkgs that must be in-sync was augmented by some sort of user input. For example, as you suggested, one idea might be for you to set up a file containing a list of additional pkgs that should be in-sync. You could pass that to the attach command and those additional pkgs would be synced up. That would be fairly simple to do but it would require the user to figure out what pkgs to put in the list. You'd have to look at some released version of Solaris and decide which pkgs to add. This might be a bit of a maintenance issue since the set of pkgs changes over time and over each update release. If this seems like something people are interested in, I'd like to hear more comments and we could refine a proposal. I'll then file an RFE and work up an ARC proposal. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Update on attach and upgrades
On Nov 6, 2008, at 12:47 AM, Jerry Jelinek wrote: I think that just updating the non-global zone for every pkg that is installed in the global is probably not quite right since you want to be able to have different software in different zones, including the global zone. Upgrade is already used today for non-global zones, this would just be something similar but individually per zone, an it would be an option to the update, default would still be the current update. If you upgrade today, you all your packages will be upgraded in the locale zones. It would be possible to leverage the solution we have today so that the list of pkgs that must be in-sync was augmented by some sort of user input. For example, as you suggested, one idea might be for you to set up a file containing a list of additional pkgs that should be in-sync. You could pass that to the attach command and those additional pkgs would be synced up. That would be fairly simple to do but it would require the user to figure out what pkgs to put in the list. You'd have to look at some released version of Solaris and decide which pkgs to add. This might be a bit of a maintenance issue since the set of pkgs changes over time and over each update release. 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. If this seems like something people are interested in, I'd like to hear more comments and we could refine a proposal. I'll then file an RFE and work up an ARC proposal. I know my employer would greatly appreciate something like this, it would make life easier with hundreds of zones, and again, to be able to mimic the upgrade behavior would be useful. When i first heard that update on attach i saw the possibility to more easily manage upgrades in our environment, but the current implementation does not help us. ___ zones-discuss mailing list zones-discuss@opensolaris.org
