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