[openstack-dev] [nova] Future of turbo-hipster CI

Joshua Hesketh joshua.hesketh at gmail.com
Thu Oct 6 01:56:50 UTC 2016


On Tue, Oct 4, 2016 at 11:49 PM, Matt Riedemann <mriedem at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161006/7e6a7841/attachment.html>


More information about the OpenStack-dev mailing list