Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-27
13:49:02 mnaser yaaaay
13:49:13 mnaser did you know the cinder section in nova still uses os_region_name and not region_name
13:49:22 mnaser that was a fun exercise.
13:50:01 mnaser and then even when fixing it, i had no idea why it didn't work, turns out service catalog and stuff was being cached
13:50:26 openstackgerrit Eric Fried proposed openstack/nova master: [placement] split gigantor SQL query, add logging https://review.openstack.org/590041
13:50:47 efried nova-scheduler meeting in 10 minutes in #openstack-meeting-alt
13:50:54 sean-k-mooney mnaser: seams ligit. we cache alot of things
13:51:52 mnaser sean-k-mooney: yeah it was a fun exercise in debugging
13:51:59 mnaser attaching a volume where it 404s on the attachemnt :p
14:18:20 openstackgerrit Konstantinos Samaras-Tsakiris proposed openstack/nova-specs master: Placement model for passthrough devices https://review.openstack.org/591037
14:33:47 mriedem stephenfin: have you seen this? http://status.openstack.org/elastic-recheck/#1788922
14:34:03 mriedem we have a new gate failure which started friday after the func test refactor changes landed for the libvirt func test base
14:34:14 mriedem looks like some directories are not getting mocked now and fail in certain node providers
14:34:24 stephenfin mriedem: I had not but I'll look into it now
14:35:46 openstackgerrit Merged openstack/nova master: List instances from all cells explicitly https://review.openstack.org/593717
15:02:41 sahid moshele: i replied
15:34:25 openstackgerrit sahid proposed openstack/nova master: hardware: fix memory check usage for small/large pages https://review.openstack.org/532168
15:34:58 openstackgerrit Stephen Finucane proposed openstack/nova master: privsep: Handle ENOENT when checking for direct IO support https://review.openstack.org/596815
15:35:24 stephenfin mriedem: ^^ I suspect you're going to dislike that, but I can't find any reason that those refactor patches would have caused the CI failures
15:40:28 mriedem stephenfin: ok question inline
15:40:34 mriedem maybe something switched over to py3 on friday?
15:41:23 dansmith shouldn't we be mocking that out for functional tests anyway?
15:42:14 dansmith we wouldn't want a functional test to behave differently if I run it on a weird filesystem...
15:44:01 sean-k-mooney dansmith: well if nova would behave qually weridly maybe we would
15:44:11 sean-k-mooney *equally
15:44:53 dansmith we can test for both/all cases and make sure we handle it
15:45:03 dansmith but anything dependent on the system we're running on belongs in integration tests, IMHO
15:45:24 dansmith otherwise we're saying we expect you can't run functional tests on weird platforms, which I think goes against the intent there
15:46:07 sean-k-mooney dansmith: i really thing mocking in functional test should ideally be as minimal as possible but that said it really depend on what the functional test is testing
15:47:06 dansmith sean-k-mooney: per-test mocking for sure, but I think that if functional tests run differently on the gate depending on which cloud provider, and different on dev boxes because we're using different distros, platforms, filesystems, etc that's not super helpful
15:47:17 sean-k-mooney dansmith: the main delta from me between a integration test and fuctional test is that for functual tests we mock other services
15:47:43 sean-k-mooney dansmith: ya i agree with that point
15:47:43 dansmith sean-k-mooney: it's why we don't use real libvirt in functional, right? because then you couldn't run the functional tests on other platforms
15:48:02 stephenfin dansmith: I thought it was because libvirt was another service, so to speak
15:48:39 mriedem stephenfin: no, it's because i shouldn't have to install libvirt to run unit tests
15:48:50 mriedem like, i don't need a vcenter installed locally to run vmware tests
15:48:51 sean-k-mooney mriedem: unit test yes
15:49:01 sean-k-mooney mriedem: fucntional test i would argue you should
15:49:21 sean-k-mooney mriedem: that is if the fucntional test is testing the libvirt driver
15:49:30 dansmith to me, our functional tests have minimal mocking so that we test large strings of nova together instead of mocking out everything above/below,
15:49:36 dansmith but they're still highly synthetic
15:49:40 sean-k-mooney mriedem: if its testing the compute manager then no. you should not need libvirt installed
15:50:36 stephenfin dansmith: Yeah, fair. Still think this is a valid fix though. Unless that particular platform couldn't even run libvirt, it's conceivable that someone using it in production would see this issue
15:51:14 dansmith stephenfin: not arguing that it's not valid
15:52:33 stephenfin "we wouldn't want a functional test to behave differently if I run it on a weird filesystem.." I figured we _would_ want it to behave differently
15:52:57 dansmith what happens if you run functional on windows?
15:53:10 sean-k-mooney stephenfin: is the filesystem logic germain to the functunality you are testing
15:53:16 stephenfin again, assuming that weird filesystem could conceivably be used in production
15:53:28 stephenfin Hmm, does libvirt work on Windows?
15:53:38 sean-k-mooney stephenfin: it can manage hyperv
15:53:44 stephenfin If not, these whole things should be marked with skipIf
15:53:55 sean-k-mooney stephenfin: not sure if it runs on windows in that case
15:53:59 dansmith stephenfin: is this using real libvirt? if not, then I'm not sure why that matters
15:54:14 stephenfin sean-k-mooney: Correction. Does nova+libvirt work on Windows?
15:55:17 sean-k-mooney stephenfin: its not support but it would proably run
15:55:43 dansmith stephenfin: are you saying that people shouldn't be able to run nova unit and functional tests of the libvirt driver on windows?
15:55:56 dansmith or any other platform where libvirt doesn't exist or is hard to get a dev environment for?
15:56:03 mriedem so i'm mostly just interested in finding out what regressed on friday
15:56:07 stephenfin dansmith: I think I am
15:56:10 stephenfin :)
15:56:11 mriedem looks like oslo.privsep 1.29 was released on thursday
15:56:16 stephenfin But I'm probably wrong
15:56:17 sean-k-mooney dansmith: well i dont think you should be able to run fuctional tests of the libvirt dirvier without libvirt.
15:56:20 mriedem so could have been a regression or something new in the library
15:56:22 dansmith because AFAIK, we're expecting the unit and functional tests to pretty much run everywhere
15:56:40 sean-k-mooney dansmith: if you can its a unit test not a functional test
15:56:41 dansmith sean-k-mooney: all of our functional tests of the libvirt driver do not use libvirt, AFAIK
15:57:09 mriedem oh heh nevermind
15:57:13 mriedem april 23, not august 23
15:57:28 dansmith sean-k-mooney: saying it another way: I don't think any of our functional tests of the libvirt driver use libvirt
15:57:37 openstackgerrit Stephen Finucane proposed openstack/nova master: privsep: Handle ENOENT when checking for direct IO support https://review.openstack.org/596815
15:58:03 stephenfin dansmith: Yeah, they don't. We have a mock/simulator or sorts written
15:58:08 dansmith right
15:58:08 sean-k-mooney dansmith: perhaps we should not consider them libvirt driver fuctional tests then anyway i think we are ratholing
15:58:17 mriedem we used to pip install libvirt-python in our unit/functional tests,
15:58:33 mriedem but turned out that certain builds of that were reporting one version but actually built against another
15:58:42 mriedem so you'd get really weird failures, like libvirt attributes not existing
15:59:39 mriedem https://bugs.launchpad.net/nova/+bug/1414708
15:59:39 openstack Launchpad bug 1414708 in OpenStack Compute (nova) "libvirt unit tests are failing if no real libvirt installed" [Low,Fix released] - Assigned to Matt Riedemann (mriedem)
16:01:15 openstackgerrit Merged openstack/nova master: Fix create_resource_provider docstring https://review.openstack.org/595453
16:03:16 mriedem stephenfin: should probably remove that url link
16:03:33 mriedem the query is in the linked bug if people care
16:03:40 stephenfin mriedem: Fair. Sec
16:05:37 openstackgerrit Stephen Finucane proposed openstack/nova master: privsep: Handle ENOENT when checking for direct IO support https://review.openstack.org/596815
16:08:21 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Validate huge pages https://review.openstack.org/399653
16:08:22 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Further simplification of test_numa_servers https://review.openstack.org/596832
17:20:03 jaypipes mnaser: you got those to work? I still can't since my mac has py3.7
17:20:41 mnaser jaypipes: pyenv has been good to me
17:20:54 mnaser pyenv shell <version> and proceed
17:21:17 mnaser it gets a bit annoying since you got to switch back and forth a few times, and you can go back to the system one using `pyenv shell system`
17:21:34 mnaser i think you can drop a .pyenv file that makes a folder use a version specifically all the time too
17:21:44 mnaser so your shell remains using 3.7 unless you're in the nova dir for example
17:22:18 mnaser btw: we deployed rocky, it seems okay so far, i'm getting it added to nodepool (and deployed in nodepool with bfv) so i'll report if anything goes up in flames
17:23:15 sean-k-mooney mnaser: when did nodepool get bfv support?
17:23:41 mnaser sean-k-mooney: i think it's been a while
17:23:56 mnaser https://review.openstack.org/#/c/596830/
17:24:29 jaypipes mnaser: interesting. hadn't heard of pyenv. thanks!
17:24:43 sean-k-mooney jaypipes: pyenv is pretty cool
17:25:18 sean-k-mooney jaypipes: its basically the python comunityes answer to what we do with tox+pbr+requirements repo
17:25:35 sean-k-mooney or am i thinking of pipenv

Earlier   Later