07:10:33 #startmeeting multisite 07:10:33 Meeting started Thu Aug 4 07:10:33 2016 UTC. The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:10:33 Useful Commands: #action #agreed #help #info #idea #link #topic. 07:10:33 The meeting name has been set to 'multisite' 07:10:44 #info dimitri 07:10:51 #info joehuang 07:10:56 #info meimei 07:11:11 I talked to Ashish while ago 07:11:44 how about the functest in CI 07:11:57 Hello, Ashish 07:12:03 he is trouble-shooting the access problem 07:12:14 Hi Joe, By mistake I connected to some other group 07:12:23 yeah, Hi All 07:12:38 no problem, welcome back :) 07:12:51 we need to resolve one the access problem, then tempest can work 07:13:08 other things are happening with tempest, where we create user/project for kb 07:13:13 do you mean the 8118 port can't be accessed in the container 07:13:35 I think, the mapping from public ip to internal ip is not proper 07:13:46 192. internal Ip 07:13:52 172. is public ip 07:14:00 is this the mapping by Fuel? 07:14:09 HA in fuel 07:14:35 I have seen configuration for the mapping only in HA configuration files 07:14:39 try grepping on the ip and port number of nova 07:14:39 Is kingbird running with Nova in same node? 07:14:43 yes 07:14:51 see where it’s set and make sure that kb follows the same 07:15:03 it is same 07:15:11 start with the /etc 07:15:16 iptables/haconfigurations/kb.conf 07:15:23 all are same 07:15:26 is it only this? 07:15:38 I think so 07:15:50 I have an idea 07:15:55 okay 07:16:18 change the port of kingbird to one of other service port which works in functest 07:16:55 1 sec 07:16:56 okay 07:17:21 http://192.168.0.2:9292 07:17:25 this url is registered in keystone for glance 07:18:09 but the bind host is 192.168.0.5 07:18:15 so ours is also same 07:18:26 bind host in kb.conf is 192.168.0.5 07:18:46 url in keystone is http://192.168.0.2:8118/v1.0 07:18:49 now 07:19:21 really strange, I have no idea about Fuel's setting why. 07:19:22 from the controller glance is accessible with both the addresses 07:19:35 i mean, telnet 192.168.0.5 8774 07:19:36 works 07:19:41 telnet 192.168.0.2 8774 07:19:42 works 07:19:57 but for kingbird it doesn not, it works only with the bind host registered in kb.conf 07:20:12 not the url mentioned in keystone 07:20:20 you can use 0.0.0.0 for bind host 07:20:30 other wise I guess you can't access it 07:20:49 for 0.0.0.0 means all IP address for this host works for the service 07:21:13 in all other configurations it is the ip 07:21:36 how many ip address the host have? 07:21:40 so kept the same for kb as well 07:22:39 can Haproxy forward(load balancing) request to kingbird? 07:22:51 that is the problem I suppose 07:22:56 or haproxy drops the packet? 07:23:19 If it forwards and it is discarded at some point I am not sure 07:24:46 for kb, can you try the kb functest bypass the haproxy 07:25:11 from curl http://192.168.0.5:8118/v1.0 first 07:25:26 no 192 series is not accessible 07:25:33 Have you seen this? /etc/apache2/sites-available/25-apache_api_proxy.conf:29: AllowCONNECT 443 563 5000 6385 8000 8003 8004 8042 8080 8082 8386 8773 8774 8776 8777 9292 9494 9696 07:25:53 no 8118 port allowed! 07:26:19 to Dimitri, this may be the issue 07:27:14 Ashish, try adding 8118 to the list and restart apache. see if it fixes this 07:27:33 it does not 07:27:49 grep 8774 and add 8118 accordding 07:28:07 I feel mapping for 192.168.0.5 => 192.168.0.2 is not happening for 8118 07:29:37 as we are not able to access kb from 192.168.0.2 07:29:42 Iptable /etc/iptables/rules.v4:115:-A INPUT -p tcp -m multiport --ports 9292,9494,9191,8773 -m comment --comment "104 glance" -j ACCEPT 07:29:53 I couldn’t fined an entry for kb 07:30:08 ACCEPT tcp -- anywhere anywhere multiport ports 8118 /* 106 kingbird */ 07:30:19 root@node-4:~# iptables -L | grep 8118 07:30:41 ok, shouldn’t it be in the file? 07:31:35 also this 07:31:41 /etc/haproxy/conf.d/080-glance-api.cfg:3: bind 172.16.0.3:9292 07:31:49 /etc/haproxy/conf.d/080-glance-api.cfg:4: bind 192.168.0.2:9292 07:31:50 /etc/haproxy/conf.d/080-glance-api.cfg:10: server node-4 192.168.0.5:9292 check inter 10s fastinter 2s downinter 3s rise 3 fall 3 07:32:24 i guess this is the mapping 07:32:42 yes 07:32:50 we have file simillary 07:33:34 yes, looking at it 07:34:21 have you restared haproxy after adding the kb configuration? 07:35:04 yes 07:36:42 cat /etc/keystone/default_catalog.templates 07:36:49 weird file 07:38:46 may be it is used during deployment 07:39:02 thats it 07:43:49 ok 07:44:26 this file is used for batch endpont create 07:45:08 can the kb service pingable now from functest container? 07:45:55 no 07:46:44 it is not pingable from controller also on the other internal ip 07:46:46 BTW, the installation and configuration guide has been submitted for review, please have a look, thanks 07:46:57 this is the problem 07:47:49 yeah, will do it. Have you updated comments for the commit done is kb repo as well 07:47:52 we need to have 0.2.0 tag in kingbird after the functest works, and test cases pass 07:48:22 few of my comments are valid on https://review.openstack.org/#/c/349762/ as well 07:48:24 will do that after one is merged, so update once in kb reposity 07:48:39 okay 07:48:44 understand, so review the multisite first 07:48:53 fine 07:49:22 could you add the user guide, you have writen lots of API example, it will be easy for you 07:50:04 yeah, tell me the procedure I will do it 07:50:11 hi dimitri and meiemi, how do you think about it? 07:51:34 about what 07:52:09 tagging and user guide 07:52:47 the colorado branch is planned on Aug 15 07:53:59 I’ve prepared the milestone on the launchpad already. Including the tag that we will use in this release 07:54:00 o, one more, I mentioned in the mail, that some times the on demand sync doesn't sync immediatly 07:54:04 it will 1.0 07:54:19 trying to align with newton release cycle 07:54:32 seems a little early for 1.0 version number 07:54:41 you might have hit the time when on-demand collided with periodic 07:54:45 I don’t think so 07:54:51 we have quota management in place 07:55:03 one usecase we solve then it can be 1.0 07:55:09 the a management 07:55:14 quota management 07:55:22 this could be the first proper release 07:55:32 not reach stable yet 07:55:49 for example, 0.9 also acceptable 07:56:05 beta release 07:56:34 not been tested by user yet 07:57:43 a little worry on the lock 07:58:47 have you checked if you might have hit the time when on-demand collided with the periodic run? 07:58:58 that should not happen 07:59:03 it should not collide 07:59:20 as only in periodic sync I am acquring lock and release it 07:59:23 when kb-engine restart, often can't get the lock 07:59:30 that is because 07:59:34 the message printed 07:59:55 the earlier run has acquired and due to some error it halted 08:00:00 now the lock is there in db 08:00:08 then subsequent runs will fail 08:00:29 before releasing lock, engine is stopped 08:01:07 so next time when we start engine, db has lock acquired earlier, which will not allow to acquire and sync 08:01:09 ok, Ashish, is there any risk for you to submit the userguide and get merged before Aug.15 08:02:28 currently there are quite few projects( in one cycle), so the lock should be released soon 08:02:32 the risk is the immediate problems with testing 08:02:40 but seems it doesn't 08:02:40 you can see that there are issues 08:02:54 test is the first priority 08:03:48 I want to help, but I am not able to access the lab in intel pod 08:04:33 so Ashish and Dimitri fix the test environment issue first 08:04:47 you can help by managing the docs. If the issue persist, Ashish may not have the time to write it 08:05:11 I'll try 08:05:17 I can help with you the API structures and all 08:05:31 ok 08:05:38 thanks 08:05:40 great. I think we can close 08:05:44 #info fix the test issue first 08:05:57 #info joe help to add the userguide 08:06:21 ok, let's close, and hope the test can pass ASAP 08:06:31 #endmeeting