| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-23 | |||
| 17:03:57 | pvc_ | noted on this. thanks for your help. :) | |
| 17:07:35 | openstackgerrit | Merged openstack/nova-specs master: Document Stein review priorities https://review.openstack.org/609807 | |
| 17:17:04 | openstack | Launchpad bug 1787910 in OpenStack Compute (nova) rocky "OVB overcloud deploy fails on nova placement errors" [High,Fix committed] - Assigned to Matt Riedemann (mriedem) | |
| 17:17:04 | melwitt | dtantsur: I've been meaning to ask you a question about this ironic bug we fixed around RC time https://bugs.launchpad.net/nova/+bug/1787910 in comment #2 you mentioned the regression broke the ironic-inspector CI upstream. do you happen to know why the ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa job we run in nova did not break the same way? | |
| 17:17:17 | dtantsur | melwitt: looking | |
| 17:18:17 | melwitt | thanks. I don't know the differences between the ironic-inspector job and our job | |
| 17:18:35 | dtantsur | melwitt: okay, so tripleo got broken because it still used disk/ram filters with ironic | |
| 17:18:38 | melwitt | trying to learn if there's a test coverage gap we can close to catch more issues | |
| 17:18:54 | dtantsur | as to inspector, I don't remember why exactly I mentioned that. but there is at least one difference | |
| 17:19:17 | dtantsur | ironic CI does not set vcpus/memory_mb on nodes, which leads to them not exposed to nova for some time | |
| 17:19:29 | dtantsur | ironic-inspector, as part of its functioning, discovers these properties and sets them | |
| 17:19:45 | sean-k-mooney | dtantsur: i was under the impression we ended up keeping the disk/ram filter for that reason in rocky and it was going to be fixed in ironic this cycle | |
| 17:20:24 | dtantsur | sean-k-mooney: I don't think it was for this reason, but I may be missing something | |
| 17:20:40 | dtantsur | for ironic these properties (and filters) are optional since.. mmm.. pike? maybe queens | |
| 17:21:23 | melwitt | dtantsur: thanks for the pointer | |
| 17:21:40 | dtantsur | np | |
| 17:21:46 | sean-k-mooney | dtantsur: we defintly had a bug in the RC period related to them during rocky release. mriedem do you remeber what the bug related to ironc and the disk/ram filter was? | |
| 17:22:25 | dtantsur | sean-k-mooney: the link melwitt posted above? yeah, essentially disk/ram filter stopped working for ironic. since nobody cares about this case any more, we just ended up fixing tripleo to not enable these filters. | |
| 17:22:33 | dtantsur | no further investigation was done IIUC | |
| 17:23:17 | sean-k-mooney | dtantsur: maybe not sure | |
| 17:24:08 | melwitt | yeah, looks like it, use of the filters resulted in NoValidHost because of the bug | |
| 17:25:03 | melwitt | so I probably the failure to update_available_resource was showing up in our ironic job, but was hidden because things otherwise worked (without ram/disk filters). which seems like it would be unexpected | |
| 17:25:06 | sean-k-mooney | i think the only reason to use the disk/ram filter today would be if you were using the caching scheduler since it does not use palcement | |
| 17:27:25 | dtantsur | yep | |
| 17:31:10 | openstackgerrit | sean mooney proposed openstack/nova-specs master: Add spec for sriov live migration https://review.openstack.org/605116 | |
| 17:31:48 | melwitt | looks like there were two different bugs in this bug. one was the update_available_resource fail (which wasn't caught by any CI) and then the core/ram/disk filter problem which was "unfixable", that is, only way out was to stop configuring deployments to use the filters | |
| 17:33:16 | melwitt | it just so happened that because tripleo CI was failing because it was using the core/ram/disk filters, they also noticed the update_available_resource failure in the logs | |
| 17:33:44 | sean-k-mooney | brb | |
| 17:34:26 | openstackgerrit | Merged openstack/nova-specs master: Detach and attach boot volumes - Stein https://review.openstack.org/600628 | |
| 17:52:41 | mriedem | efried: do you/anyone care about this anymore? https://review.openstack.org/#/c/560174/ it was mostly just historical documentation right? | |
| 18:27:01 | efried | mriedem: I'm not sure. The information is probably still useful. I guess the last sentence would need to be updated to reflect how we actually solved it. Swhy I hadn't abandoned it yet. | |
| 18:27:46 | openstackgerrit | Sundar Nadathur proposed openstack/nova-specs master: Nova Cyborg interaction specification. https://review.openstack.org/603955 | |
| 18:33:47 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: Ensure attachment cleanup on failure in driver.pre_live_migration https://review.openstack.org/612774 | |
| 18:33:47 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: Move live_migration.pre.start to the start of the method https://review.openstack.org/612773 | |
| 18:35:26 | efried | mriedem: abandoned | |
| 18:35:27 | melwitt | huh, looks no longer possible to filter logstash by n-cpu log type only. I guess not enough people used it | |
| 18:37:42 | artom | Huh, stable/pike is going to be very problematic for ^^ | |
| 18:38:38 | mriedem | melwitt: tags:"screen-n-cpu.txt" | |
| 18:38:52 | melwitt | mriedem: filters out my result when I do | |
| 18:39:20 | artom | Oh wait, our downstream bug is OSP13/queens, so we're good | |
| 18:39:21 | melwitt | oh wait | |
| 18:39:30 | melwitt | mriedem: user error, my bad | |
| 18:40:30 | edleafe | cdent: ^^ Got all the tests passing locally \o/ | |
| 18:40:43 | edleafe | doh! fat fingers ^^ | |
| 18:41:14 | melwitt | I want to create an e-r query and I'm rusty | |
| 18:41:29 | mriedem | well, there are specs to be reviewed if you wanted to do that instead :) | |
| 18:41:43 | melwitt | I'm doing that too | |
| 18:42:25 | melwitt | I thought this would be quicker than it's being | |
| 18:49:17 | melwitt | bah, there's already a query for this. just e-r hasn't posted anything on it | |
| 18:51:18 | mriedem | jroll: you might want to take a gander at this ironic volume-backed resize/cold migrate spec https://review.openstack.org/#/c/449155/ | |
| 18:51:25 | mriedem | i haven't been through it in quite awhile | |
| 18:51:37 | mriedem | but i'm also not very ironically inclined | |
| 18:52:30 | mriedem | seems that tuba guy would also care about this | |
| 18:53:24 | pvc | so sad | |
| 18:53:24 | pvc | sean-k-mooney suddenly root@test-vgpu:/home/ubuntu# nvidia-smi No devices were found | |
| 19:01:01 | cfriesen | since it's spec review day, I'd appreciate some eyes on https://review.openstack.org/#/c/571111/ | |
| 19:01:14 | cfriesen | (the emulated TPM spec) | |
| 19:02:32 | pvc | nervermind me | |
| 19:04:03 | cfriesen | I think the open questions are whether we want to support CRB at this point (and if so how to ask for it), and whether we need to explicitly call out what happens for non-x86 architectures or leave that for the implementation. | |
| 19:58:00 | mriedem | jaypipes: are there any plans for this? https://review.openstack.org/#/c/529135/ | |
| 20:02:47 | sean-k-mooney | mriedem: by the way sorry to be so negitive on https://review.openstack.org/#/c/612500 i understand why huawei and zte wants this but i really dont think its a viable option | |
| 20:03:17 | cdent | any particularly exciting specs to look at? | |
| 20:04:23 | sean-k-mooney | i dont know is https://review.openstack.org/#/c/600016/ worth reading ? | |
| 20:05:26 | cdent | sean-k-mooney: jay likes it, eric's less sure. I think if I update it to include the use case that eric's describing, it's a useful feature, but not likely to happen in stein | |
| 20:05:29 | jaypipes | mriedem: that's another one I tired of fighting about. | |
| 20:05:35 | artom | Wouldn't that be more or a placement spec at this point? | |
| 20:06:17 | jaypipes | mriedem: would be nice to get a real solution for it. apparently Oath has a whole code series for that backported against Ocata that I am supposed to figure out what is wrong with. :( | |
| 20:06:41 | sean-k-mooney | cdent: i have not read it yet but my first reaction to "GET /resource_providers?having=VCPU" was thats not already a thing? | |
| 20:07:12 | sean-k-mooney | e.g. i just assumed there was an effiect way to say give me all there resouce provierd with X resouce class | |
| 20:07:14 | cdent | nope, you can't easily list _any_ resource provider that has a particular class of resource, as it will leave out providers that are full | |
| 20:07:54 | sean-k-mooney | ah so its the and are not full bit that is missing right | |
| 20:08:08 | sean-k-mooney | well and may or maynot be full | |
| 20:08:24 | mriedem | sean-k-mooney: it's not my spec | |
| 20:08:27 | sean-k-mooney | e.g. just list all the RPs that have X regarless of there fullness | |
| 20:08:45 | cdent | exactly | |
| 20:09:15 | cdent | artom: placement specs is not a thing yet | |
| 20:09:19 | sean-k-mooney | mriedem: ya i kindof assumed you jsut repoposed after the spec repo rebase | |
| 20:09:37 | sean-k-mooney | mriedem: but did you not say huawei wanted this back in dublin | |
| 20:09:48 | mriedem | huawei wants sriov bond yes | |
| 20:09:58 | mriedem | *huawei's customers want sriov bond | |
| 20:10:08 | sean-k-mooney | mriedem: ya thats want i ment rather then that spec specifcally | |
| 20:11:32 | mriedem | but i can't get the network product guys internally to clearly describe the requirements they have against nova | |
| 20:11:40 | artom | cdent, oh. Um, should it be, with the split and everything? | |
| 20:11:43 | mriedem | so i can't really compare what they want, or their proposed solutions, to the zte spec | |
| 20:12:20 | mriedem | except they all say "something has to do the bond within the guest" hand wave hand wave | |
| 20:12:33 | sean-k-mooney | mriedem: ya i know that feeling. the zte solution is very non cloudy | |
| 20:12:36 | cdent | artom: the idea is that it will likely happen once the split is deemed complete. We have a list of things to complete before we declare that | |
| 20:13:41 | mriedem | jaypipes: you need to get your build request user metadata scheduler filter thing done first | |
| 20:13:44 | artom | cdent, fair enough, thanks :) And reading the commit message, you just wanted to stash https://review.openstack.org/#/c/600016/ somewhere | |
| 20:13:44 | sean-k-mooney | mriedem: what is often missed is sure you can do the bond in the guest but unless you tell neutron about it so it can confiugre the top of rack switch you screwed if you want to use lacp | |
| 20:14:00 | jaypipes | mriedem: yep. | |
| 20:14:03 | cdent | artom: yup | |
| 20:14:19 | jaypipes | mriedem: right after I shoot myself in the head from looking at Chef recipe bullshit. | |
| 20:17:34 | melwitt | mriedem: just so I'm clear, does the initial allocation ratios spec cover the ability to set per aggregate allocation ratios? https://review.openstack.org/552105 I mean, I know it's not called out in the spec, but does the spec allow it to work as a side effect? | |
| 20:18:11 | melwitt | or is there more work or another spec we would need to restore per aggregate allocation ratio abilities? | |
| 20:19:38 | sean-k-mooney | melwitt: i think that would be a different spec. but if the desire for aggragate allocation ratios was just to be able to set it via an api then plament does that | |
| 20:20:43 | melwitt | yeah, that's what I mean, if it's already possible to set allocation ratio per aggregate in placement, then I guess after the spec I linked is implemented, users will have what they need to do it | |
| 20:21:56 | sean-k-mooney | melwitt: well no thats not possible but you can prgramtclly set an allocation via the api. you would have to loop over the RPs in the placement aggreate to set them via the placemetn api to get the same effect as nova old aggreate allocation ratios | |
| 20:22:15 | mriedem | melwitt: no | |
| 20:22:29 | mriedem | melwitt: you're looking for https://review.openstack.org/544683 | |