Earlier  
Posted Nick Remark
#openstack-nova - 2018-01-23
16:16:56 mriedem right before you pushed
16:17:06 mriedem we can assert the fault is set in the functional test that is also being updated
16:17:14 melwitt I think maybe I did what you asked
16:17:31 melwitt oh, nope, different func test
16:17:48 mriedem ah that works too
16:18:00 melwitt k, lemme add that
16:18:03 mriedem that's fine,
16:18:20 mriedem this is better actually because a rebuild can be done for a non-admin and we want to make sure the non-admin can see the fault
16:18:44 mriedem i don't know if we want to say something specific in the fault message about attempting to rebuild with a different image, that could be a slippery slope of assumptions about why we failed
16:18:45 melwitt okay, cool
16:19:13 mriedem like, image might be fine, but some other filter failed because a resource is unavailable or something
16:19:33 melwitt yeah, I was thinking about that too
16:19:46 mriedem +2
16:20:23 mriedem heh stable/newton is still around
16:21:29 melwitt :)
16:22:37 mriedem this is probably not worth yet another newton release before eol though
16:22:46 mriedem tonyb: when you gonna pull that newton-eol trigger?
16:23:27 melwitt wah wah
16:30:05 bauzas wait, Newton is not EOL'd yet ?
16:30:08 bauzas woah
16:30:14 mriedem melwitt: want to start on the backports?
16:30:47 melwitt mriedem: yes
16:30:47 bauzas melwitt: mriedem: dansmith: I think we should document a relnote with https://review.openstack.org/#/c/536268/6
16:31:01 bauzas I was about to say that we will provide a new behaviour
16:31:16 dansmith bauzas: it's really the behavior that every other action has though
16:31:18 bauzas I'm not asking for a microversion, but we need to explain for operators I think
16:31:31 bauzas dansmith: I know
16:31:41 bauzas dansmith: I'm just thinking that it's a game changer
16:31:56 bauzas and documenting it would be IMHO a small thing for a better point
16:32:00 mriedem *shrug* i thought about a "fixes" release note just to point out that if scheduling fails during rebuild the instance will go to ERROR state and a fault will be recorded
16:32:02 bauzas I just don't want to see rants here :p
16:32:20 bauzas mriedem: exactly my point
16:32:26 bauzas not more than that
16:32:35 mriedem i'd be fine with that
16:32:37 bauzas so we can point out the relnote if someone is aking that
16:32:47 dansmith meh.
16:33:03 bauzas backporting that means also that we will change the logic
16:33:27 bauzas hopefully the stable version will be not a .z one
16:33:57 mriedem umm
16:34:00 mriedem it's not a new feature
16:34:03 mriedem it's a bug fix
16:34:16 bauzas sure, but we're changing the API right?
16:34:26 mriedem we didn't bump the .y for the change that made the API fail fast if you tried to rebuild a volume-backed instance and change the image
16:34:28 bauzas again, I'm not asking for a microversion, please
16:34:36 bauzas okay
16:34:51 bauzas whatever the semver will be, I just think we need to explain that to ops
16:35:32 bauzas os-instance-actions API is admin by default ?
16:35:42 mriedem no
16:35:44 bauzas I don't remember, I need to look at the default policy
16:35:50 bauzas ok, cool then
16:35:54 mriedem os-instance-actions events with the traceback is admin by default
16:36:03 bauzas hah, right
16:36:09 mriedem i think you can't see the events before some microversion if you're not an admin either
16:36:22 bauzas I can test on my box
16:36:53 mriedem don't bother: https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id46
16:37:18 bauzas cool cool
16:38:59 openstackgerrit Merged openstack/python-novaclient master: Add support for microversion 2.60 - volume multiattach https://review.openstack.org/536621
16:39:52 bauzas mriedem: dansmith: melwitt: looks like my proposal to add a relnote didn't get a huge consensus, still okay if I'm providing it ?
16:39:53 melwitt mriedem, bauzas: so, should I add a fixes relnote to the patch then?
16:40:01 bauzas hah, jinxed
16:40:02 mriedem incoming
16:40:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Set server status to ERROR if rebuild failed https://review.openstack.org/536268
16:40:16 bauzas who's doing that ? I can take my pen if nobody does
16:40:32 bauzas oh, a new rev
16:40:36 bauzas mriedem: on it
16:41:07 bauzas mriedem: +2
16:41:22 bauzas I can fast-approve or dansmith can +W
16:43:30 mriedem stvnoyes: ildikov: first victim of the multiattach swap volume test http://logs.openstack.org/89/532689/5/check/nova-multiattach/094e46b/job-output.txt.gz#_2018-01-23_12_43_58_790340
16:44:59 mriedem this is where the swap starts http://logs.openstack.org/89/532689/5/check/nova-multiattach/094e46b/job-output.txt.gz#_2018-01-23_12_43_59_312226
16:45:12 openstackgerrit melanie witt proposed openstack/nova stable/pike: Set server status to ERROR if rebuild failed https://review.openstack.org/536897
16:45:44 dmsimard mriedem, kashyap: hi o/ It would be nice if we could land these in time for queens: https://review.openstack.org/#/c/524748/ && https://review.openstack.org/#/c/526748/ (and understand why the guestfs.set_backend_settings patch is breaking things when testing it here https://review.openstack.org/#/c/524750/ )
16:46:06 dmsimard I suppose these are stable backport candidates as well
16:47:41 mriedem ildikov: stvnoyes: this is on a rax-dfw node and those have been really slow lately, so maybe it's just related to a slow node timeout since the swap volume tests do take awhile
16:48:04 mriedem dmsimard: i can't really say why things don't work with that stuff,
16:48:12 mriedem need some more libguestfs/qemu people
16:48:48 dmsimard mriedem: I don't know these people, I'm a mere mortal :(
16:49:12 mriedem dmsimard: i think https://review.openstack.org/#/c/526748/ is pretty straight forward though - don't do logging in a thread
16:49:17 mriedem b/c eventlet can explode
16:51:36 stvnoyes mriedem, ildikov, I finally got my new env working but I am seeing some failures in the 'normal' tempest multiattach tests. I am looking to see why that is. It is likely something unique to my env. that's what I'm doing atm.
16:52:03 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
16:55:24 mriedem it's doing the swap here http://logs.openstack.org/89/532689/5/check/nova-multiattach/094e46b/logs/screen-n-cpu.txt.gz#_Jan_23_11_16_02_654135
16:56:55 mriedem sdague: do you ever remember anything about losing a requestid when using an elevated context? or people talking about resolving that?
16:57:17 mriedem i was tracing a swap volume operation through the logs and lose some of the logging once the context gets elevated
16:58:29 openstackgerrit Jackie Truong proposed openstack/python-novaclient master: Microversion 2.61 - Add trusted_image_certificates https://review.openstack.org/500396
16:58:30 openstackgerrit Radoslav Gerganov proposed openstack/nova master: fix _ensure_resource_provider() https://review.openstack.org/536902
17:01:49 openstackgerrit Radoslav Gerganov proposed openstack/nova master: WIP: VMware: implement update_provider_tree() https://review.openstack.org/536348
17:03:09 openstackgerrit melanie witt proposed openstack/nova stable/ocata: Set server status to ERROR if rebuild failed https://review.openstack.org/536904
17:13:05 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Refactor WSGI apps and utils to limit imports https://review.openstack.org/533797
17:15:56 gibi mriedem: btw, do you need me to run the weekly nova meeting on Thrusday?
17:16:28 mriedem gibi: maybe...
17:16:36 mriedem i'll let you know in a bit
17:16:47 gibi mriedem: OK, I can do that if needed
17:17:20 mriedem gibi: i should be able to do it, assuming i can remember :)
17:17:34 gibi mriedem: OK
17:36:49 artom melwitt, no newton backport for the rebuild imageref fix? There was some confusion whether newton is EOL or not
17:38:46 dansmith artom: it's EOL, just not deleted yet
17:38:50 melwitt artom: indeed the stable/newton branch is still around coincidentally. but earlier mriedem said it's probably not worth another newton release for this
17:39:44 dansmith I agree
17:40:25 artom Sure, not gonna argue with that
17:40:45 artom (I mean, I probably would, in theory)

Earlier   Later