| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-20 | |||
| 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 | |
| 17:16:01 | johnthetubaguy | melwitt: added some follow up comments | |
| 17:16:35 | melwitt | johnthetubaguy: I saw, thanks, much appreciated. I replied to your one about duplicates a sec ago. I was thinking of the create_limit API when I say 'duplicates' | |
| 17:16:40 | johnthetubaguy | melwitt: I think the outstanding question in my head is a nuts edge case, delete, if you delete in the new DB, but the old one wasn't deleted, it might come back to life | |
| 17:16:47 | sdague | robcresswell: added comments to the bug, nova-api logs would be useful there for that request id | |
| 17:17:06 | sdague | the 403 makes it seem like there is something going on differently on the auth side | |
| 17:17:15 | johnthetubaguy | melwitt: I was thinking we only get duplicates from the migration | |
| 17:17:20 | melwitt | johnthetubaguy: yeah, have to think about that one more. thanks for all the good points | |
| 17:17:43 | johnthetubaguy | melwitt: no worries, this stuff really mashes your brain, somehow | |
| 17:19:12 | melwitt | johnthetubaguy: yeah. exact duplicates most likely. but I was thinking of if someone already has a 'instances' limit in the main DB, if they create an 'instances' limit before migrations were run, they would have two, one in API DB and one in main DB | |
| 17:19:59 | johnthetubaguy | melwitt: oh right, you get a "newer one" at the top | |
| 17:20:17 | melwitt | yeah. again I don't see why anyone would do that but that could happen | |
| 17:20:36 | johnthetubaguy | well, depends if you automate your user onboarding | |
| 17:20:49 | johnthetubaguy | thats probably more likely that I would like | |