Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-26
14:37:19 openstackgerrit Matthew Booth proposed openstack/nova master: Run evacuate tests with local/lvm and shared/rbd storage https://review.openstack.org/604400
14:38:24 efried bauzas: please have a quick look at new comments on https://review.openstack.org/#/c/599208/ before you put up a new patch set.
14:39:04 bauzas efried: ack, thanks for the notice, I was writing the UTs :)
14:39:11 efried I figgered
14:44:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268
14:46:45 bauzas efried: about your two points, fair enough for the type, but maybe it's YAGNI
14:47:29 efried bauzas: surely doesn't do any harm
14:49:03 openstackgerrit Merged openstack/nova stable/queens: Skip ServerActionsTestJSON.test_rebuild_server for cells v1 job https://review.openstack.org/605115
14:50:14 mriedem stephenfin: done
14:50:25 stephenfin mriedem: Ta
14:53:12 sean-k-mooney mriedem: i tried to review https://review.openstack.org/#/c/605199/ this morning.
14:53:32 sean-k-mooney mriedem: your logic makes sense to me but i dont know why its failing
14:55:22 melwitt naichuans: yes, stein runways are open. feel free to add approved ready-for-review blueprints to the queue
14:59:46 mriedem sean-k-mooney: yeah idk either, it's not very important right now, i have a workaround in nova, and it can wait for dan to come back
15:00:15 bauzas naichuans: keep in mind we need first to have both the consumer-gen series and the scheduler using nested allocations series to be merged before your one
15:00:31 bauzas naichuans: and we also need a reshaping change for the xen driver
15:06:40 bauzas efried: I left a reply on my change
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

Earlier   Later