08:02:52 <joehuang_> #startmeeting multisite
08:02:52 <collabot`> Meeting started Thu Dec 29 08:02:52 2016 UTC.  The chair is joehuang_. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:02:52 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:02:52 <collabot`> The meeting name has been set to 'multisite'
08:03:00 <joehuang_> everything fine
08:03:09 <joehuang_> how about you?
08:03:15 <goutham_pratapa> i am doing good :)
08:03:28 <joehuang_> that's great
08:03:56 <joehuang_> do you have topic to discuss in the meeting, we have some review offline for the patch
08:04:19 <goutham_pratapa> Yea nothing much working on the KB-client
08:04:32 <goutham_pratapa> and done with kingbird quota update as well.
08:05:12 <joehuang_> good, do you mean this patch https://review.openstack.org/#/c/411375/
08:06:14 <joehuang_> and https://review.openstack.org/#/c/414921/
08:06:25 <goutham_pratapa> no that was keypair-sync kingbird server i am talking about kingbird client https://hastebin.com/ayilonatac.sql  attached is the result locally
08:07:03 <goutham_pratapa> https://review.openstack.org/#/c/414921/ -- this is kingbird quota list which lists the global limits
08:07:43 <joehuang_> ok, one more patch which has not been submitted yet
08:07:50 <goutham_pratapa> if a tenant wants to view his global limits he can use kingbird quota list
08:08:04 <joehuang_> I have lots of patch in the review queue
08:08:19 <goutham_pratapa> if a admin wants to view other tenant details he can use kingbird quota list --tenant <tenant-id>
08:08:26 <joehuang_> yes
08:08:52 <goutham_pratapa> yea i will update the patch once we merge that i am afraid we may land in merge conflicts :P
08:09:13 <goutham_pratapa> if i push that kingbird quota update :)
08:09:33 <joehuang_> I have put +2 on this one https://review.openstack.org/#/c/415235/
08:10:05 <joehuang_> wait for Dimitri to confirm whether the patch is good enough to merge
08:10:06 <goutham_pratapa> yea that was a bug i am waiting for dimitri approval to merge it
08:10:12 <goutham_pratapa> yes..
08:10:23 <joehuang_> ok
08:10:37 <goutham_pratapa> and coming to kingbird quota sync
08:11:21 <joehuang_> good job, more and more patches
08:12:03 <goutham_pratapa> we are just returning a string "triggered quota sync for " <tenant> which is a bit tricky to show it from the KB-client side
08:12:16 <goutham_pratapa> so working on that as well.
08:12:46 <joehuang_> not clear for the end user
08:13:12 <goutham_pratapa> so how should we tackle this?
08:14:09 <goutham_pratapa> should we follow the approach we have discussed for resource-sync??
08:14:32 <goutham_pratapa> return a job-id and then tracking status with the job-id ??
08:14:47 <joehuang_> I think it'll be better
08:15:05 <goutham_pratapa> fine then i have to work on that as well..
08:15:41 <joehuang_> my concerns in the mail is that how to purge old jobs
08:15:58 <joehuang_> which is alread finished
08:16:13 <goutham_pratapa> currently i have been working on the kb-client so once we are done with the lagging part (kb-commands) then we can work on the server side code..
08:16:32 <goutham_pratapa> yea i would suggest to have the latest one . rather than having all the sync-job details..
08:16:54 <goutham_pratapa> what say?
08:18:12 <joehuang_> have you received the mail about that
08:18:30 <goutham_pratapa> we have to see how to delete the finished one's and have the latest one..
08:18:56 <joehuang_> http://paste.openstack.org/show/593579/
08:19:25 <joehuang_> if it's sync job, it's ok to wait until the result returns
08:19:40 <goutham_pratapa> yea i have recieved this..
08:19:56 <joehuang_> but if it's async job, we need job-id and feed status, and provide api to query the status
08:20:17 <goutham_pratapa> yes..
08:20:36 <joehuang_> currently keypair-sync and quota-sync are sync task, so wait for the result is ok
08:21:21 <joehuang_> we may just need to improve the result content
08:21:56 <goutham_pratapa> Yes.
08:22:12 <goutham_pratapa> it should be a async job only
08:22:47 <goutham_pratapa> in our future release it must be async after the previous meeting we have to migrate to async..
08:22:59 <goutham_pratapa> we have to discuss this with dimitri as well.
08:24:09 <joehuang_> ok, let's discuss it in next weekly meeting, Dimitri should come back then
08:24:52 <goutham_pratapa> yea
08:25:04 <goutham_pratapa> in the mean while i m plannig to have it this way
08:25:54 <joehuang_> it's up to the job's estimated duration
08:26:13 <goutham_pratapa> i mean my approach to handle the async job
08:26:28 <joehuang_> for short job, like keypair-sync/quota-sync, sync job seems to be fine
08:26:44 <joehuang_> but for long duration job, async. job should be
08:27:22 <goutham_pratapa> yess..
08:27:31 <goutham_pratapa> even i feel the same ..
08:27:48 <joehuang_> #info discuss aynch. job handling in next weekly meeting
08:28:24 <joehuang_> #info short duration job, sync job seems to be fine
08:28:41 <goutham_pratapa> i will suggest my approach off how to handle the async job please correct me if iam wrong..
08:28:59 <joehuang_> #info long duration job should be async.job
08:29:07 <joehuang_> ok
08:29:32 <goutham_pratapa> we create 2 tables say table-1 and table-2 ---
08:30:06 <goutham_pratapa> when User fires in a curl request we return a job-id and status as "Sync started" ---- this has to be stored in table-1. here job-id is the primary-key
08:30:34 <goutham_pratapa> when the control reaches the kb-Engine we change the status in table-1 to "Sync in progress"
08:31:16 <goutham_pratapa> when we create keypair in nova_v2.py we change the status based on the id (foreign key in table-2) "Region"(seperate-column which consists of all target_regions)
08:32:45 <goutham_pratapa> and the status (seperate-column of table ) where the status by default is "in progress" and once creation of keypair is done we update in table-2 as the synced
08:33:13 <goutham_pratapa> if fail we update the table-2 with sync-failed ..
08:34:24 <goutham_pratapa> while the sync job is running user can see the sync job status with the job-id just like we use "heat resource-list <stack-id>"
08:35:25 <goutham_pratapa> when the entire the job is completed we update the table-1 with job and status "synced or sync-failed"
08:35:57 <goutham_pratapa> when the entire the job is completed we update the table-1 with the help of jobid and status "synced or sync-failed" based upon the result.
08:36:50 <joehuang_> good idea
08:36:55 <goutham_pratapa> please correct me if am wrong
08:37:29 <goutham_pratapa> i am visualizing it to be some what similiar to heat stack creation and heat resource list <stack-id>
08:37:31 <joehuang_> no need to update the failed
08:37:58 <joehuang_> just judge in the response for the job status query
08:38:04 <goutham_pratapa> ok
08:38:53 <joehuang_> "synced or sync-failed" no need to update
08:39:03 <joehuang_> just update each region should be enough
08:39:18 <goutham_pratapa> ohkk
08:40:38 <joehuang_> let's discuss that with Dimitri
08:40:41 <goutham_pratapa> I will take these suggestions into consideration and proceed further,,
08:40:49 <joehuang_> in next weekly meeting
08:40:54 <goutham_pratapa> sure..
08:41:00 <joehuang_> other topics?
08:41:09 <goutham_pratapa> i have nothing more discuss..
08:41:35 <goutham_pratapa> i wish you and your family and friends a Happy and prosperous new Year ...
08:42:05 <joehuang_> happy new year!
08:42:11 <joehuang_> a better 2017
08:42:22 <goutham_pratapa> I hope you reach your milestones with ease
08:42:28 <goutham_pratapa> :()
08:42:30 <joehuang_> thank you !
08:42:31 <goutham_pratapa> :) **
08:42:32 <joehuang_> :)
08:42:41 <joehuang_> #endmeeting