| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-26 | |||
| 15:06:58 | efried | ack | |
| 15:07:49 | bauzas | efried: tl;dr if someday nvidia wants to name a type "nvidia-mysuperawesometypeforaimlcoinminingandotherbuzzword', they just need to release a new driver version | |
| 15:08:13 | bauzas | and I just don't want to have a vendors war on the placement API :) | |
| 15:09:07 | sean-k-mooney | bauzas: mdev types? ya they can be anything but i think there is a lenght limit in the kernel | |
| 15:09:26 | bauzas | sean-k-mooney: sure, TEXT ? | |
| 15:09:35 | bauzas | or whatever crazy | |
| 15:09:47 | efried | these type strings correspond to what you need to put in the config, right? | |
| 15:09:58 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459 | |
| 15:10:53 | bauzas | efried: yup, and I hate that | |
| 15:11:06 | sean-k-mooney | dansmith: looking at the kernel docs its not clare i would have to check the cheder for the mdev device | |
| 15:11:22 | sean-k-mooney | dansmith: sorry that was for bauzas ^ | |
| 15:11:27 | bauzas | efried: but there is a big difference in having a vendor-specific information in a config file, and something set in the DB and shown on the API side :) | |
| 15:11:45 | bauzas | s/, and/vs. | |
| 15:11:59 | bauzas | god dammit, my fucking English | |
| 15:12:35 | sean-k-mooney | bauzas: is that different then your normal english :) | |
| 15:12:59 | bauzas | aber ich lerne Deutch | |
| 15:14:21 | bauzas | sean-k-mooney: https://www.kernel.org/doc/Documentation/vfio-mediated-device.txt | |
| 15:16:12 | sean-k-mooney | bauzas: i read that it does not have the max size of a mdev type specified | |
| 15:16:26 | bauzas | yeah it's a struct | |
| 15:16:47 | bauzas | sean-k-mooney: open bar then, right? | |
| 15:17:24 | sean-k-mooney | bauzas: more or less | |
| 15:17:34 | bauzas | oh and look the header | |
| 15:17:38 | bauzas | who wrote this | |
| 15:17:44 | bauzas | now, you'll understand | |
| 15:17:53 | bauzas | it's totally free | |
| 15:18:07 | bauzas | the less I expose, the safer I am :) | |
| 15:18:29 | mnaser | did nova-scheduler go multiprocess in rocky? | |
| 15:20:17 | bauzas | multi-workers yes | |
| 15:21:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 15:21:39 | bauzas | mnaser: https://review.openstack.org/#/c/159382/ | |
| 15:22:12 | mnaser | proposed in 2015, merged in 2018: nice | |
| 15:22:33 | mriedem | it was abandoned for a few years | |
| 15:22:36 | bauzas | mnaser: we had concerns in the past that were resolved | |
| 15:22:42 | mnaser | oh yeah of course | |
| 15:22:48 | mnaser | it makes sense now with placement being there | |
| 15:23:03 | mnaser | running 3 schedulers across 3 nodes was one big game of luck too | |
| 15:23:41 | sean-k-mooney | mnaser: when we stated clamin in placement you could jsut run multiple schuler process to scale without multiprocess support | |
| 15:25:52 | jaypipes | it was only the caching scheduler that was unsafe for multi-workers. | |
| 15:26:17 | sean-k-mooney | jaypipes: post placement | |
| 15:26:19 | mriedem | oh i'm not sure that's true | |
| 15:26:33 | mriedem | you could still race with filter scheduler | |
| 15:26:49 | mriedem | since there was no claim in the scheduler | |
| 15:27:00 | sean-k-mooney | mriedem: for numa/sriov resouces? | |
| 15:27:11 | mriedem | for anything | |
| 15:27:12 | sean-k-mooney | for a normal vm request i did not tihnk we coudl | |
| 15:27:13 | mriedem | before pike | |
| 15:27:51 | sean-k-mooney | mriedem: was pike when we started claiming cpus ram and disk in placmenent? | |
| 15:27:53 | jaypipes | right. before pike. | |
| 15:28:04 | mriedem | sean-k-mooney: yes | |
| 15:28:47 | sean-k-mooney | mriedem: ok so ya pre pike you could race post pike bar late claimes on the compute node for pinning/sriov/hugepages no race | |
| 15:30:58 | mriedem | or if you're using server groups... | |
| 15:31:02 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: Re-propose numa-aware-live-migration spec https://review.openstack.org/599587 | |
| 15:31:20 | mriedem | so all of the NFV things = still race-tastic | |
| 15:31:55 | mriedem | and ironically the scheduler is the one thing that NFV things hate most because they already know exactly where they want to put the goodies | |
| 15:32:01 | sean-k-mooney | mriedem: thats true for multi process works and multi schduler too right they are both as rachy for nfv stuff | |
| 15:32:12 | mriedem | even single scheduler | |
| 15:32:14 | mriedem | single worker | |
| 15:32:51 | mriedem | this is why a late affinity check exists in the compute | |
| 15:39:24 | mdbooth | efried: Just wondering about external, non-libvirt CI in the context of https://review.openstack.org/#/c/602174/ | |
| 15:40:12 | mdbooth | efried: Do you have one of those? If so, do you write your own jobs 'from scratch', or would the changes to the playbooks/.zuul.yaml in there cause it to fail? | |
| 15:41:31 | efried | mdbooth: We have an external, non-libvirt CI, yes. It runs tempest stuffs. I'm not an expert on it. | |
| 15:42:01 | mdbooth | efried: Ok. Just wondering if you'd end up running gate/test_evacuate.sh by default. | |
| 15:42:08 | mdbooth | If you did, it would fail. | |
| 15:42:24 | mdbooth | mriedem: Do you know how external CI is typically configured ^^^ ? | |
| 15:42:44 | efried | "typically"? | |
| 15:42:50 | efried | not really, no. | |
| 15:42:59 | efried | I couldn't really even tell you how ours is configured :) | |
| 15:43:09 | efried | edmondsw: Any ideas ^ ? | |
| 15:43:49 | edmondsw | not sure what gate/test_evacuate.sh is | |
| 15:43:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add attach kwarg to base/nova-net allocate_for_instance methods https://review.openstack.org/605464 | |
| 15:43:56 | jaypipes | gibi: question for you on https://review.openstack.org/#/c/591811/. I'm sure I'm just missing something silly... | |
| 15:43:57 | mriedem | mdbooth: they wouldn't | |
| 15:43:59 | efried | mdbooth: It looks to me like this is only going to change the legacy nova-live-migration job. Does that even get triggered anymore? | |
| 15:44:06 | mdbooth | edmondsw: It's new in https://review.openstack.org/#/c/602174/ | |
| 15:44:07 | mriedem | efried: yes | |
| 15:44:08 | gibi | jaypipes: looking | |
| 15:44:16 | mriedem | devstack-gate can run post-test hook scripts | |
| 15:44:39 | mdbooth | Basically if it's 'opt-in' then failing if libvirt isn't configured is the correct behaviour | |
| 15:44:40 | mriedem | some 3rd party CI still uses devstack-gate, some are moving to zuul v3 which doesn't use devstack-gate (unless you define a legacy-style job, like nova-live-migration) | |
| 15:44:48 | mriedem | it's definitely opt-in | |
| 15:44:53 | mdbooth | If we always run it we'd probably want it to just skip | |
| 15:44:59 | mdbooth | mriedem: Thanks | |
| 15:45:52 | edmondsw | mdbooth our CI is currently using devstack all-in-ones for each run, so it can't do things like evacuate that require multiple nodes yet... working on that | |
| 15:46:10 | mriedem | tempest doesn't test evacuate anyway | |
| 15:46:20 | efried | and we're using zuulv3, right? | |
| 15:46:23 | mriedem | that's why this in a separate script, when tempest isn't running | |
| 15:46:29 | openstackgerrit | Merged openstack/nova stable/queens: Follow devstack-plugin-ceph job rename https://review.openstack.org/602019 | |
| 15:46:36 | openstackgerrit | Merged openstack/nova stable/queens: nova-status - don't count deleted compute_nodes https://review.openstack.org/604786 | |
| 15:47:17 | gibi | jaypipes: you are right we are not catching AllocationDeleteFailed explicitly above in the call stack. Fortunately there are generic exception handling in place alreasy that puts the instance in ERROR state. | |
| 15:47:56 | gibi | jaypipes: the move operations are async on the API so when the fault happens there is no way to return that back to the API user anyhow | |
| 15:49:34 | edmondsw | efried we are not using zuulv3 in PowerVM CI yet, if that's what you were asking | |
| 15:49:51 | efried | dah, okay, thought we were | |
| 15:50:24 | edmondsw | last I heard, zuulv3 wasn't really ready for 3rd party CI usage yet | |
| 15:51:10 | melwitt | mriedem: I was looking at whether I should add the vmware live migration patch (in the queue) to a runway but saw it's failing vmware CI, and I see you've been discussing it with rado https://review.openstack.org/#/c/270116 | |
| 15:53:05 | mriedem | i haven't looked at it since my last comments | |
| 15:53:48 | mriedem | it's also failing unit test | |
| 15:54:20 | melwitt | ok. I'll make a note next to it in the queue | |
| 15:57:42 | mriedem | a shiny donkey to whoever can bring me the head of https://bugs.launchpad.net/nova/+bug/1789998 | |
| 15:57:42 | openstack | Launchpad bug 1789998 in OpenStack Compute (nova) "ResourceProviderAllocationRetrievalFailed ERROR log message on fresh n-cpu startup" [Low,Triaged] | |
| 15:58:13 | efried | F, I forgot *again* to collect my shiny nickel in Denver. | |