Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-02
10:33:33 gmann johnthetubaguy: yea, list is too huge we did not notice those
10:35:10 gmann johnthetubaguy: i have added that in etherpad also (so mriedem can mark that rc potential), ll check from home.
10:36:12 johnthetubaguy gmann: thanks
10:36:39 johnthetubaguy gmann: it was such a massive list, there were always going to be niggles, would love to squash then before release, if possible
10:36:58 gmann +1
10:48:30 sfinucan bauzas: Can I +W this? https://review.openstack.org/#/c/426864/6
10:48:47 sfinucan I assume it won't do anything silly like tag the release or whatnot
10:51:34 johnthetubaguy sfinucan: that sounds fine to me, we have added lots of preludes by accident in the past
10:51:56 sfinucan johnthetubaguy: Righto - +W it is
10:52:27 johnthetubaguy oh year, I should review that one again
10:52:30 bauzas sfinucan: cool with me
10:52:36 bauzas johnthetubaguy: I'm already on it
10:53:29 sfinucan bauzas: Could you also take a look at https://review.openstack.org/#/c/427499/, seeing as you're far more familiar with that feature
10:55:29 bauzas sfinucan: mmm, I had a concern on the bottom patch
10:55:46 bauzas at least a typo
10:56:22 sfinucan bauzas: Hmm, if you want to fix it now we can just re-approve, right?
10:56:46 sfinucan Also, do you know what "barber pole sorting" is? :D
10:57:06 sfinucan I'm guessing it's Python's 'zip', but that's a guess
10:58:31 bauzas sfinucan: https://en.wikipedia.org/wiki/Barber's_pole#Computer_science
10:58:56 sfinucan bauzas: I don't think that's what he's talking about though
10:59:06 sfinucan That describes a loading bar - he's on about sorting something
10:59:38 bauzas sfinucan: that would mean it takes time IIUC
10:59:50 bauzas sfinucan: oh, you removed +W
11:00:00 bauzas sfinucan: but that doesn't mean the gate jobs will stop
11:00:07 bauzas sfinucan: we have to trigger a new PS
11:00:12 sfinucan bauzas: it doesn't?
11:00:14 sfinucan Oh
11:00:15 bauzas nope
11:00:20 sfinucan Well, should we fix that typo?
11:00:31 bauzas we could do that in a follow-up
11:00:34 bauzas now it's in the gate
11:00:55 sfinucan That sounds fair
11:00:56 bauzas and given we have 3 patches that could be trampled if we provide a new rev
11:01:06 bauzas so, adding the fix at a top patch
11:01:24 mdbooth johnthetubaguy: In case you're interested, looks like the db state was probably corrupt, perhaps due to a previous incomplete cleanup. This was in a CI system. So robustification likely not relevant to anybody.
11:02:21 bauzas sfinucan: restored the +W
11:02:33 sfinucan (y)
11:09:16 sfinucan Are we still merging bugfixes? If so, could I get some eyes on this (to be backported) change? https://review.openstack.org/#/c/396184/
11:09:46 openstackgerrit Stephen Finucane proposed openstack/nova master: Fix backwards compatibility for InstanceNUMACell https://review.openstack.org/396184
11:13:04 johnthetubaguy sfinucan: I think so, although we should avoid high risk ones till tomorrow
11:13:37 johnthetubaguy sfinucan: we usually try to keep master not too different to stable/ocata so any backports we need are likely to be easier
11:15:01 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Make 'get_domain' private https://review.openstack.org/417378
11:17:57 johnthetubaguy mdbooth: ah, good context, in complete cleanup would do it
11:18:35 sfinucan Gerrit's "Add Reviewer" dialog is truly awful
11:22:19 openstackgerrit John Garbutt proposed openstack/nova-specs master: WIP: write up policy ideas for pike https://review.openstack.org/427872
11:37:38 openstackgerrit John Garbutt proposed openstack/nova-specs master: WIP: write up policy ideas for pike https://review.openstack.org/427872
11:40:47 panda any hints on what may cause this ? http://logs.openstack.org/periodic/periodic-tripleo-ci-centos-7-ovb-nonha/632c7f2/logs/overcloud-novacompute-0/var/log/nova/nova-compute.txt.gz#_2017-02-02_08_13_29_759
11:45:55 kashyap mdbooth: or johnthetubaguy: When you have a moment, need an opinon
11:46:10 kashyap Where do you think is appropriate for these kinds of tests to live? https://review.openstack.org/#/c/315786/
11:46:44 kashyap They are trying to add the NMI Watchdog test for a Nova instance in Tempest. But Tempest upstream, rightfully rejects it, as there are no API operations, and it is too Nova-specific
11:47:03 johnthetubaguy kashyap: sounds like we need a nova tempest plugin
11:47:23 johnthetubaguy I would say nova functional tests, but they don't normally need images setup up, AFAIK, I could be wrong
11:47:34 johnthetubaguy kashyap: you really want to be talking to sdague about all that
11:47:53 kashyap johnthetubaguy: Does such a thing exists (or is it exist)?
11:48:06 kashyap johnthetubaguy: Yeah, maybe sdague is still getting ready to wake up
11:48:23 johnthetubaguy kashyap: there are some details here: http://docs.openstack.org/developer/nova/test_strategy.html#types-of-tests
11:48:30 johnthetubaguy but looks like it might need updating
11:48:51 kashyap johnthetubaguy: So, one place you are suggesting is - nova/nova/tests/functional
11:53:05 mdbooth johnthetubaguy: More context on the db_sync thing, looks like we had a puppet job which retried on failure, which included exceeding its timeout. Seems db sync was taking too long and we ended up running 2 simultaneously.
11:53:14 mdbooth So perhaps robustification might be in order.
11:53:37 mdbooth Perhaps the migration should hold an exclusive lock while it runs.
11:53:44 johnthetubaguy mdbooth: it should be all done in a single transaction, for each version, I thought?
11:54:01 johnthetubaguy maybe we never added that stuff in db sync
11:54:27 johnthetubaguy maybe thats not possible...
11:54:48 mdbooth Does msql honour transactions for ddl?
11:55:00 johnthetubaguy I was just thinking the same question, I don't know
11:55:13 johnthetubaguy I had always assume that, but you might be right
11:55:27 johnthetubaguy nothing like an olso.concurrency lock to stop that being an issue, like you say
11:55:51 mdbooth Interwebs say no transactional ddl
11:56:50 mdbooth Think it would have to be a db lock, because we can't be sure where db sync is running.
11:57:05 mdbooth Also, think change would have to be in sqla migrations
11:58:42 johnthetubaguy mdbooth: true, DB lock is safer
12:10:37 owalsh mdbooth: DB lock might be overkill...
12:11:05 owalsh the first db sync succeeded IIRC
12:11:21 mdbooth owalsh: I don't think so. It would only have to used for exclusion of the migration itself.
12:11:44 mdbooth I think it could be pretty simple to implement, tbh.
12:12:02 openstackgerrit Derek Higgins proposed openstack/nova master: Simplify uses of assert_has_calls https://review.openstack.org/428108
12:12:16 derekh johnthetubaguy: sfinucan ^^ sorry forgot to push it up yesterday
12:12:26 mdbooth When you initially read the current version from the migrate_version table you'd take an exclusive lock on it.
12:12:52 mdbooth Then you'd exclude any other migration from starting until this once completed, but other db operations can continue.
12:13:15 sfinucan derekh: Sweet. Cheers :) Think it can/should wait until Ocata is cut though
12:13:42 derekh sfinucan: sounds fine by me, just letting ye know its there
12:20:09 owalsh mdbooth: hmm the oslo.db tests used to lock - https://review.openstack.org/58830
12:20:52 mdbooth owalsh: A good reason to use a db lock
12:21:22 owalsh but why protect the tests with a lock instead of the migration?
12:21:56 mdbooth owalsh: I think every test runs the migrations.
12:22:01 mdbooth Unless... optimisation.
12:22:04 mdbooth But mostly.
12:26:28 owalsh forget that, (should have looked at the diff), it's just locking the engine reset
12:27:20 mdbooth owalsh: I've emailed zzzeek for an opinion. cc'd you.
12:42:21 openstack bug 1660878 in OpenStack Compute (nova) "test_reboot_deleted_server fails with 409 "Cannot 'reboot' instance while it is in vm_state building"" [High,In progress] https://launchpad.net/bugs/1660878 - Assigned to Matt Riedemann (mriedem)
12:42:21 lyarwood hopefully a stupid question, does the gate rebase changes? I keep hitting Bug 1660878 in https://review.openstack.org/#/c/427267/ and wonder if I need to manually rebase it to pick up https://review.openstack.org/#/c/427782/
12:46:45 lyarwood http://logs.openstack.org/67/427267/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/e4e67b3/logs/devstacklog.txt.gz#_2017-02-02_10_50_57_699 - okay, so we merge the change, so I should have https://review.openstack.org/#/c/427782/
12:54:24 openstackgerrit John Garbutt proposed openstack/nova master: Report reserved_host_disk_mb in GB not KB https://review.openstack.org/428120
12:55:46 johnthetubaguy bauzas: sfinucan: a nasty placement issue the openstack ansible guys were hitting ^
12:55:57 johnthetubaguy just want to make sure I am not reading that incorrectly
13:04:25 mdbooth lyarwood: Yep
13:05:19 lyarwood mdbooth: thanks, I'll wait for dansmith and mriedem to come online before I recheck https://review.openstack.org/#/c/427267/ again
13:08:11 mdbooth johnthetubaguy: Do you think you'll get around to https://review.openstack.org/#/c/383859/ before release? Fixes NFS, and makes doing the same for other filesystem-backed drivers trivial. See glusterfs follow-on for eg: https://review.openstack.org/#/c/423402/
13:08:13 gcb sfinucan, mriedem: As I know we have been preparing for final octata release, Can we still merge python 3 unit tests patches now ?

Earlier   Later