08:05:36 <joehuang> #startmeeting multisite
08:05:36 <collabot> Meeting started Thu Dec 22 08:05:36 2016 UTC.  The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:05:36 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:05:36 <collabot> The meeting name has been set to 'multisite'
08:05:46 <joehuang> Dimitri is on holiday now
08:05:48 <joehuang> let
08:05:55 <joehuang> let's have a short chat
08:05:56 <goutham_pratapa> yes
08:06:12 <goutham_pratapa> i have updated the patch set
08:06:13 <joehuang> I saw that you have updated the patch
08:06:27 <joehuang> but I have not reviewed that yet
08:06:31 <goutham_pratapa> yea
08:06:42 <goutham_pratapa> i will just breif through what i think
08:06:50 <joehuang> please
08:07:28 <goutham_pratapa> if a user fires keypair-sync then region must sync into the regions where keypair is not present
08:07:40 <goutham_pratapa> keypair must sync**
08:08:01 <joehuang> yes
08:08:20 <joehuang> if Force is True, override existing one
08:08:26 <goutham_pratapa> if keypair is already present then keypair sync must not be done in that region and continue with the rest
08:08:49 <goutham_pratapa> yes if force is true.
08:08:55 <joehuang> if Force is False, then skip the overlapping one, but continue for the rest
08:08:55 <goutham_pratapa> then override.
08:09:04 <goutham_pratapa> https://hastebin.com/kihaxipugo.rb
08:09:14 <goutham_pratapa> this is what i am expecting as the out put
08:09:26 <goutham_pratapa> please go through and comment :)
08:09:45 <goutham_pratapa> i mean im visualizing this as an output
08:10:03 <goutham_pratapa> #link https://hastebin.com/kihaxipugo.rb
08:10:20 <joehuang> should we let the job failed if there is overlapping one, or just skip that and still think the job is successful one?
08:10:45 <goutham_pratapa> just skip and continue with the rest ..
08:11:12 <joehuang> Do we have acommand to show the difference after sync?
08:11:24 <goutham_pratapa> we will display fail -- fail means keypair wasnot synced in that region
08:11:37 <joehuang> We may need some command to show the difference
08:12:37 <goutham_pratapa> yes
08:13:21 <joehuang> the failure could be in more detail, which keypair is overlapping in which region
08:13:46 <joehuang> but not just failed
08:14:24 <joehuang> if just failure, the end user can't understand it's all failure or just part failure
08:14:33 <goutham_pratapa> currently,while doing keypair sync.if sync in a region is a failure we are displaying that
08:14:38 <goutham_pratapa> yes i agree
08:14:52 <goutham_pratapa> but as off now we are syncing only single keypair
08:15:30 <joehuang> even for single keypair, we may let the user know the detail failure,
08:15:32 <goutham_pratapa> so if it is a failure i think it means that keypair is already present
08:15:50 <goutham_pratapa> ohkk fine actually your suggestion looks good
08:16:02 <goutham_pratapa> we will go through that only
08:16:13 <goutham_pratapa> we will go with that** only
08:16:18 <joehuang> it's async job, how do we know the failure result
08:17:06 <goutham_pratapa> currently we are doing some validation and getting the region where keypair is not present and then syncing in that particular region
08:18:16 <joehuang> yes, if the validation is done in sync way, we can report the failure
08:18:30 <joehuang> but what happened if failure happened in the async. job
08:19:20 <goutham_pratapa> actually i am thinking of that .
08:19:53 <goutham_pratapa> dimitri was suggesting multi status responses
08:20:12 <joehuang> it should like a job in the db
08:20:53 <goutham_pratapa> commit and roll back approach??
08:21:05 <joehuang> with a list of region is in processing, and marked with success if succeed in the sync, otherwise this region is stistill in processing
08:21:08 <goutham_pratapa> commit or roll-back approach?
08:21:17 <joehuang> no  roll-back needed
08:21:29 <goutham_pratapa> ohkk
08:21:38 <joehuang> just that the enduser can have a way to know the progress of the async. job
08:22:05 <joehuang> for example, if I sync the keypair to 10 regions, it's a job
08:22:28 <joehuang> during the query, may be 5 finished, 5 are processing
08:22:48 <joehuang> and next time, 8 finished, 2 are processing
08:23:01 <joehuang> at last, all finished
08:23:43 <goutham_pratapa> ohkk
08:23:59 <joehuang> so, we need to return a job handle(for example, the job id) to the end user, and end user can query the status of the
08:24:07 <joehuang> job through the handle
08:24:55 <joehuang> otherwise, we currently just use sync job in kb-api is better than to start async job and handle in kb-engine
08:25:30 <joehuang> this "sync" is not sync keypair, :)
08:25:53 <goutham_pratapa> yea i understood.
08:26:50 <joehuang> but for sync job, the end user has to wait for the response from all other regions
08:28:10 <goutham_pratapa> then it means when we create a keypair in each region then we even have to analyze the response which nova is returning
08:28:54 <goutham_pratapa> and then based on responses provided by each region we have to display output?
08:29:53 <joehuang> the user experice is not good
08:30:26 <joehuang> if some region is timeout, then the response has to wait for longtime, even other succeed
08:31:28 <goutham_pratapa> ok
08:33:06 <joehuang> in fact, each "sync keypair"(or other resource") is more like to trigger a job
08:33:23 <joehuang> may take time to finish the job
08:34:07 <joehuang> especially for time consuming sync api calling
08:34:11 <goutham_pratapa> yes i agree
08:36:05 <joehuang> if it's a job, even the validation could be put in the async job done by kb-engine
08:36:41 <goutham_pratapa> currently validation is a part of kb-engine
08:36:48 <joehuang> kb-engine to record the validation result into the job status
08:37:10 <joehuang> so that when the end user check the job, know what happened in each region
08:38:22 <goutham_pratapa> ok i will go through what i have done till now  and what has to be done ..
08:38:34 <goutham_pratapa> please correct me if i am wrong
08:38:44 <joehuang> ok, let's check the code and to see if design update is needed
08:39:48 <joehuang> so let's continue work offline
08:39:54 <goutham_pratapa> currently when user sends a curl request.. it will do basic validation like check for keypair in the api-side, bad resource_type etc..
08:40:17 <goutham_pratapa> then the request goes to the kb-engine and there
08:41:30 <goutham_pratapa> we check for keypairs in alll regions and filter out the regions where keypair is not present by creating threads for each region
08:42:52 <joehuang> use call or cast from api to engine?
08:43:16 <goutham_pratapa> we use call not cast. and once we get the list of regions (sync_regions)where keypair is not present there we create keypairs by creating multiple threads for that filtered regions
08:43:46 <goutham_pratapa> filtered-regions-- sync-regions
08:43:53 <joehuang> ok, it'ok for the keypair sync job
08:43:59 <joehuang> currently
08:44:18 <joehuang> we may introduce job for long-run task later
08:44:28 <joehuang> at least currently, call should be enough
08:44:39 <goutham_pratapa> yes,
08:45:05 <joehuang> improve step by step
08:45:11 <goutham_pratapa> yes..
08:45:21 <joehuang> ok, I'll review the patch
08:45:26 <goutham_pratapa> sure..
08:45:43 <joehuang> thank you, merry christmas
08:46:11 <goutham_pratapa> jus a sec
08:46:17 <joehuang> fortunaetly single keypair sync is a short task
08:46:19 <joehuang> please
08:46:38 <goutham_pratapa> i will even improve the way we display
08:46:45 <goutham_pratapa> the error..
08:46:54 <joehuang> cool
08:47:12 <goutham_pratapa> i mean detailed explanation of why the sync failed instead of just displaying fail
08:47:24 <joehuang> I understoo
08:47:27 <goutham_pratapa> u review the patch and drop comments
08:47:40 <joehuang> sure
08:47:57 <goutham_pratapa> i will take this its a good way of showing the output..
08:48:33 <joehuang> ok
08:48:35 <goutham_pratapa> Merry christmas.. again :)
08:48:51 <joehuang> Thanks, enjoy
08:48:59 <goutham_pratapa> bye :)
08:49:06 <joehuang> bye :)
08:49:10 <joehuang> #endmeeting