05:30:22 <gongysh> #startmeeting tacker
05:30:24 <openstack> Meeting started Wed Apr 26 05:30:22 2017 UTC and is due to finish in 60 minutes.  The chair is gongysh. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:30:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:30:27 <openstack> The meeting name has been set to 'tacker'
05:30:40 <gongysh> hi everyone
05:30:47 <janki> o/
05:30:50 <janki> hi gongysh
05:30:54 <Zhou_Zhihong> o/
05:31:02 <gongysh> #topic roll call
05:31:03 <YanXing_an> o/
05:31:06 <trinaths1> o/
05:31:11 <tung_doan> o/
05:31:30 <sridhar_ram> o/
05:32:17 <gongysh> sridhar_ram, tung_doan trinaths1 janki Zhou_Zhihong YanXing_an hi
05:32:30 <gongysh> so we have 7 at meeting
05:32:42 <gongysh> #topic BP
05:32:47 <trinaths1> gongysh: hi
05:33:10 <gongysh> first BP is the VIM reacheability monitor
05:33:37 <gongysh> I have tried to implement it in two mistral ways.
05:33:52 <gongysh> 1 is a loop workflow
05:34:17 <gongysh> but it will create thousands of task execution in mistral db.
05:34:41 <gongysh> I am trying to modify mistral not to save task executions.
05:34:55 <gongysh> 2. is a loop task action
05:35:00 <sridhar_ram> gongysh: ideally we shd have one workflow per vim
05:35:26 <gongysh> a loop task action in a workflow.
05:35:53 <gongysh> but even if we deregister the vim, with the workflow is deleted, the action itself is still running.
05:36:12 <gongysh> mistral does not stop the action even with the task execution is deleted.
05:36:41 <gongysh> sridhar_ram, yes , the two ways are using just a workflow.
05:36:48 <tung_doan> gongysh: I heard that you need to delete workflow first?
05:37:11 <sridhar_ram> gongysh: understood, for (1) can't we delete the task-executions once it moved to completion
05:37:12 <sridhar_ram> ?
05:37:48 <sridhar_ram> gongysh: but that would be bad.. lots of chatter between tacker & mistral .. it will beat the whole point
05:37:59 <sridhar_ram> .. of introducing this feature
05:38:48 <gongysh> sridhar_ram, 1's problem is:  the loop workflow will create thousands of task executions in mistral db.
05:39:35 <gongysh> 2's problem is we will leave a loop action in mistral executor.
05:39:38 <diga> o/
05:40:14 <gongysh> #link https://bugs.launchpad.net/mistral/+bug/1685583
05:40:15 <openstack> Launchpad bug 1685583 in Mistral "action does not be deleted when workflow execution is delete" [Undecided,New]
05:41:30 <gongysh> so we have to modify mistral to allow us to use loop workflow or loop action.
05:42:41 <gongysh> our spec is at https://review.openstack.org/#/c/459520/
05:43:35 <gongysh> the code is at https://review.openstack.org/#/c/457140/
05:43:49 <tung_doan> gongysh: (1) can we have the delay between loops? By this way, mistral db could be decreased
05:45:17 <gongysh> but with the 'for ever' properties of  loop workflow, the decreased does not make much difference.
05:47:07 <gongysh> I will ask for mistral guys to look at how to let mistral not to save task executions.
05:47:26 <gongysh> ask for  -> ask
05:48:03 <sridhar_ram> gongysh: is task executions removed by the "user" ?
05:49:06 <sridhar_ram> basically, i'm curious how mistral cleans up / garbage collects finished executions
05:49:24 <gongysh> sridhar_ram,  in (1) one loop workflow will be created after one vim is registered, and the workflow related executrions ( include workflow execution,  its tasks executions) will be removed if the vim is de-registered.
05:50:28 <gongysh> but during execution, the loop workflow's task executions will be saved in mistral db.
05:50:52 <gongysh> since we are a loop workflow, it will have many many task executions in mistral db.
05:51:05 <gongysh> which will crash mistral in a long run.
05:51:24 <sridhar_ram> gongysh: looking at https://review.openstack.org/#/c/457140/5/tacker/mistral/mistralactions/ping_workflow.yaml ..  one task execution per "action: tacker.pingaction"
05:51:30 <sridhar_ram> ?
05:51:48 <sridhar_ram> .. and this accumulates overtime ?
05:51:56 <gongysh> yes.
05:52:07 <sridhar_ram> got it.. sorry i'm slow today ;-)
05:52:30 <sridhar_ram> the reason i'm asking this.. looks this is by design (from mistral perspective)
05:52:52 <gongysh> sridhar_ram, seems to be.
05:53:05 <sridhar_ram> .. they are leaving the executions for the user to get the status .. ERROR, SUCCESS, etc
05:53:25 <gongysh> sridhar_ram, right.
05:53:53 <sridhar_ram> how abt your option (2) ?
05:54:20 <sridhar_ram> one action with loop (implemented in python action code) ?
05:54:36 <gongysh> sridhar_ram, I think to modify the mistral for (1) is easier than for (2).
05:55:02 <sridhar_ram> gongysh: okay
05:55:07 <gongysh> sridhar_ram,   class PingVimAction(base.Action):
05:55:08 <gongysh> ...
05:55:08 <gongysh> def run(self):
05:55:08 <gongysh> while True:
05:55:10 <gongysh> status = self._ping()
05:55:10 <gongysh> if self.current_status != status:
05:55:12 <gongysh> self.current_status = self._update(status)
05:55:16 <gongysh> this is loop action for (2).
05:55:54 <gongysh> it is running for every in mistral executor even if we delete our vim workflow and its executions.
05:56:03 <gongysh> every -> ever.
05:56:50 <sridhar_ram> gongysh: ouch.. first they need to support such "indefinite" action before we can leverage it
05:58:05 <gongysh> ok that is for mistral actions to implement tack vim monitoring.
05:58:17 <gongysh> second bp spec
05:58:31 <gongysh> YanXing_an, do you have update for barbican integration?
05:58:56 <YanXing_an> gongysh, yes. I am writing the code
05:59:15 <gongysh> YanXing_an, great.
05:59:30 <gongysh> third spec block storage
05:59:36 <gongysh> Zhou_Zhihong, hi
05:59:38 <gongysh> do you have any update?
05:59:47 <Zhou_Zhihong> I got the review opinions. I'll use model2 and continue update the spec.
06:00:14 <Zhou_Zhihong> add new features of 'boot from volume' and 'volume delete'
06:00:17 * gongysh has to speed up to avoid sridhar_ram to blabber
06:00:24 <trinaths1> :)
06:00:34 <sridhar_ram> you've been warned !
06:00:47 <gongysh> Zhou_Zhihong, ok, thanks
06:01:22 <gongysh> seems the NS with vnffg team is not here.
06:01:52 <gongysh> so the OSC commands
06:01:57 <trinaths1> hi
06:02:07 <trinaths1> https://review.openstack.org/#/c/455188/
06:02:35 <gongysh> openstack vim create/delete/list/show
06:02:36 <gongysh> openstack ns create/delete/list/show
06:02:37 <gongysh> openstack ns descriptor create/delete/list/show
06:02:37 <gongysh> openstack ns descriptor template show
06:02:40 <gongysh> openstack vnf create/delete/list/show
06:02:41 <gongysh> openstack vnf descriptor create/delete/list/show
06:02:41 <gongysh> openstack vnf descriptor template show
06:02:41 <gongysh> openstack vnf graph create/delete/list/show
06:02:42 <gongysh> openstack vnf graph descriptor create/delete/list/show
06:02:42 <gongysh> openstack vnf graph descriptor template show
06:02:44 <gongysh> openstack vnf chain/classifier show/list
06:02:44 <gongysh> openstack vnf network forwarding path list
06:02:46 <gongysh> openstack nfv event list
06:02:46 <gongysh> openstack nfv extension list
06:02:48 <gongysh> this is my list of commands
06:03:30 <trinaths1> this list looks good to me. Any other suggestions.
06:03:59 <sridhar_ram> let's proceed with this ..
06:04:45 <sridhar_ram> .. we might get pulled for using acronyms "vnf" and "ns" .. we can blame ETSI NFV for that
06:04:59 <trinaths1> okay. I will update the spec.
06:05:06 <trinaths1> sridhar_ram: ;)
06:05:22 <gongysh> sridhar_ram, that's our root. we can blame ETSI NFV.
06:05:46 <gongysh> ok. lets go with this list.
06:05:48 <sridhar_ram> gongysh: we can easily get way for vnf .. ns will be little tough .. let's see
06:06:06 <gongysh> #topic bug
06:06:26 * sridhar_ram is bailing as promised ...
06:06:42 <sridhar_ram> sorry folks, need to leave ..
06:06:50 <trinaths1> sridhar_ram: also promised a party
06:07:03 * gongysh is worrying about sridhar_ram  into blabber mode.
06:07:03 <sridhar_ram> trinaths1: in syndey
06:07:15 <trinaths1> sridhar_ram: :(
06:07:21 <sridhar_ram> gongysh: i won't.. pls continue
06:07:31 <gongysh> https://review.openstack.org/#/c/451827/
06:07:47 <gongysh> vnffg paramters
06:08:07 <trinaths1> gongysh: I have 2 issues/bugs to discuss with you regarding deep_update
06:08:20 <trinaths1> gongysh: I'm okay after this meeting too
06:08:22 <gongysh> trinaths1,  are you interested in testing https://review.openstack.org/#/c/451827/
06:09:02 <trinaths1> gongysh: yes. I need testing steps the author followed.'
06:09:47 <gongysh> trinaths1, ok, please ask on the review site.
06:10:01 <trinaths1> gongysh:  as per dharmendra comment, the fix failed. I will re-verify.
06:10:22 <gongysh> trinaths1, now it is your update-vim bug
06:10:31 <gongysh> I cannot see any update on that.
06:10:52 <gongysh> https://review.openstack.org/#/c/449956/
06:10:52 <trinaths1> gongysh: was working on this. will post a fresh commit today EOD>
06:11:06 <trinaths1> gongysh:  was also waiting for any other reviewer comments
06:11:16 <gongysh> #topic open discussion
06:11:28 <gongysh> one is boston meeting
06:11:41 <gongysh> we will have a on-boarding forum
06:11:59 <gongysh> to introduce tacker for openstack developers
06:12:23 <gongysh> I will be on boston summit.
06:12:32 <gongysh> sridhar_ram, will you be there?
06:13:09 <ballu_> hi all
06:13:28 <gongysh> sridhar_ram, are you awake?
06:14:16 <gongysh> ok
06:14:29 <gongysh> do you have any items to talk about?
06:14:29 <trinaths1> gongysh: regarding deep_update, http://git.openstack.org/cgit/openstack/tacker/tree/tacker/common/utils.py#n206 , it was used at 2 places http://git.openstack.org/cgit/openstack/tacker/tree/tacker/nfvo/nfvo_plugin.py#n144  and http://git.openstack.org/cgit/openstack/tacker/tree/tacker/vnfm/infra_drivers/openstack/openstack.py#n213  and redefined at another place. http://git.openstack.org/cgit/openstack/tacker/tree/tac
06:14:30 <trinaths1> ker/vnfm/infra_d
06:14:53 <trinaths1> gongysh: de we need to remove it or do we need to have it ?
06:15:19 <trinaths1> gongysh:  two implementations for deep_update
06:15:28 <trinaths1> gongysh:  1 at http://git.openstack.org/cgit/openstack/tacker/tree/tacker/common/utils.py#n206
06:15:34 <trinaths1> gongysh:   2 at http://git.openstack.org/cgit/openstack/tacker/tree/tacker/vnfm/infra_drivers/openstack/openstack.py#n213
06:15:36 <gongysh> trinaths1, it is not a must to remove it. you can see if it will make your code cleaner if we don't use it.
06:15:41 <trinaths1> gongysh:  do we require 2 implemtation for 1 function ?
06:16:06 <trinaths1> gongysh: there are 2 places where deep_update is used in overall code.
06:16:19 <trinaths1> gongysh: also, its defined completely two times?
06:16:39 <gongysh> trinaths1, you can try first on vim update feature, if it will make your code cleaner, you can remove it in later refactor codes.
06:16:46 <gongysh> if not, we can still use it.
06:17:49 <trinaths1> gongysh: okay I agree. but still deep_update is defined two times.
06:18:06 <trinaths1> gongysh: we use one implemenation from utils.py
06:18:13 <trinaths1> gongysh: rather than re-defining them
06:18:47 <gongysh> trinaths1, you even can do refactor first to merge the two definition.
06:19:08 <trinaths1> gongysh: confused. :(
06:19:48 <gongysh> trinaths1, you said 'its defined completely two times'
06:20:14 <gongysh> trinaths1, let's move this to tacker channel.
06:20:27 <trinaths1> gongysh: okay.
06:20:49 <gongysh> what else to discuss?
06:21:16 <tung_doan> gongysh: I hope your suggestion in this patch: https://review.openstack.org/#/c/453964/
06:21:48 <gongysh> tung_doan, ok
06:21:57 <tung_doan> gongysh: what option to replace "policy_driver"? it is "action_driver"? I hope to wrap it soon. thanks
06:22:30 <ballu_> anyone can help on aodh here ?
06:22:44 <gongysh> tung_doan, Let me think it again
06:22:52 <gongysh> ballu_, this a tacker meeting. thanks
06:23:01 <ballu_> oh ok
06:23:02 <tung_doan> gongysh: sure. thanks :)
06:23:04 <ballu_> thanks
06:23:48 <gongysh> if nothing else, we will end meeting earlier.
06:24:01 <gongysh> thanks everyone
06:24:07 <gongysh> #endmeeting