Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
On 05/28/2015 08:24 PM, Zane Bitter wrote: On 28/05/15 03:35, Jan Provaznik wrote: On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned at the summit that this approach fails to take into account the complex ballet of service restarts required to update OpenStack services. (/me shakes fist at OpenStack services.) And furthermore, that the Puppet manifests already encode the necessary relationships to do this properly. (Thanks Puppeteers!) Indeed we'd be doing the Wrong Thing by Puppet if we changed this stuff from under it. The problem of course is that neither Puppet nor yum/apt has a view of the entire system. Yum doesn't know about the relationships between services and Puppet doesn't know about all of the _other_ packages that they depend on. One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. Why not swap the order? First run puppet using ensure=latest which updates/restarts everything Openstack depends on, then run yum/apt update to update any remaining bits. You wouldn't need exclude list then. Will ensure=latest update all packages that the given one is dependent on, even if it doesn't require new versions? I assumed that it wouldn't, so by doing Puppet first we would just ensure that we are even less likely to pick up library changes by restarting services after the libraries are updated. We could take advantage of this only when both a service and a dependency library are part of the upgrade. Other services depending on the lib would have to be restarted out-of-puppet in post yum-update phase anyway. I wonder if it is worth to try generate list of exclude packages (to be able to run yum first) given quite limited benefit it provides, but if it's simple enough then +1 :). A problem with that approach is that it still fails to restart services which have had libraries updated but have not themselves been updated. That's no worse than the pure yum approach though. We might need an additional way to just manually trigger a restart of services. Maybe this could be handled at the packaging stage by reving the package version when there is a known fix in a low-level library, thus triggering a service restart in the puppet phase. My concern is that then e.g. libc update would mean repackaging (bumping version) of zillion of other packages, also zillion of packages would be downloaded/upgraded on each system because of a new package version. Yes, no distro ever created works like this - for good reason - and it is way out of scope for us to try to change that :) I think that providing user a manual (script) way to restart services after update would be sufficient solution (though not so sophisticated). Maybe there's a way we can poke Puppet to do it. cheers, Zane. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
On 05/28/2015 05:32 PM, James Slagle wrote: Then I'm +1 for running Puppet with 'ensure = latest' first and then 'yum update -y'. Seems ideal solution from my point of view. How would this solve the library update problem though?. If a new version of a library is released to address a security issue or what not, first you'd run puppet, which doesn't see anything new. Then the yum update -y would pick up the library update, but no services would get restarted. I don't think we can convince all distros to rev every package version that might depend on such a library update. Take something like heartbleed for example, when the updated openssl was released, there wasn't a corresponding rebuild of every package out there that requires openssl to set a minimum requires on the new openssl version (that I know of). Hmpf, it won't solve the library update problem. I didn't think about such case. I don't know puppet internals at all, but what about some type of Puppet provider that overrides latest to make Puppet think that it's actually updated a package even if no such update exists? That could trigger Puppet to then restart the services b/c it thinks it's updated something. Service restart is not triggered by package providers, but by dependencies stated in modules. So using dummy package provider does not seem ideal for me. SImilar to what TripleO is doing with the norpm provider where the install is a noop: https://github.com/stackforge/puppet-tripleo/blob/master/lib/puppet/provider/package/norpm.rb Could we then swap in this provider when we're triggering the update via Heat? So we do a yum update -y, and then rerun puppet, and it thinks it's updated everything, so it restarts as needed. Each module would need to have parameter implemented to enable such behaviour. But anyway I don't like this solution because I see it as dirty hack. AFAIR all service resources in OpenStack modules are defined as 'refreshonly'. This means that we could implement in Tripleo manifests a logic just to schedule refresh on them when it is required. Thoughts? Regards, Martin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
On 28/05/15 03:35, Jan Provaznik wrote: On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned at the summit that this approach fails to take into account the complex ballet of service restarts required to update OpenStack services. (/me shakes fist at OpenStack services.) And furthermore, that the Puppet manifests already encode the necessary relationships to do this properly. (Thanks Puppeteers!) Indeed we'd be doing the Wrong Thing by Puppet if we changed this stuff from under it. The problem of course is that neither Puppet nor yum/apt has a view of the entire system. Yum doesn't know about the relationships between services and Puppet doesn't know about all of the _other_ packages that they depend on. One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. Why not swap the order? First run puppet using ensure=latest which updates/restarts everything Openstack depends on, then run yum/apt update to update any remaining bits. You wouldn't need exclude list then. Will ensure=latest update all packages that the given one is dependent on, even if it doesn't require new versions? I assumed that it wouldn't, so by doing Puppet first we would just ensure that we are even less likely to pick up library changes by restarting services after the libraries are updated. A problem with that approach is that it still fails to restart services which have had libraries updated but have not themselves been updated. That's no worse than the pure yum approach though. We might need an additional way to just manually trigger a restart of services. Maybe this could be handled at the packaging stage by reving the package version when there is a known fix in a low-level library, thus triggering a service restart in the puppet phase. My concern is that then e.g. libc update would mean repackaging (bumping version) of zillion of other packages, also zillion of packages would be downloaded/upgraded on each system because of a new package version. Yes, no distro ever created works like this - for good reason - and it is way out of scope for us to try to change that :) I think that providing user a manual (script) way to restart services after update would be sufficient solution (though not so sophisticated). Maybe there's a way we can poke Puppet to do it. cheers, Zane. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
while more effort, you could write a script that took a package name, and gave back the whole set of rpm/versions that it depended on, then write that to a file. If the list of rpm/versions from the previous run changes, then have puppet kick the process? Thanks, Kevin From: Zane Bitter [zbit...@redhat.com] Sent: Thursday, May 28, 2015 11:24 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy On 28/05/15 03:35, Jan Provaznik wrote: On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned at the summit that this approach fails to take into account the complex ballet of service restarts required to update OpenStack services. (/me shakes fist at OpenStack services.) And furthermore, that the Puppet manifests already encode the necessary relationships to do this properly. (Thanks Puppeteers!) Indeed we'd be doing the Wrong Thing by Puppet if we changed this stuff from under it. The problem of course is that neither Puppet nor yum/apt has a view of the entire system. Yum doesn't know about the relationships between services and Puppet doesn't know about all of the _other_ packages that they depend on. One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. Why not swap the order? First run puppet using ensure=latest which updates/restarts everything Openstack depends on, then run yum/apt update to update any remaining bits. You wouldn't need exclude list then. Will ensure=latest update all packages that the given one is dependent on, even if it doesn't require new versions? I assumed that it wouldn't, so by doing Puppet first we would just ensure that we are even less likely to pick up library changes by restarting services after the libraries are updated. A problem with that approach is that it still fails to restart services which have had libraries updated but have not themselves been updated. That's no worse than the pure yum approach though. We might need an additional way to just manually trigger a restart of services. Maybe this could be handled at the packaging stage by reving the package version when there is a known fix in a low-level library, thus triggering a service restart in the puppet phase. My concern is that then e.g. libc update would mean repackaging (bumping version) of zillion of other packages, also zillion of packages would be downloaded/upgraded on each system because of a new package version. Yes, no distro ever created works like this - for good reason - and it is way out of scope for us to try to change that :) I think that providing user a manual (script) way to restart services after update would be sufficient solution (though not so sophisticated). Maybe there's a way we can poke Puppet to do it. cheers, Zane. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
Excerpts from Zane Bitter's message of 2015-05-28 11:24:33 -0700: On 28/05/15 03:35, Jan Provaznik wrote: On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned at the summit that this approach fails to take into account the complex ballet of service restarts required to update OpenStack services. (/me shakes fist at OpenStack services.) And furthermore, that the Puppet manifests already encode the necessary relationships to do this properly. (Thanks Puppeteers!) Indeed we'd be doing the Wrong Thing by Puppet if we changed this stuff from under it. The problem of course is that neither Puppet nor yum/apt has a view of the entire system. Yum doesn't know about the relationships between services and Puppet doesn't know about all of the _other_ packages that they depend on. One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. Why not swap the order? First run puppet using ensure=latest which updates/restarts everything Openstack depends on, then run yum/apt update to update any remaining bits. You wouldn't need exclude list then. Will ensure=latest update all packages that the given one is dependent on, even if it doesn't require new versions? I assumed that it wouldn't, so by doing Puppet first we would just ensure that we are even less likely to pick up library changes by restarting services after the libraries are updated. No. A problem with that approach is that it still fails to restart services which have had libraries updated but have not themselves been updated. That's no worse than the pure yum approach though. We might need an additional way to just manually trigger a restart of services. Maybe this could be handled at the packaging stage by reving the package version when there is a known fix in a low-level library, thus triggering a service restart in the puppet phase. My concern is that then e.g. libc update would mean repackaging (bumping version) of zillion of other packages, also zillion of packages would be downloaded/upgraded on each system because of a new package version. Yes, no distro ever created works like this - for good reason - and it is way out of scope for us to try to change that :) There are a number of clever things that can detect C shared libraries that need to be reloaded. One such thing is checkrestart from debian-goodies. It combs through lsof to do that. Not possible for python libs and dlopened plugins though. This is one of the arguments for containers -- at least you know if you changed something, it's time for a new container. I think that providing user a manual (script) way to restart services after update would be sufficient solution (though not so sophisticated). Maybe there's a way we can poke Puppet to do it. This is one big flaw with the declare the world and converge on it model. Often there is a single diminutive workflow that could be used to achieve the end-goal and one would be better off expending their energy on tests to ensure that the end state is reached than trying to figure out how to express all the things as DSL that is actually achievable. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
On 05/28/2015 09:35 AM, Jan Provaznik wrote: On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. Why not swap the order? First run puppet using ensure=latest which updates/restarts everything Openstack depends on, then run yum/apt update to update any remaining bits. You wouldn't need exclude list then. Isn't running Puppet with 'ensure = latest' enough? If packaging is correct all dependencies which will require update will be updated together with packages updated by Puppet. Am I missing something or the goal here is to update all packages? A problem with that approach is that it still fails to restart services which have had libraries updated but have not themselves been updated. That's no worse than the pure yum approach though. We might need an additional way to just manually trigger a restart of services. Maybe this could be handled at the packaging stage by reving the package version when there is a known fix in a low-level library, thus triggering a service restart in the puppet phase. My concern is that then e.g. libc update would mean repackaging (bumping version) of zillion of other packages, also zillion of packages would be downloaded/upgraded on each system because of a new package version. I think that providing user a manual (script) way to restart services after update would be sufficient solution (though not so sophisticated). Jan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Regards, Martin -- Martin Mágr Openstack Red Hat Czech IRC nick: mmagr / paramite Freenode channels: #openstack-dev, #packstack-dev, #puppet-openstack, #rdo, #rdo-puppet __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
On 05/28/2015 10:25 AM, Martin Mágr wrote: On 05/28/2015 09:35 AM, Jan Provaznik wrote: On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. Why not swap the order? First run puppet using ensure=latest which updates/restarts everything Openstack depends on, then run yum/apt update to update any remaining bits. You wouldn't need exclude list then. Isn't running Puppet with 'ensure = latest' enough? If packaging is correct all dependencies which will require update will be updated together with packages updated by Puppet. Am I missing something or the goal here is to update all packages? Yes - the goal so to update all packages (so puppet only is not sufficient because it will not take care of packages which are not listed in puppet modules). __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned at the summit that this approach fails to take into account the complex ballet of service restarts required to update OpenStack services. (/me shakes fist at OpenStack services.) And furthermore, that the Puppet manifests already encode the necessary relationships to do this properly. (Thanks Puppeteers!) Indeed we'd be doing the Wrong Thing by Puppet if we changed this stuff from under it. The problem of course is that neither Puppet nor yum/apt has a view of the entire system. Yum doesn't know about the relationships between services and Puppet doesn't know about all of the _other_ packages that they depend on. One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. Why not swap the order? First run puppet using ensure=latest which updates/restarts everything Openstack depends on, then run yum/apt update to update any remaining bits. You wouldn't need exclude list then. A problem with that approach is that it still fails to restart services which have had libraries updated but have not themselves been updated. That's no worse than the pure yum approach though. We might need an additional way to just manually trigger a restart of services. Maybe this could be handled at the packaging stage by reving the package version when there is a known fix in a low-level library, thus triggering a service restart in the puppet phase. My concern is that then e.g. libc update would mean repackaging (bumping version) of zillion of other packages, also zillion of packages would be downloaded/upgraded on each system because of a new package version. I think that providing user a manual (script) way to restart services after update would be sufficient solution (though not so sophisticated). Jan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
On 05/28/2015 10:47 AM, Jan Provaznik wrote: On 05/28/2015 10:25 AM, Martin Mágr wrote: On 05/28/2015 09:35 AM, Jan Provaznik wrote: On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. Why not swap the order? First run puppet using ensure=latest which updates/restarts everything Openstack depends on, then run yum/apt update to update any remaining bits. You wouldn't need exclude list then. Isn't running Puppet with 'ensure = latest' enough? If packaging is correct all dependencies which will require update will be updated together with packages updated by Puppet. Am I missing something or the goal here is to update all packages? Yes - the goal so to update all packages (so puppet only is not sufficient because it will not take care of packages which are not listed in puppet modules). __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Then I'm +1 for running Puppet with 'ensure = latest' first and then 'yum update -y'. Seems ideal solution from my point of view. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
On Thu, May 28, 2015 at 5:02 AM, Martin Mágr mm...@redhat.com wrote: On 05/28/2015 10:47 AM, Jan Provaznik wrote: On 05/28/2015 10:25 AM, Martin Mágr wrote: On 05/28/2015 09:35 AM, Jan Provaznik wrote: On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. Why not swap the order? First run puppet using ensure=latest which updates/restarts everything Openstack depends on, then run yum/apt update to update any remaining bits. You wouldn't need exclude list then. Isn't running Puppet with 'ensure = latest' enough? If packaging is correct all dependencies which will require update will be updated together with packages updated by Puppet. Am I missing something or the goal here is to update all packages? Yes - the goal so to update all packages (so puppet only is not sufficient because it will not take care of packages which are not listed in puppet modules). __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Then I'm +1 for running Puppet with 'ensure = latest' first and then 'yum update -y'. Seems ideal solution from my point of view. How would this solve the library update problem though?. If a new version of a library is released to address a security issue or what not, first you'd run puppet, which doesn't see anything new. Then the yum update -y would pick up the library update, but no services would get restarted. I don't think we can convince all distros to rev every package version that might depend on such a library update. Take something like heartbleed for example, when the updated openssl was released, there wasn't a corresponding rebuild of every package out there that requires openssl to set a minimum requires on the new openssl version (that I know of). I don't know puppet internals at all, but what about some type of Puppet provider that overrides latest to make Puppet think that it's actually updated a package even if no such update exists? That could trigger Puppet to then restart the services b/c it thinks it's updated something. SImilar to what TripleO is doing with the norpm provider where the install is a noop: https://github.com/stackforge/puppet-tripleo/blob/master/lib/puppet/provider/package/norpm.rb Could we then swap in this provider when we're triggering the update via Heat? So we do a yum update -y, and then rerun puppet, and it thinks it's updated everything, so it restarts as needed. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- James Slagle -- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned at the summit that this approach fails to take into account the complex ballet of service restarts required to update OpenStack services. (/me shakes fist at OpenStack services.) And furthermore, that the Puppet manifests already encode the necessary relationships to do this properly. (Thanks Puppeteers!) Indeed we'd be doing the Wrong Thing by Puppet if we changed this stuff from under it. The problem of course is that neither Puppet nor yum/apt has a view of the entire system. Yum doesn't know about the relationships between services and Puppet doesn't know about all of the _other_ packages that they depend on. One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. A problem with that approach is that it still fails to restart services which have had libraries updated but have not themselves been updated. That's no worse than the pure yum approach though. We might need an additional way to just manually trigger a restart of services. What do folks think of this plan? Anybody got better ideas? thanks, Zane. [1] https://review.openstack.org/#/c/179974 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Adding the [Puppet] tag to raise visibility. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy
On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned at the summit that this approach fails to take into account the complex ballet of service restarts required to update OpenStack services. (/me shakes fist at OpenStack services.) And furthermore, that the Puppet manifests already encode the necessary relationships to do this properly. (Thanks Puppeteers!) Indeed we'd be doing the Wrong Thing by Puppet if we changed this stuff from under it. The problem of course is that neither Puppet nor yum/apt has a view of the entire system. Yum doesn't know about the relationships between services and Puppet doesn't know about all of the _other_ packages that they depend on. One solution proposed was to do a yum update first but specifically exclude any packages that Puppet knows about (the --excludes flag appears sufficient for this); then follow that up with another Puppet run using ensure - latest. My only concern with this approach is how do we collect and maintain the excludes list. Other than that it sounds reasonable. A problem with that approach is that it still fails to restart services which have had libraries updated but have not themselves been updated. That's no worse than the pure yum approach though. We might need an additional way to just manually trigger a restart of services. Maybe this could be handled at the packaging stage by reving the package version when there is a known fix in a low-level library, thus triggering a service restart in the puppet phase. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
