Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-20
16:48:44 mriedem i.e. can't the scheduler report client just make calls to placement which is really going to be the placement fixture?
16:48:46 bauzas mriedem: because we don't have yet a real placement client
16:49:10 sdague mriedem: because we'd need to emulate *all* the details of keystone
16:49:15 sdague including the token contents
16:49:52 sdague we did the same thing on the osapi fixture
16:50:26 sdague it just feels less janky because the test code is given that client back, and it makes the calls
16:50:32 bauzas yeah I tried to use the same logic
16:50:50 sdague but here we've got a keystone validated client in between services that aren't directly being talked to by the test
16:50:57 mriedem so will this still use the resource providers in the nova_api db?
16:51:14 bauzas yeah I would have loved to see something like a faked client but I wasn't able
16:51:18 mriedem like we'll have functional tests for the scheduler that post some RPs to setup some data, and then the scheduler will run and GET them back?
16:51:30 bauzas mriedem: yup, see the top patch
16:51:34 sdague mriedem: yeh, all that linkage is there
16:51:40 bauzas eg. the server affinity ones
16:52:10 bauzas I tested that with server group test class
16:52:19 mriedem ok, it's not obvious from the server group test
16:52:37 bauzas sec, finding you the logs
16:52:41 mriedem i figured there would be a specific scheduler filter functional test that preloads (POSTs) some RPs into the placement fixture
16:52:53 mriedem and then calls the scheduler filter to get some hosts back
16:53:01 mriedem but whatever, i'm sure it was failing before you added this
16:53:29 openstackgerrit sahid proposed openstack/nova: numa: add numa constraints for emulator threads policy https://review.openstack.org/385023
16:53:32 openstackgerrit sahid proposed openstack/nova: libvirt: return a CPU overhead if isolate emulator threads requested https://review.openstack.org/385364
16:53:32 openstackgerrit sahid proposed openstack/nova: objects: add new field cpuset_reserved in NUMACell https://review.openstack.org/400874
16:53:33 openstackgerrit sahid proposed openstack/nova: numa: fit instance topology with cpus reserved onto cores https://review.openstack.org/400875
16:53:36 openstackgerrit sahid proposed openstack/nova: virt: update overhead to take into account vCPUs https://review.openstack.org/385024
16:53:40 openstackgerrit sahid proposed openstack/nova: libvirt: make emulator threads to run on the reserved pCPU https://review.openstack.org/400878
16:53:41 openstackgerrit sahid proposed openstack/nova: numa: take into account cpus reserved https://review.openstack.org/400876
16:53:42 openstackgerrit sahid proposed openstack/nova: numa: update numa usage incording the cpu reserved https://review.openstack.org/400877
16:53:47 mriedem and our fake computes in those tests are using the fake virt driver which is providing some fake resources so that the resource tracker puts that stuff into the placement service right?
16:53:59 bauzas mriedem: lemme verify
16:54:12 mriedem i wonder if we'll have a race there...
16:54:35 mriedem because i'm not sure that starting the nova-compute service is blocking on doing update_available_resource
16:54:37 mriedem in the RT
16:55:06 bauzas yeah, sec
16:55:08 bauzas pasting it
16:55:23 bauzas because the functional test job is not yet done
16:55:40 sdague mriedem: that I don't know, I do know that conceptually this fixture means you can run the in process test cloud with placement so you can start exploring this space
16:55:40 bauzas mriedem: http://paste.openstack.org/show/595821/
16:56:04 bauzas mriedem: L41 of that paste
16:56:16 bauzas and L37
16:56:38 robcresswell o/ hey folks we've reached this cycles "horizon and novaclient are broken again" time. What are we usupposed to be using instead of absolute limits?
16:57:00 bauzas we still get an error because of the microversion problem
16:57:14 mriedem bauzas: ok cool
16:57:18 bauzas but the computes are correctly updating the Placement service AFAICS
16:57:23 bauzas unless I missed something
16:57:43 mriedem robcresswell: more context would be good
16:57:53 mriedem what microversion are you breaking on?
16:58:20 bauzas mriedem: the fact that the get method is not asking for 1.4
16:58:28 robcresswell mriedem: We don't use them, so 2.1 I'd assume.
16:58:44 mriedem robcresswell: then i don't know why you'd be broken
16:58:46 robcresswell Its just because of the 7.0.0 release I believe
16:58:47 bauzas so when the scheduler asks for resources, the placement service says "meh, what are you asking?"
16:58:52 robcresswell oo, interesting
16:59:01 mriedem bauzas: i know
16:59:22 bauzas oh, sorry, I thought your "what microversion are you breaking on?" was related to me :)
16:59:41 bauzas anyway, back to that problem
16:59:59 mriedem nope
16:59:59 sdague robcresswell: a well formed bug is probably important here, because at this point we're just all guessing :)
17:00:15 mriedem i'm going to lunch and running errands, so be back in a couple of hours
17:00:20 robcresswell sdague: Yeah, I'll give it a go.
17:00:23 mriedem when you guys will have figured and fixed everything
17:01:54 openstackgerrit Arnaud Morin proposed openstack/nova: Set default value to HTTP_X_FORWARDED_PROTO https://review.openstack.org/423375
17:05:17 dims sdague : just 3 lines to review if you get a chance please - https://review.openstack.org/#/c/421911/
17:05:36 dims leakypipes : ^^
17:05:57 sdague dims: +2
17:06:16 dims thanks sdague !
17:06:23 bauzas Whipped
17:06:33 dims thanks bauzas !
17:06:36 leakypipes dims: done.
17:06:42 dims and leakypipes !
17:06:51 leakypipes fastest patch approval EVAH.
17:06:58 dims i know!!!!
17:07:14 bauzas leakypipes: https://review.openstack.org/#/c/423353/ in case you wanna beat my timings :)
17:07:33 leakypipes bauzas: I'm already reviewing that one :)
17:07:49 bauzas leakypipes: http://paste.openstack.org/show/595821/ for seeing the result
17:09:32 bauzas leakypipes: FWIW, I'm planning to write a specific change for https://review.openstack.org/#/c/385693/27/nova/scheduler/client/report.py
17:09:39 bauzas because it's a bug
17:10:02 leakypipes bauzas: what's a bug?
17:10:08 bauzas and we need that in order to merge the scheduler change
17:10:12 dims update for all of you - sdague, leakypipes, bauzas, mriedem_afk : am down to one flaky issue in Nova and one persistent failure in neutron in that py35/tempest job
17:10:16 bauzas leakypipes: the fact that we're stuck with 1.0
17:10:21 sdague dims: cool
17:10:30 sdague dims what is the flakey issue?
17:10:48 openstack Launchpad bug 1658148 in python-novaclient "Horizon/Nova interactions broken " [Undecided,New]
17:10:48 robcresswell sdague, mriedem_afk: https://bugs.launchpad.net/python-novaclient/+bug/1658148 Bug report so far, I'll continue to add more.
17:10:57 robcresswell Sorry for the vague title
17:11:14 leakypipes bauzas: you're saying you are pushing a patch that only adds the OpenStack-APi-Version header to the reporting client. is that correct?
17:11:17 dims sdague : tempest.api.compute.admin.test_servers.ServersAdminTestJSON.test_list_servers_by_admin_with_specified_tenant
17:11:18 leakypipes bauzas: if so, cool by me.
17:11:28 bauzas leakypipes: yup, zactly
17:11:43 leakypipes bauzas: I have separate three patches waiting each with that same code block :)
17:11:48 bauzas heh
17:11:52 bauzas and mine too
17:12:08 bauzas all my tempest jobs are red because of that
17:12:15 dims the neutron failure is tempest.api.compute.admin.test_auto_allocate_network.AutoAllocateNetworkTest.test_server_multi_create_auto_allocate for the record
17:12:31 bauzas FWIW, 7th coffee of the day
17:12:44 bauzas I'm nearly close to beat my personal record
17:13:02 bauzas still 1
17:13:11 bauzas but the day is not over
17:15:55 johnthetubaguy melwitt: I think I got my head more around the first two quota patches now

Earlier   Later