| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-20 | |||
| 16:19:38 | sdague | is there code exercising it somewhere? | |
| 16:19:49 | bauzas | sdague: in the top patch | |
| 16:20:03 | bauzas | sdague: I'm getting a 400 like devstack | |
| 16:20:16 | bauzas | because we're not asking for the latest microversion | |
| 16:20:22 | sdague | ok | |
| 16:20:29 | bauzas | but when tested locally, I'm able to see the REST resources correctly | |
| 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 | |