08:02:15 #startmeeting multisite 08:02:15 Meeting started Thu Jan 19 08:02:15 2017 UTC. The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:02:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:02:15 The meeting name has been set to 'multisite' 08:03:01 hello 08:04:01 Helllo Goutham and Dimitri? 08:04:24 hi 08:04:32 hi 08:04:52 dimitri has to join i guess. 08:05:03 ok 08:05:56 i have updated the tempest test_cases with python-clients 08:06:04 i hope u saw a new commit :) 08:06:16 i mean a new patch update ***8 08:07:17 i have a doubt joe.. 08:08:05 python-kingbirdclient has not been released yet, so the import may fail 08:08:36 yess.. 08:08:39 python-kingbirdlcient needs to be released for the tempest test to run 08:08:45 yes 08:08:49 that will be done soon 08:08:59 but in delete request we cannot send body i think 08:09:29 because we use requests and in requests there is no such thing like a body which can be sent right?? 08:09:29 no body for delete request 08:09:55 empty body 08:10:43 yes which means this curl request (please visit link) "https://hastebin.com/waxekutobe.bash" cannnot be performed 08:11:38 o, for quota delete, ashish implement it that single quota object could be deleted 08:11:39 so it's ok 08:12:40 but using kingbird client we cannot send the body i think 08:12:55 should be able to do 08:13:01 i have tried and failed 08:13:30 we will be using requet.delete internally then how can we send?? 08:13:32 otherwise only part of the deletion function will be supported by kingbird client 08:13:59 hi 08:14:09 hello, Dimitri 08:14:12 actaully in nova and cinder there is a complete quota deletion for specified tenant but not a particular item deletion 08:14:15 hi dimitri 08:14:23 hi guys 08:14:55 How about the multisite deployment environment 08:15:43 it’s ready 08:16:15 the nodes have been configured 08:16:34 request access to user.opnfvericsson.se 08:16:34 you mean hardware ready of multi-region OpenStack ready? 08:17:17 not able to access the user.opnfvericsson.se 08:17:37 mr will be ready also. I’m testing the scripts. there’s been a lot of changes in openstack client which means i need to rewrite the kb install scripts as well 08:17:52 yes 08:17:53 write a jira ticket on INFRA 08:18:12 Jose will get it fixed for you in no time 08:18:29 attach your public key 08:18:39 ok 08:19:21 #info Multi Region environment ready soon 08:20:11 currently Goutham is update the tempest to use kingbirdclient, 08:20:21 but kingbirdclient has not been released yet 08:21:12 yes, I know. I will release it as soon as all the commits are in 08:21:21 Yes before dimitri releases that i would like to discuss about the single item deletion in kb-client 08:21:29 tag it with 0.0.1 08:22:02 Goutham just mentioned that deletion problem 08:22:21 yes, it is a problem :) 08:22:41 only delete all can be supported 08:23:27 even in Nova/Cinder, only delete all supported 08:23:27 so i will remove that small peice of code and then the kb-client will be ready to release .. 08:23:37 yes, we need to change that 08:23:40 good catch 08:24:29 i will make a commit very soon.. 08:24:29 #info remove item level quota deletion 08:24:59 #action release python-kingbirdclient so that kingbird tempest can use it 08:25:45 we need not change the server side code immediately. we will remove it once we are done with the keypair syncin part 08:25:47 it's very tight to add job tables 08:26:31 do you want to add that in Ocata release? 08:26:55 yes. 08:27:05 i will try hard to complete by that time.. 08:28:42 Dimitri, your ideas? 08:30:21 And I'll be on holiday from Jan 25 ~ Feb.3 08:30:58 ohh 08:31:31 Chinese spring festival 08:31:44 great.. 08:32:25 but then we have to act fast then.. writing test_cases will eb 08:32:33 What is your estimate goutham? 08:33:15 finalize the db structure and give me a 5 days time based on the progress can we decide?? 08:34:04 but i think we can do it... :) 08:34:10 you have to change the reponse for old commands, and test cases need to update too 08:34:52 yes.. 08:35:10 ok 08:35:17 there are some challenges.. 08:35:54 job_status in two tables? 08:36:30 No one is sync_status which means keypair's sync status in that particular region.. 08:36:44 and the other is entire job status 08:37:01 My idea is to extend this to multiple keypair sync as well 08:37:16 so we have to sync status in two tables.. 08:37:28 two sync_status*** 08:38:15 when the job will be purged? 08:38:26 otherwise the job table will grow bigger and bigger 08:38:36 or have to purge it manually? 08:38:47 i think it has to be purged when a user deletes it manually.. 08:39:22 a user or admin? 08:39:29 user 08:39:39 I assume that only admin can purge the finished job 08:39:57 you mean user should have to purge the job by himself 08:40:42 say if a user performed a job and he wants to view what resources he has synced in a particular job he must have the right to see.. what he has synced. 08:41:40 keeping the deletion rights only with admin i dont think its a good idea 08:42:15 so you have to provide job management interface too 08:42:37 to list old jobs, delete old jobs 08:43:36 actually i didnt get the last point 08:43:42 we will list all the jobs. 08:43:57 which are started or done by a particular user. 08:44:20 this can wait 08:44:59 job management is another feature 08:46:12 hmm 08:48:17 sorry my link was broken 08:49:01 hello, would you chair the next two weekly meetings? 08:49:16 I'll be on holiday that time 08:49:16 i was saying that job management is a different feature 08:49:28 and can be postpone to next release 08:49:36 fine 08:50:01 I’ll coordinate with goutham and if there will be the need for a meeting, I’ll call for it 08:50:13 thank you Dimitri 08:50:13 sure.. 08:50:25 So is the db structure ok to all?? 08:50:45 job_status dupplicated 08:50:50 others ok 08:51:16 one is region_sync_Status and the other is overall job_sync detail 08:51:42 in fact, job_status could be calculated through the sync_status of different region 08:51:48 as discussed my idea is to extend this to multiple keypair as well 08:51:53 no need to store it in a special field 08:52:22 multiple keypair sync as one job or multiple jobs? 08:53:02 so every keypair sync to every region status if synced then we update the row as "Success" and if failed we update the row as "failure" and then if we have one fail in that column for that job 08:53:03 the resource id is different for different keypair 08:54:17 we update the job status as failure and the user can see why sync job ha failed by using kingbird keypair-sync status which will return the details of the syncjob 08:54:38 +1 08:54:38 has failed by using ** 08:54:58 multiple keypair sync as one single job 08:56:55 ok, it can be updated if we find some issue in the code 08:57:20 yes.. 08:57:31 running out of time 08:57:55 ok then i will update status regularly then.. 08:57:56 ok, discuss as needed offline 08:58:06 via emails. 08:58:13 thank you attending the meeting 08:58:15 bye all have a good day.. 08:58:18 #endmeeting