Re: [openstack-dev] [Heat][Oslo] Versioned objects compatibility mode
On Mon, Jun 22, 2015 at 5:40 AM, Jastrzebski, Michal michal.jastrzeb...@intel.com wrote: Hello, I wanted to start discussion about versioned objects backporting for conductor-less projects. In Vancouver we discussed compatibility mode, which works like that: Dan's blog post suggests that Nova already requires two restarts: http://www.danplanet.com/blog/2015/06/26/upgrading-nova-to-kilo-with-minimal-downtime/ I added a bp/spec for this in Heat: https://review.openstack.org/196670 There is also an approved spec in Cinder: https://review.openstack.org/192037 which, to avoid restarts, stores the configuration in the DB. This places a requirement for all services to have a direct access to the database, so it can't be used in all projects. Thang Pham also wrote a Cinder POC implementation: https://review.openstack.org/184404. / Greg __ 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] [Heat][Oslo] Versioned objects compatibility mode
Davanum, Can we also use SIGHUP signal tool instead of for these restarts? Regards, Sergey. On 22 June 2015 at 13:12, Davanum Srinivas dava...@gmail.com wrote: Michał, we are adding that reread config to oslo.service, there's a test version on pypi 0.1.0 (API not yet stable) that you can try and see if it works for you. thanks, dims On Mon, Jun 22, 2015 at 5:40 AM, Jastrzebski, Michal michal.jastrzeb...@intel.com wrote: Hello, I wanted to start discussion about versioned objects backporting for conductor-less projects. In Vancouver we discussed compatibility mode, which works like that: 1. We define one version for every object we use, this means adding base object, for example: Class HeatObject: VERSION=1.5 All objects inherit from this one, each time we change it, we bump up this variable. 2. We introduce new config option in heat.conf Combatibility_mode = 1.4 3. Implement mechanism which will automatically backport each outgoing message to 1.4 as long as we have this var. Upgrade flow looks like that: 1. We have all nodes using 1.4 version 2. We incrementally run new version with 1.4 compatibility mode 3. When all nodes are already up-to-date, we incrementally turn off compatibility mode This solution has one rather big disadvantage: 2 restarts. This can be mitigated by adding another call to reread config without restart. Oslo.config has this capability, but we need to add call to run it. Thoughts? Regards, Michał Jastrzębski __ 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [Heat][Oslo] Versioned objects compatibility mode
At the moment, We have reload config files in place: https://github.com/openstack/oslo.service/blob/master/oslo_service/service.py#L487 there are patches against Nova and Neutron where we are looking at how this works and what else we can do. -- dims On Mon, Jun 22, 2015 at 7:21 AM, Sergey Kraynev skray...@mirantis.com wrote: Davanum, Can we also use SIGHUP signal tool instead of for these restarts? Regards, Sergey. On 22 June 2015 at 13:12, Davanum Srinivas dava...@gmail.com wrote: Michał, we are adding that reread config to oslo.service, there's a test version on pypi 0.1.0 (API not yet stable) that you can try and see if it works for you. thanks, dims On Mon, Jun 22, 2015 at 5:40 AM, Jastrzebski, Michal michal.jastrzeb...@intel.com wrote: Hello, I wanted to start discussion about versioned objects backporting for conductor-less projects. In Vancouver we discussed compatibility mode, which works like that: 1. We define one version for every object we use, this means adding base object, for example: Class HeatObject: VERSION=1.5 All objects inherit from this one, each time we change it, we bump up this variable. 2. We introduce new config option in heat.conf Combatibility_mode = 1.4 3. Implement mechanism which will automatically backport each outgoing message to 1.4 as long as we have this var. Upgrade flow looks like that: 1. We have all nodes using 1.4 version 2. We incrementally run new version with 1.4 compatibility mode 3. When all nodes are already up-to-date, we incrementally turn off compatibility mode This solution has one rather big disadvantage: 2 restarts. This can be mitigated by adding another call to reread config without restart. Oslo.config has this capability, but we need to add call to run it. Thoughts? Regards, Michał Jastrzębski __ 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [Heat][Oslo] Versioned objects compatibility mode
Michał, we are adding that reread config to oslo.service, there's a test version on pypi 0.1.0 (API not yet stable) that you can try and see if it works for you. thanks, dims On Mon, Jun 22, 2015 at 5:40 AM, Jastrzebski, Michal michal.jastrzeb...@intel.com wrote: Hello, I wanted to start discussion about versioned objects backporting for conductor-less projects. In Vancouver we discussed compatibility mode, which works like that: 1. We define one version for every object we use, this means adding base object, for example: Class HeatObject: VERSION=1.5 All objects inherit from this one, each time we change it, we bump up this variable. 2. We introduce new config option in heat.conf Combatibility_mode = 1.4 3. Implement mechanism which will automatically backport each outgoing message to 1.4 as long as we have this var. Upgrade flow looks like that: 1. We have all nodes using 1.4 version 2. We incrementally run new version with 1.4 compatibility mode 3. When all nodes are already up-to-date, we incrementally turn off compatibility mode This solution has one rather big disadvantage: 2 restarts. This can be mitigated by adding another call to reread config without restart. Oslo.config has this capability, but we need to add call to run it. Thoughts? Regards, Michał Jastrzębski __ 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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-dev] [Heat][Oslo] Versioned objects compatibility mode
Hello, I wanted to start discussion about versioned objects backporting for conductor-less projects. In Vancouver we discussed compatibility mode, which works like that: 1. We define one version for every object we use, this means adding base object, for example: Class HeatObject: VERSION=1.5 All objects inherit from this one, each time we change it, we bump up this variable. 2. We introduce new config option in heat.conf Combatibility_mode = 1.4 3. Implement mechanism which will automatically backport each outgoing message to 1.4 as long as we have this var. Upgrade flow looks like that: 1. We have all nodes using 1.4 version 2. We incrementally run new version with 1.4 compatibility mode 3. When all nodes are already up-to-date, we incrementally turn off compatibility mode This solution has one rather big disadvantage: 2 restarts. This can be mitigated by adding another call to reread config without restart. Oslo.config has this capability, but we need to add call to run it. Thoughts? Regards, Michał Jastrzębski __ 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
