On Tue, Oct 4, 2016 at 11:49 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote:
> On 10/3/2016 11:29 PM, Joshua Hesketh wrote: > >> Howdy, >> >> Quick bit of background. Turbo-hipster is a 3rd party CI system that >> runs nova's database migrations against real datasets to try and catch >> real-world problems. >> >> When it was initially written the state of migrations in nova would >> cause a lot of pain for deployers (such as very long downtimes while >> upgrades were performed or just not working at all). Since then nova has >> made conscious efforts to minimise this time and are generally aware >> when implementing a necessary migration may cause large downtimes and >> attempt to work around it where possible. >> >> turbo-hipster used to run against every change in nova. This was to >> catch changes that may have affected migration performance as a side >> effect. However for the last few months turbo-hipster has only been >> running against changes modifying files in nova/db/*. Any changes >> outside of there that causes pain can likely be reverted. >> >> As a note, turbo-hipster is currently not running due >> to https://review.openstack.org/#/c/374307/ until I have time to update >> the datasets used. >> >> The question now is whether or not to continue running. Is there still >> value in running turbo-hipster? It uses significant resources and it >> feels that developers have learned the lessons it was designed to teach. >> >> Not running it increases the risk a migration will fail or take a very >> long time for a real user, but turbo-hipster is far from perfect anyway >> and only tests a couple of datasets so that risk is still there. >> >> Are nova developers still getting value out of turbo-hipster or has it >> achieved its goal and is it time for it to retire? >> >> Thanks, >> Josh >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > I honestly forgot it existed. We have had some proposed database > migrations come up which were a bit controversial, e.g.: > > https://review.openstack.org/#/c/248780/ > > So we if know or expect something to be problematic/controversial it's something that can be tested manually (as it sounds you have been doing). It could be possible to find other operators willing to assist too. > So it would be nice to have something big to test these out while > considering them. We used to have Johannes for manual test runs on > migration changes but he's no longer around. > > So I guess I'm fine with not having t-h anymore since I didn't even notice > the absence for the last couple of releases, but I worry a bit about not > having a large test dataset for manual runs. > > It hasn't been absent for that long. It has only been running on migrations (ie not every change) for the last few months. > Having said that, I think Dan Smith came across a fairly large production > DB dataset recently which he was using for testing some archive changes, > maybe Dan will become our new Johannes, but grumpier of course. :) > > -- > > Thanks, > > Matt Riedemann > > > __________________________________________________________________________ > 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