Earlier  
Posted Nick Remark
#openstack-nova - 2018-10-18
19:29:28 mordred eandersson: either $nova_api_url/v2.1 or $nova_api_url should totally work with keystoneauth/openstacksdk/shade
19:29:46 mordred eandersson: I think there are some older things out there that assume the thing in the catalog has the version appended
19:30:29 mordred but for nova I believe most of them do the right thing either way
19:30:41 eandersson So there might be an edge case that does not handle it properly
19:30:58 mordred I *personally* prefer unversioned endpoint in catalog because putting versioned endpoint in catalog is what got us into the wole volumev2 volumev3 service-type mess
19:31:41 mordred but I'm pretty sure nova isn't going to have a new major version in the new future, so putting a versioned nova endpoint in the catalog should be fine
19:31:56 mordred hopefully you're enjoying how I'm not giving you an answer at all
19:33:40 eandersson Yea I agree on unversioned
19:33:50 eandersson It's also causing minor issues for us with a api proxy
19:34:00 eandersson but might just be my lack of knowledge on nginx
19:34:46 eandersson hehe
19:49:54 openstackgerrit melanie witt proposed openstack/nova master: Add nova-status upgrade check for consoles https://review.openstack.org/611214
19:49:55 openstackgerrit melanie witt proposed openstack/nova master: Add rolling upgrade info to enable_consoleauth workaround reno https://review.openstack.org/611218
20:10:30 openstackgerrit Artom Lifshitz proposed openstack/nova master: Ensure attachment cleanup on failure in driver.pre_live_migration https://review.openstack.org/587439
20:10:35 artom mriedem, ^^
20:15:05 artom Cheerio :)
20:36:48 mriedem efried: gibi: hoowee i just went through https://review.openstack.org/#/c/606050/
20:36:50 mriedem kind of a doozy
20:37:29 mriedem dansmith: i believe ^ will mean that if we ever go down the non-migration-based allocation cleanup route on a same-host resize, we'll wipe out all allocations for the instance, including for the old_flavor
20:37:44 mriedem but, i'm not sure how possible that is today unless you have <queens computes in a cell
20:37:49 mriedem which shouldn't happen if you're running stein
20:37:53 tonyb mriedem: Oh gosh that's a question ... I'll research it and see
20:38:04 mriedem tonyb: i forgot the question
20:38:37 tonyb mriedem: is emulatedTPM supported on kvm on power
20:38:44 mriedem oh
20:39:04 tonyb I have the spec open and I'll go read some code when I get off this meeting
20:40:28 mriedem i'm going to shift gears and do something fun like delete the caching scheduler
20:57:26 efried mriedem: Left responses to some of your queries. The main one I can't answer, though.
20:57:49 mriedem where do babies come from?
20:57:50 mriedem that one?
21:03:49 openstackgerrit Merged openstack/nova master: Merge image_size extension response into image view builder https://review.openstack.org/606845
21:12:30 cdent mriedem: do you recall if somebody already thought about postgresql with regard to https://review.openstack.org/#/c/611115/ ? Since it is a group by it might cause the "must appear in the GROUP BY" error. But I can't remember if that only happens if you use an agg function.
21:13:07 cdent So I started a check experimental on it, but then realized the tempest-pg-full won't run the functional tests that exercise the problem. Is there anything else that will?
21:13:26 mriedem nope
21:13:44 mriedem the only mysql/pg-specific stuff that runs in func/unit tests are the schema migration tests
21:14:18 mriedem the alternative is using DISTINCT in there as efried pointed out
21:15:07 efried I tried ^ locally and it worked, but no idea what that means.
21:15:18 efried I've been wanting to ask jay what the difference is.
21:15:39 efried He +2d the change, so he must've thought GROUP BY was fine, but...
21:16:13 cdent it's perfectly fine as is for mysql, but _might_ be a problem for pg
21:17:35 cdent I can poke at it (/me looks at queue ... ) Monday if nobody else wants/needs to. mriedem do you think this will tickle the problem?
21:18:02 cdent as in: do we need to care about this?
21:18:47 mriedem what will tickle the problem?
21:19:11 mriedem i don't know enough about group by rules for pg
21:19:41 mriedem you could probably recreate it with just placement and a pg db,
21:20:05 mriedem by having a consumer with >1 allocation against a resource provider and there not being any consumers table record for the allocations
21:20:09 mriedem so just hack it up manually
21:22:23 cdent What I meant was: is this the type of group by that postgresql will wail at? It will be easy enough to mess with manually. But for me, I won't have time before Monday
21:23:20 mriedem i don't know the answer to that
21:23:38 mriedem zzzeek_ might know off the top of his head
21:26:33 cdent i've left a note on the review, if nothing happens before next week, I'll dig
22:02:32 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove the CachingScheduler https://review.openstack.org/611723
22:02:57 mriedem johnthetubaguy: mgagne: ^
22:04:20 mgagne +1 for me
22:04:42 mgagne didn't review the technical side of your removal, just the idea
22:07:05 mriedem email sent to the ops list as well
22:30:38 openstackgerrit Merged openstack/os-vif master: Fix random test_unplug_ovs failures https://review.openstack.org/611017
22:30:39 openstackgerrit Merged openstack/os-vif master: Do not call linux_net.delete_net_dev on Windows https://review.openstack.org/610916
22:47:37 openstackgerrit Sundar Nadathur proposed openstack/nova-specs master: Nova Cyborg interaction specification. https://review.openstack.org/603955
23:00:36 openstackgerrit Dan Smith proposed openstack/nova master: Return a minimal construct for nova service-list when a cell is down https://review.openstack.org/584829
23:32:15 openstackgerrit Merged openstack/nova stable/queens: Handle volume API failure in _post_live_migration https://review.openstack.org/611084
23:46:08 openstackgerrit Merged openstack/nova master: Fix typo in libvirt.hw_machine_type help https://review.openstack.org/611422
23:46:15 openstackgerrit Merged openstack/nova master: Fix block_device_mapping_v2 mention in server create API reference https://review.openstack.org/611433
#openstack-nova - 2018-10-19
00:58:59 openstackgerrit Brin Zhang proposed openstack/nova master: Add restrictions on updated_at when getting migrations https://review.openstack.org/607798
01:05:35 openstackgerrit Brin Zhang proposed openstack/nova master: Add restrictions on updated_at when getting instance action records https://review.openstack.org/607801
02:04:14 openstackgerrit Merged openstack/python-novaclient master: Recommend against using --force for evacuate/live migration https://review.openstack.org/611436
03:04:08 openstackgerrit Merged openstack/nova stable/rocky: Ignore uuid if already set in ComputeNode.update_from_virt_driver https://review.openstack.org/611337
03:34:01 openstackgerrit Merged openstack/nova stable/rocky: Use unique consumer_id when doing online data migration https://review.openstack.org/611315
05:35:06 openstackgerrit Takashi NATSUME proposed openstack/nova master: Fix best_match() deprecation warning https://review.openstack.org/611204
05:46:11 openstackgerrit Brin Zhang proposed openstack/nova master: Add restrictions on updated_at when getting migrations https://review.openstack.org/607798
05:48:31 openstackgerrit Brin Zhang proposed openstack/nova master: Add restrictions on updated_at when getting instance action records https://review.openstack.org/607801
06:36:43 jaosorior Could I get a review for this https://review.openstack.org/#/c/609591/ ?
07:09:25 bauzas Good morning Nova
07:17:59 openstackgerrit Zhenyu Zheng proposed openstack/nova-specs master: Detach and attach boot volumes - Stein https://review.openstack.org/600628
08:19:47 openstackgerrit Merged openstack/nova master: Migrate nova v2.0 legacy job to zuulv3 https://review.openstack.org/610403
10:13:56 openstackgerrit Tetsuro Nakamura proposed openstack/nova-specs master: Spec: Support filtering by forbidden aggregate https://review.openstack.org/603352
10:30:56 openstackgerrit huanhongda proposed openstack/nova master: AZ operations: check host has no instances https://review.openstack.org/611833
10:33:52 openstackgerrit huanhongda proposed openstack/nova master: AZ operations: check host has no instances https://review.openstack.org/611833
11:39:33 openstackgerrit Radoslav Gerganov proposed openstack/nova master: Preserve compute stats used by the scheduler https://review.openstack.org/611852
12:39:03 openstackgerrit Matt Riedemann proposed openstack/nova master: Document each libvirt.sysinfo_serial choice https://review.openstack.org/611426
12:43:37 mriedem so uh, do we want to do this stable-only ironic inventory workaround thing in rocky? https://review.openstack.org/#/c/609043/
12:43:50 mriedem and queens and pike
12:44:11 mriedem tl;dr once you've migrated all of your ironic instances to resource classes, you don't want to report vcpu/ram/disk inventory anymore on those nodes
12:48:58 SteelyDan I'd say so
12:53:49 mriedem i wasn't sure if the option should be deprecated immediately? seems kind of weird, but it will just be gone when you get to stein.
12:53:53 mriedem not sure how much it matters
12:56:42 SteelyDan me either
12:56:44 mriedem bauzas: were you witholding a +W on https://review.openstack.org/#/c/610088/ for some reason?
12:56:46 SteelyDan mriedem: does this ring any bells? http://logs.openstack.org/58/591658/12/check/tempest-full-py3/5224550/controller/logs/screen-n-api.txt.gz?level=TRACE#_Oct_18_20_49_20_086138
12:56:47 mriedem even though you were +2?
12:57:10 SteelyDan there's a ton of unrelated red in that log, so ignore the rest, but the FK error there doesn't seem related to the patch
12:57:20 SteelyDan and there are also rabbit connection failures later in the log
12:58:14 mriedem hmm, no, also seems weird that we'd get cell0 FK errors for a resize operation....
12:58:24 mriedem which shouldn't have anything to do with cell0
12:58:48 SteelyDan it's an action,
12:58:50 mriedem unless it's trying to record an action in the api,
12:58:54 SteelyDan but yeah that clearly looks like we're talking to the wrong db
12:58:56 mriedem and defaulting to the cell0 db connectoin in nova.conf,
12:59:06 mriedem but when we look up the instance we should target the context to cell1
12:59:21 SteelyDan oh I bet I know

Earlier   Later