Re: [openstack-dev] [upgrade] request for pre-upgrade check for db purge
On 9/11/2018 9:01 AM, Dan Smith wrote: I dunno, adding something to nova.conf that is only used for nova-status like that seems kinda weird to me. It's just a warning/informational sort of thing so it just doesn't seem worth the complication to me. It doesn't seem complicated to me, I'm not sure why the config is weird, but maybe just because it's config-driven CLI behavior? Moving it to an age thing set at one year seems okay, and better than making the absolute limit more configurable. Any reason why this wouldn't just be a command line flag to status if people want it to behave in a specific way from a specific tool? I always think of the pre-upgrade checks as release-specific and we could drop the old ones at some point, so that's why I wasn't thinking about adding check-specific options to the command - but since we also say it's OK to run "nova-status upgrade check" to verify a green install, it's probably good to leave the old checks in place, i.e. you're likely always going to want those cells v2 and placement checks we added in ocata even long after ocata EOL. -- Thanks, Matt __ 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] [upgrade] request for pre-upgrade check for db purge
> How do people feel about this? It seems pretty straight-forward to > me. If people are generally in favor of this, then the question is > what would be sane defaults - or should we not assume a default and > force operators to opt into this? I dunno, adding something to nova.conf that is only used for nova-status like that seems kinda weird to me. It's just a warning/informational sort of thing so it just doesn't seem worth the complication to me. Moving it to an age thing set at one year seems okay, and better than making the absolute limit more configurable. Any reason why this wouldn't just be a command line flag to status if people want it to behave in a specific way from a specific tool? --Dan __ 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] [upgrade] request for pre-upgrade check for db purge
I created a nova bug [1] to track a request that came up in the upgrades SIG room at the PTG today [2] and would like to see if there is any feedback from other operators/developers that weren't part of the discussion. The basic problem is that failing to archive/purge deleted records* from the database can make upgrades much slower during schema migrations. Anecdotes from the room mentioned that it can be literally impossible to complete upgrades for keystone and heat in certain scenarios if you don't purge the database first. The request was that a configurable limit gets added to each service which is checked as part of the service's pre-upgrade check routine [3] and warn if the number of records to purge is over that limit. For example, the nova-status upgrade check could warn if there are over 10 deleted records total across all cells databases. Maybe cinder would have something similar for deleted volumes. Keystone could have something for revoked tokens. Another idea in the room was flagging on records over a certain age limit. For example, if there are deleted instances in nova that were deleted >1 year ago. How do people feel about this? It seems pretty straight-forward to me. If people are generally in favor of this, then the question is what would be sane defaults - or should we not assume a default and force operators to opt into this? * nova delete doesn't actually delete the record from the instances table, it flips a value to hide it - you have to archive/purge those records to get them out of the main table. [1] https://bugs.launchpad.net/nova/+bug/1791824 [2] https://etherpad.openstack.org/p/upgrade-sig-ptg-stein [3] https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html -- Thanks, Matt __ 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
