Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-20
16:20:57 bauzas sdague: I haven't changed the noauth logic because I thought we could be discussing about the direction
16:21:28 bauzas sdague: because nova doesn't create a fake token to pass up to the next middleware, it rather returns a 204 with that token so a later call could use it
16:21:37 bauzas so it basically fakes keystone
16:22:00 bauzas sdague: but in the scheduler report client, we don't have the same logic, and we just get the 204 instead
16:22:40 bauzas so, the question would be : should we do like nova and have a better client, or should we just pass the fake token upcall ?
16:22:57 bauzas I didn't want that question to be discussed while reviewing the fixture
16:30:15 dtp mriedem to submit a blueprint for pike, it sounds like i just add a link to it to the next meeting agenda?
16:30:22 pumaranikar sfinucan, https://review.openstack.org/#/c/345708/ feature classification matrix. Can you please check my comment ?
16:30:36 mriedem dtp: specless blueprint?
16:30:38 pumaranikar sfinucan, let me know if any changes required
16:30:43 dtp yeah specless
16:30:56 mriedem dtp: just target it to pike for now
16:31:01 mriedem we aren't reviewing pike bps yet
16:31:13 dtp okey dokey, thanks!
16:33:18 mfeoktistov mriedem: what do you think about https://review.openstack.org/#/c/312488/ also Virtuozzo CI ran and passed test_verify_created_server_ephemeral_disk
16:35:42 mriedem mfeoktistov: i think i have to wrap up some internal stuff today before i can get back to reviewing things upstream
16:36:01 mriedem mfeoktistov: but it was ok for the most part last i looked so i don't expect big issues
16:38:16 mriedem andreykurilin: one thing i wanted to remind you of, next thursday is the final release for novaclient for ocata
16:38:37 mriedem andreykurilin: i think we have some stuff to get released, like at least one microversion, and maybe some bug fixes
16:38:44 andreykurilin mriedem: thanks for reminding :)
16:39:15 andreykurilin mriedem: we have one critical bug fix at review. I'll try to help author to finish it asap
16:39:21 mriedem https://github.com/openstack/python-novaclient/compare/7.0.0...master
16:39:26 andreykurilin mriedem: https://review.openstack.org/#/c/419441/
16:39:31 openstackgerrit Hironori Shiina proposed openstack/nova: ironic: Add trigger crash dump support to ironic driver https://review.openstack.org/376548
16:42:18 openstackgerrit Sylvain Bauza proposed openstack/nova: WIP: Scheduler calling the Placement API https://review.openstack.org/417961
16:42:18 openstackgerrit Sylvain Bauza proposed openstack/nova: Add a PlacementFixture https://review.openstack.org/423353
16:42:44 bauzas sdague: could you please reapply your +2 ? I just add UTs for validating the fixture
16:43:10 sdague bauzas: done
16:43:12 bauzas mriedem: leakypipes: in case you wanna quickly +W it ^
16:43:24 bauzas sdague: thanks
16:43:31 bauzas now working on the microversion issue
16:43:35 bauzas leakypipes: ^
16:48:24 mriedem bauzas: sdague: why do we need to stub out the scheduler report client if we have a placement fixture?
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: objects: add new field cpuset_reserved in NUMACell https://review.openstack.org/400874
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: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 bauzas mriedem: http://paste.openstack.org/show/595821/
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: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 sdague robcresswell: a well formed bug is probably important here, because at this point we're just all guessing :)
16:59:59 mriedem nope
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

Earlier   Later