Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-23
17:00:34 pvc_ thank you sean-k-mooney. :)
17:01:49 sean-k-mooney pvc_: you should look at https://docs.nvidia.com/grid/latest/grid-vgpu-user-guide/index.html#vgpu-types-tesla-p100 to determin how your tesla P100 can be subdevied
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 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: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: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: Move live_migration.pre.start to the start of the method https://review.openstack.org/612773
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: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 sean-k-mooney suddenly root@test-vgpu:/home/ubuntu# nvidia-smi No devices were found
18:53:24 pvc so sad
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 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: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: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

Earlier   Later