Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-18
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
12:59:26 mriedem so, it looks like it's probably shitting b/c it's trying to create an action in cell0 for an instance in cell1
12:59:39 SteelyDan this changes it so we're not permanently targeting the context.. so the resize goes on to be untargeted
13:00:22 SteelyDan didn't think of that until you made the connection to cell0
13:00:34 SteelyDan that's also probably why we can't connect to fake:/// or whatever rabbit
13:00:44 mriedem uh huh
13:02:51 openstackgerrit Dan Smith proposed openstack/nova master: Return a minimal construct for nova show when a cell is down https://review.openstack.org/591658
13:02:52 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
13:16:23 bauzas mriedem: just a miss I guess
13:16:24 bauzas fixed
13:18:06 mriedem danke
13:18:19 bauzas bitte
13:30:37 openstackgerrit Daniel Abad proposed openstack/nova master: Fix ironic client ironic_url deprecation warning https://review.openstack.org/611872
14:01:00 melwitt
14:18:29 openstackgerrit Stephen Finucane proposed openstack/osc-placement master: Enforce key-value'ness for 'allocation candidate list --resource' https://review.openstack.org/611883
14:18:30 openstackgerrit Stephen Finucane proposed openstack/osc-placement master: tox: Hide deprecation warnings from stdlib https://review.openstack.org/611884
14:49:43 spatel I got this error when i reboot one of my instance any idea what is this? http://paste.openstack.org/show/732501/
15:27:25 cfriesen spatel: looks like corrupt filesystem
15:28:07 cfriesen or at least corrupt something on disk
15:31:48 mriedem_afk i've triaged https://bugs.launchpad.net/nova/+bug/1798805 but not sure if we would ever do anything about it
15:31:48 openstack Launchpad bug 1798805 in OpenStack Compute (nova) "Nova scheduler schedules VMs on nodes where nova-compute is down" [Wishlist,Triaged]
15:33:07 finucannot bauzas: If I delete a compute nodes RP, it'll be recreated, right?
15:34:04 SteelyDan mriedem_afk: I think that means disable in the "break its needs" sort of sense
15:34:31 SteelyDan I'm strongly in favor of keeping disable purely for scheduler reasons, but I think it's saying if the compute is actually down, we shouldn't take action on instances
15:34:35 SteelyDan which is probably reasonable
15:35:01 SteelyDan or make our super awesome bug-free state sync periodic power the instance on when the compute comes back
15:36:03 imacdonn I kinda sorta wish there was a "don't schedule anything new" status, which is different from "don't try to interact with me at all"
15:36:26 SteelyDan imacdonn: that's what disable means
15:36:29 SteelyDan it's the only thing it means
15:36:43 imacdonn the former, you mean
15:36:59 SteelyDan it means don't schedule anything there
15:37:04 imacdonn right
15:37:31 SteelyDan you're saying you wish there was a "kneecap this compute"
15:37:33 SteelyDan API?
15:37:45 imacdonn IMO, it should really mean "don't talk that node at all right now", and there should be some other way to tell the scheduler not to pout anything NEW there
15:38:23 finucannot mriedem_afk, awaugama: More investigation needed but I think there's something wrong with those foo_allocation_ratio options. I configured them on the compute node, waited ages aaand...nada. Deleting the RP fixed things
15:38:27 imacdonn (or maybe the opposite, so keep the existing meaning of "disable") ... but I think they are use-cases for each
15:38:37 SteelyDan we're not changing the existing meaning for disable
15:38:57 SteelyDan we could add another state, but it just means for every single operation we do another db hit to check the state of the host
15:39:03 finucannot mriedem_afk, awaugama: At least, assuming my understanding of how that's _supposed_ to work is correct. It it Friday so maybe it's not
15:39:24 imacdonn "hard_disabled" ? :)

Earlier   Later