Earlier  
Posted Nick Remark
#openstack-nova - 2018-09-26
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 openstack Launchpad bug 1789998 in OpenStack Compute (nova) "ResourceProviderAllocationRetrievalFailed ERROR log message on fresh n-cpu startup" [Low,Triaged]
15:57:42 mriedem a shiny donkey to whoever can bring me the head of https://bugs.launchpad.net/nova/+bug/1789998
15:58:13 efried F, I forgot *again* to collect my shiny nickel in Denver.
15:58:20 mriedem it's still in my backpack
15:58:53 efried That should probably be my bug. But I'm not likely to have time to look at it today.
15:59:55 efried also, /me wonders what "shiny donkey" means. Sounds like a euphemism for something.
16:00:00 efried Will it also fit in your backpack?
16:01:19 mdbooth mriedem: Speaking of common gate bugs: https://review.openstack.org/#/c/605436/
16:01:41 mriedem efried: https://www.youtube.com/watch?v=UNV44oqUF6k
16:01:56 mdbooth Although I didn't to a full test run on it locally first, so I won't be surprised if there's a kink to work out.
16:02:30 mriedem evacuate + affinity + locks = my head will explode
16:03:59 mdbooth mriedem: Add in a context manager which is a closure and some tail recursion ;)
16:05:13 melwitt I added cfriesen to the review

Earlier   Later