Earlier  
Posted Nick Remark
#openstack-nova - 2017-11-11
01:55:09 openstackgerrit Merged openstack/nova master: Factor out duplicated notification sample data (2) https://review.openstack.org/452819
01:55:15 openstackgerrit Merged openstack/nova master: Deduplicated instance.(un)pause notification samples https://review.openstack.org/452820
02:13:02 openstackgerrit Merged openstack/nova master: Deduplicate instance.power-off notification samples https://review.openstack.org/475860
02:13:08 openstackgerrit Merged openstack/nova master: Deduplicate instance.interface_attach samples https://review.openstack.org/515740
02:13:14 openstackgerrit Merged openstack/nova master: Deduplicate instance.live_migration notification samples https://review.openstack.org/515745
02:13:20 openstackgerrit Merged openstack/nova master: Deduplicate instance.reboot notification samples https://review.openstack.org/515751
09:44:30 openstackgerrit Michael Still proposed openstack/nova master: Convert ext filesystem resizes to privsep. https://review.openstack.org/517516
09:44:30 openstackgerrit Michael Still proposed openstack/nova master: Move flushing block devices to privsep. https://review.openstack.org/519010
09:44:31 openstackgerrit Michael Still proposed openstack/nova master: Start moving users of parted to privsep. https://review.openstack.org/519011
14:59:06 openstackgerrit Hironori Shiina proposed openstack/nova master: virt/ironic: Implement rescue and unrescue https://review.openstack.org/416487
16:57:45 mriedem boooooya
16:57:57 efried Do tell
16:58:21 efried mriedem Back stateside?
16:59:09 mriedem rotting in LAX
17:01:38 efried Sorry to hear that.
17:03:21 efried mriedem You looking around for easy reviews to keep you busy?
17:03:27 efried <smiles sweetly>
17:03:58 mriedem nope
17:04:08 mriedem i'm going on about 1 hour of sleep so it wouldn't be helpful
17:07:10 efried mriedem What sacrifices need to be made to what gods to get a requirements bump backported to stable?
17:08:53 mriedem which one?
17:10:03 efried pypowervm. Found a bug that makes OVS-connected VMs drop their connections unrecoverably on reboot.
17:10:52 efried There's no patch up yet; still working through the fix on the pypowervm & nova-powervm side.
17:11:18 efried Just testing the waters to see if we're going to be able to backport the nova-powervm fix in its pretty form, or if we're gonna have to hack the crap out of it for stable.
17:15:57 mriedem1 sorry, wifi sucks
17:16:15 mriedem1 efried: in general we don't bump minim version in g-r
17:16:22 mriedem1 *minimum
17:17:08 efried Yuh. Are there cases for not-in-general?
17:17:34 mriedem1 yeah, cve's for one
17:18:07 mriedem1 we could maybe fudge this since it's an optional dependency,
17:18:18 mriedem1 but it is in requirements.txt so it kind of depends on how packagers handle requirements,
17:18:36 mriedem1 i know fedora/rhel strip out the requirements.txt and just handle package deps in the rpm spec
17:20:53 efried It's not really a security thing. Just a your-vm-will-break thing.
17:28:52 mriedem1 sure
17:29:13 mriedem one of the risks of putting a bunch of the driver functionality into a library, which makes things sticky
17:29:25 mriedem i will happily defer to his tonyb-ness on this
17:32:53 openstackgerrit Matt Riedemann proposed openstack/nova master: Add FlavorPayload.description for versioned notifications https://review.openstack.org/514782
17:32:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Add microversion to allow setting flavor description https://review.openstack.org/515213
17:52:04 mriedem efried: is this new? http://logs.openstack.org/73/513473/2/check/legacy-tempest-dsvm-cells/be1a0fa/logs/screen-placement-api.txt.gz#_Nov_10_01_14_05_230382
17:52:11 efried ...
17:52:56 efried mriedem It doesnae look good.
17:53:05 efried looking...
17:54:19 mriedem shit i don't think we index the placement api logs
17:58:32 clarkb we should, though indexing has been funky with the zuul v3 switch (slowly been improving its performance)
17:59:44 efried mriedem ensure_consumer_project_user is only a couple weeks old (https://review.openstack.org/#/c/500410/) but I don't see how the _ensure_project thing could fail unless timing (someone else came along and whacked the entry) or the insert failed.
18:00:51 mriedem https://bugs.launchpad.net/nova/+bug/1731668
18:00:51 openstack Launchpad bug 1731668 in OpenStack Compute (nova) "placement: claim allocations fails with IndexError in _ensure_lookup_table_entry" [Undecided,New]
18:00:54 efried oh. Or external_id ain't in there.
18:01:18 efried naw, cause that should insert it.
18:03:13 mriedem this is during scheduling, so not sure if it's a race or what - it must be a race otherwise we'd have a pretty high failure rate
18:03:23 mriedem 21 hits in 10 days
18:07:20 openstackgerrit Eric Fried proposed openstack/nova master: EXPERIMENTAL: Retry getting project ID https://review.openstack.org/519034
18:07:28 efried mriedem If it's racey, this'll fix it ^
18:07:38 efried But the real deal ought to have a limited number of retries :)
18:11:29 mriedem that seems pretty wrong, i mean, if the insert fails because of a duplicate entry
18:16:16 efried mriedem Depends how racey it is. Clearly the second SELECT failed, or we wouldn't be seeing the error. So we got to the exception clause, inserted a new one, then someone else came in and deleted it before we got to the return.
18:18:09 efried Sorry, let me try that again: The first SELECT returns nada. Then we try to INSERT, but someone had already inserted, so we get the exception. Then before we get a chance to run the second SELECT, someone comes along and deletes the entry.
18:18:25 mriedem true
18:18:54 efried That'd be a pretty wild race to be seeing so frequently.
18:26:04 mriedem in debugging this failed job, it looked like the scheduler was creating allocations twice for the same instance in the same scheduling run, but maybe it was moving the instance or something, i didn't dig into what the test does
18:26:49 mriedem actually this just failed in server create
18:28:26 efried mriedem Where do project IDs ever get deleted?
18:29:31 mriedem tempest cleanup
18:29:38 mriedem but that wouldn't be happening here,
18:29:47 mriedem and the project delete would be via keystone on test teardown in tempest
18:30:09 mriedem when we set allocations in placement, we first remove all of the existing allocations it looks like,
18:30:15 mriedem so i'm wondering if that's related somehow
18:33:33 mriedem the test tries to create 2 servers, the first one gets its allocations created in placement, the 2nd fails to create allocations in placement
18:34:16 mriedem the instances are processed serially and we're only using 1 scheduler worker, so it's weird that something would be racing here
18:35:02 mriedem we should start running 2 scheduler workers in our CI jobs just to tease out concurrency bugs, but that's a separate todo
18:36:23 efried I haven't looked at the test cases yet, but if this external_id is a uuidsentinel that we're repeating in multiple (different, unrelated) test cases, could that be causing collisions?
18:36:29 efried Or does each test case get its own database?
18:42:26 mriedem this is integration testing, so real things
18:42:29 mriedem single db
18:42:48 mriedem i'm not sure what external_id is, is that the project_id in this case?
18:43:03 efried Dunno.
18:43:48 mriedem yeah it is
18:44:23 mriedem we ensure there is an entry in the projects table for that entry before linking it to the consumers table which is linked to the allocations table
18:44:24 mriedem i think
18:44:35 mriedem *entry in the projects table for that project id
18:46:23 mriedem and if we're scheduling 2 instanes with the same project, and the first instance scheduled created allocations successfully, the projects table should already have that entry for that project_id
18:46:39 mriedem so the select() should fine it and we shouldn't even attempt the insert()
18:46:44 mriedem *find it
18:46:49 mriedem damn, brain no work good
18:56:05 mriedem efried: this one is up your alley too https://bugs.launchpad.net/nova/+bug/1730800
18:56:05 openstack Launchpad bug 1730800 in OpenStack Compute (nova) "UnknownConnectionError" [Undecided,New]
18:56:08 mriedem looks like ksa adapter stuff
18:56:26 efried looking...
19:02:11 mriedem battery is gonna die, and so am i, so i'm shutting 'er down. ttyl.
21:42:24 openstackgerrit Merged openstack/nova master: Don't update RT in _allocate_network https://review.openstack.org/513473
#openstack-nova - 2017-11-12
03:25:47 openstackgerrit LIU Yulong proposed openstack/nova master: Enable reset keypair while rebuilding instance https://review.openstack.org/379128
07:14:46 openstackgerrit jichenjc proposed openstack/nova master: [Placement] Add create inventories doc for placement https://review.openstack.org/512215
07:15:49 openstackgerrit jichenjc proposed openstack/nova master: Refactor placement version check https://review.openstack.org/512497
07:16:14 openstackgerrit jichenjc proposed openstack/nova master: Add quiesce and unquiesce in support matrix https://review.openstack.org/482390
07:16:42 openstackgerrit jichenjc proposed openstack/nova master: Add description for resource class creation https://review.openstack.org/508083
08:22:01 openstackgerrit Maciej Kucia proposed openstack/nova master: Add JSON schema validation to PCI whitelist https://review.openstack.org/476098
08:32:13 openstackgerrit Moshe Levi proposed openstack/nova master: Don't overwrite binding-profile https://review.openstack.org/519066
14:51:25 openstackgerrit Alex Xu proposed openstack/nova master: placement: avoid multiple join in _get_all_with_shared https://review.openstack.org/519081
17:37:34 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/519127
17:48:24 openstackgerrit OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/519165

Earlier   Later