05:31:16 #startmeeting tacker 05:31:17 Meeting started Wed Apr 12 05:31:16 2017 UTC and is due to finish in 60 minutes. The chair is gongysh. Information about MeetBot at http://wiki.debian.org/MeetBot. 05:31:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 05:31:20 The meeting name has been set to 'tacker' 05:31:28 o/ 05:31:35 o/ 05:31:44 hi everyone, who are you guys are here for tacker meeting? 05:31:58 yes 05:32:00 howdy all ! 05:32:08 #topic Roll Call 05:32:16 sridhar_ram, hi 05:32:16 o/ 05:32:32 o/ 05:33:03 o/ 05:33:17 how is last week? 05:33:23 are you guys happy? 05:33:25 :) 05:33:58 :) 05:34:09 hi gongysh trinaths 05:34:13 #topic tacker activity review 05:34:17 It was very hectic for me since my office product release was going since two weeks, yesterday finally we have done our product release:) 05:35:09 http://stackalytics.com/?metric=marks&module=tacker-group 05:35:13 trinaths, thanks for you reviewing effort 05:35:32 diga, congratulations. 05:35:53 trinaths: great job ! 05:35:54 gongysh: still need reviews. missed my Pike-1 bug.. 05:36:14 gongysh: thanks! I can give more time to tacker now onwards :) 05:36:18 o/ 05:36:34 YanXing_an is also improving the review. 05:36:42 diga, thanks. 05:36:45 dkushwaha_, hi 05:36:50 hi 05:37:02 Abhi111, hi, welcome 05:37:13 #annoucement 05:37:25 gongysh: is successfully gamifying tacker participation :) Let's see who stays in Pike top-5 club 05:37:25 #topic http://stackalytics.com/?metric=marks&module=tacker-group 05:37:36 sorry 05:37:41 #topic annoucement 05:37:57 p1 is over 05:38:15 anyone with raas ransomeware solution ? 05:38:16 sridhar_ram, do we need to release pi package? 05:38:50 gongysh: no, we are not marked as milestone-release type project 05:39:02 Abhi111: Hi, its an Openstack-Tacker meeting. 05:39:13 ohh 05:39:13 gongysh: fyi, we are marked as release-with-intermediary .. 05:39:16 sridhar_ram, ok, we just need to move all bugs to p2, right? 05:39:55 gongysh: yes .. and in that we need to realistic .. move some low sev bugs to P3 05:40:03 *need to be 05:40:16 sridhar_ram, I have done that. all bugs not fixed in p1 are moved from p1 to p2. 05:40:41 #link https://launchpad.net/tacker/+milestone/pike-2 05:40:51 gongysh: cool, once one or two BPs merge, we need to do an "intermediary" Pike Tacker release .. 05:41:15 p2 will end at 2017-06-05 05:41:41 sridhar_ram, yes. we have some spec in review process. 05:41:47 #topic BP 05:42:13 #link https://review.openstack.org/#/q/project:openstack/tacker-specs 05:42:37 the first one is "encrypt vim credentials with barbican" 05:43:02 patch is at https://review.openstack.org/#/c/445543/ 05:43:13 Need more reviews to make it merged 05:43:34 who will help to review it? 05:43:51 YanXing_an: first of all, you need to fix syntax in this patch 05:43:57 sridhar_ram, dkushwaha_ ? 05:43:58 gongysh: i'll continue to review it .. 05:44:08 gongysh: I will do it 05:44:15 i can help review that spec. 05:44:20 sridhar_ram, dkushwaha_ thanks 05:44:33 trinaths, you too. thanks 05:44:43 Thanks all 05:45:01 YanXing_an, please actively respond to review comments and hope it will merge soon. 05:45:09 and then we can start coding. 05:45:28 gongysh, ok, i will 05:45:39 YanXing_an: all: quick note on the credentials used to review: i think credential store should be a remote service used by tacker-service .. 05:46:01 .. irrespective of which user is creating VIMs 05:46:25 sridhar_ram, cannot understand quite. 05:47:03 gongysh: will explain further.. there was a question which barbican user/pw to be used to store the creds.. is that issue resolved ? 05:47:50 sridhar_ram, I suggest to use the user's own context. 05:48:12 use the operator (who creates vim) 's context to store creds 05:48:53 YanXing_an: gongysh: okay, i think that shd work .. 05:49:08 ok 05:50:01 sridhar_ram, and for 'shared' vim, we will use rbac way to do 'part sharing' instead of 'all sharing'. 05:50:18 next topic 05:50:28 Support block storage 05:50:39 https://review.openstack.org/#/c/453442/ 05:50:49 I need more reviews and ideas to help me update the spec. 05:51:01 I will be the one core to review the spec. 05:51:22 thanks 05:51:27 sridhar_ram, I think you will be interested in it. 05:51:47 gongysh: yes, it is in my queue .. will review 05:51:55 Zhou_Zhihong: Do you have any use-case for this? 05:52:15 Zhou_Zhihong, I have give some comments on it. 05:52:16 yes, i have verifed one case 05:52:38 gongysh, yes I see. 05:52:39 gongysh: I will review the spec 05:52:49 diga, thanks 05:53:11 Tacker support in python-openstackclient 05:53:13 Zhou_Zhihong: gongysh: one general thought is, it is preferable to solve this in a non-NFV way 05:53:16 Zhou_Zhihong: Then, can you elaborate those finding too in the spec. It will give a clear idea 05:53:43 Zhou_Zhihong: gongysh: better to leverage Simple Profile instead of the NFV profile 05:54:02 regarding my spec, on OSC, replying gongysh comments, w.r.t the command names, we are following how the other modules are doing. https://review.openstack.org/#/c/455188/ .. For example, Heat https://specs.openstack.org/openstack/heat-specs/specs/mitaka/python-openstackclient.html 05:54:21 trinaths: I will 05:54:36 sridhar_ram, http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#_Toc430015836 05:54:43 sridhar_ram are you talking about this doc? 05:54:54 gongysh: exactly 05:55:30 yes, I have put this reference on the spec review. Zhou_Zhihong , please refer to it. 05:55:38 gongysh: we don't need to artificially make this NFV specific .. we shd work across the aisle in TP / HT projects to get this done 05:56:16 gongysh: we shd just have test-cases and use-case docs in tacker on how it is used for NFV purposes 05:56:45 sridhar_ram, yes 05:57:33 next topic "Tacker support in python-openstackclient" https://review.openstack.org/#/c/455188/ 05:57:39 gongysh: background, i was in ONS Summit last week .. talked to some TOSCA Data Model folks and there is preference to keep non-NFV specific things out of NFV profile 05:58:10 I have suggest to use "tacker_" as our command prefix in "OSC" 05:58:27 for example "openstack tacker_vnfd create xxxx" 05:58:28 gongysh: nope, that beats the whole idea of OSC effort 05:58:48 gongysh: but we need to align with the list of OSC commands. 05:58:53 gongysh: AFAIK, the idea is to move away from project names in the CLI 05:59:17 sridhar_ram, then what if our command conflicts with other project? 05:59:17 gongysh: .. into one common openstack level CLI namespace 05:59:19 sridhar_ram: +1 05:59:31 sridhar_ram: +1, command should be feature specific, not product specific as per the openstack standard 05:59:54 does then have 'command namespace' concept? 06:00:05 do they have 'command namespace' concept? 06:00:13 gongysh: that's why we need to put more thoughts and work w/ those teams .. 06:00:46 sridhar_ram: I have updated many commands to be specific to what Tacker really doing. 06:00:46 gongysh: again, afaik, there is just one openstack level namespace .. 06:01:10 sridhar_ram, who will help to approve the command names used across projects" 06:01:14 sridhar_ram, who will help to approve the command names used across projects? 06:01:28 trinaths: gongysh: one suggestion is to make slight nfv type prefix to those commands that could potentially conflict 06:01:44 gongysh: here is the list of OSC commands so far listed. http://paste.openstack.org/show/606214/ 06:01:59 gongysh: good question.. i don't know the answer :( 06:02:29 gongysh: atleast anne gentle (from the docs team) should help us direct to the right person 06:02:43 sridhar_ram: then it must be something like, $> tacker event-list ==> $> openstack nfv event list ?? 06:03:02 trinaths: exactly .. something like that 06:03:35 sridhar_ram, then the "nfv" is the prefix. 06:03:51 since tacker is major NFV related project using 'nfv' as prefix might not conflict other similar commands. 06:03:54 trinaths: sridhar_ram gongysh : i think we are in NFV area. Show all cmds should start with "nfv" 06:04:32 nfv vnfd xxxx, nfv nsd xxx, fv ns xxx .... 06:04:48 so even bacic ones will look like 'openstack nfv vnf create' .. ? hmm... 06:05:09 sridhar_ram: +1 this is good 06:05:15 I can go with 'nfv' name space. 06:05:35 sridhar_ram: +1, but we might not give nfv prefix for all the commands but for misc commands. 06:05:36 sridhar_ram: sounds good :) 06:05:37 it will help users to know it is from tacker. 06:05:50 sridhar_ram, gongysh some project using their project name in openstack cli. Can we use like 'openstack tacker vnf create' ? 06:06:37 trinaths: i would like that middle ground approach .. for things like vnf, vnfd, vnffg .. i don't think we need 'nfv' .. but for other like 'network-service', 'sfc', we need .. 06:06:43 dkushwaha: -1 to above approach, we should not use project name in the cli 06:06:55 trinaths: .. but now that will be inconsistent and that will be confusing as well .. hmmm 06:07:01 dkushwaha, my original idea is to user "tacker" but now I think "nfv" is better. but hope there is no resource in our tacker named 'nfv' 06:07:08 sridhar_ram: the idea can be like for those conflicting must have nfv prefix 06:07:25 dkushwaha: as sridhar_ram mentioned we should go with nfv namespace, I think that will be right approach 06:07:41 gongysh, diga make sense 06:07:43 trinaths: agree, but now we have created some inconsistency.. i would lean towards making it consistent 06:08:04 trinaths: .. even if that means making it longer 06:08:43 sridhar_ram, we cannot make sure other commands will not conflict with commands from other projects. 06:08:53 sridhar_ram: agree. then all commands will have $> openstack nfv <-commands-> 06:09:07 trinaths: yep .. 06:09:29 trinaths: let's see how this shapes in .. in your next spec revision 06:09:46 sridhar_ram: that way we can easily avoid conflicting them. 06:09:49 sridhar_ram: trinaths: gongysh : As I am implementing new API, if we need to add/remove params from API to make command consistent, we can do that now 06:10:00 sridhar_ram: agree . 06:10:23 diga: +1 please share that commit with me. 06:10:41 diga: i thought for the initial attempt .. we are not going to change API 06:10:45 ok, let revison the spec. if we cannot get the agreement, we have to vote at next meeting. 06:10:57 trinaths: I am implementing VIM API now, will share with you by friday 06:11:01 sridhar_ram: okay 06:11:16 gongysh: i think we have a general consensus here based on what we just discussed 06:11:19 sridhar_ram: got it 06:11:45 sridhar_ram: then, one doubt, can I go with ns, vnffg as they are or network-service ... 06:12:14 sridhar_ram: like, sfc 06:12:29 sridhar_ram: https://review.openstack.org/#/c/455188/6/specs/pike/python-openstackclient.rst 06:12:31 trinaths: to be 'ns' is toooo cryptic 06:12:45 sridhar_ram: okay. 06:13:01 tung_doan, when will you try to do the 'mistral workflow' for long live task? 06:13:16 sridhar_ram, ns is ns, I dont think we should make it 'network-service'. 06:13:22 gongysh: maybe this week 06:13:32 if so, we have to do nsd, vnfd, vnf the same way 06:13:46 gongysh: this is were i want to see how other projects approached their OSC efforts 06:14:23 gongysh: agree on the consistency part .. nsd vs ns 06:14:29 sridhar_ram, those way can be a reference. but not the rule. 06:14:49 gongysh: agree 06:15:07 #next topic bugs 06:15:52 Do you guys have specific bug to talk? 06:16:30 gongysh: my outstanding one, https://review.openstack.org/#/c/449956/ 06:17:00 https://review.openstack.org/#/c/451827/, need someone workflow +1 06:17:27 trinaths, it seems there is a negative test case from dkushwaha . 06:17:54 trinaths, do you have tested your patch yourself? 06:18:13 we had better use "curl" to test. 06:18:20 gongysh: yes. I have posted my comments too 06:18:45 dkushwaha: have you downloaded the complete patch and tested it. 06:18:56 python tacker client has filled some other stuff before calling the API. 06:18:57 gongysh, sridhar_ram I have tried it on my env, and it looks we can update the vnf name with already existing name. It will be better if somebody can verify it also 06:19:14 gongysh: I have tested the same test-cases dkushwahahas done. it was failure for me. 06:19:15 %s/vnf/vim 06:19:33 trinaths, ok, I will have a test. 06:19:34 trinaths, yup, I had downloaded patch 25 06:20:01 for https://review.openstack.org/#/c/451827/ 06:20:27 I think dkushwaha will be interested in it since you are doing ns with vnffg BP. 06:20:45 dkushwaha: but we are in a conflict. 06:20:47 gongysh, right, I will review it 06:21:38 #topic open discussion 06:21:44 gongysh: btw, hope you guys review my patch: https://review.openstack.org/#/c/453964/ 06:21:46 trinaths, then, it might be my env issue. If anyone can verify it, rest is fine from my side 06:22:00 dkushwaha: okay. 06:22:32 dkushwaha: i tested an vim-update patch .. update blocked for non-admin users. Is this a diff issue ? 06:22:58 I see some patches from contributors with simple typo corrections. Are such fixes valid ? 06:23:50 sridhar_ram, it looks different case. Please look into http://paste.openstack.org/show/606169/ 06:24:03 trinaths: IMO, typo fixes in docs are okay to entertain .. but not worth fixing in the code.. totaly wast of reviewers' time 06:24:21 trinaths, In my own way, I don't review with small typo fixes. 06:24:31 dkushwaha: will check 06:24:46 dkushwaha: I have done the same testing, http://paste.openstack.org/show/606185/ 06:24:52 anybody knows how to update company affiliation in gerrit ? 06:24:58 dkushwaha: but the test failed as suggested. 06:25:10 trinaths, but with end user facing doc, it is fine. 06:25:23 diga: you mean stackalytics ? 06:25:32 trinaths: YEs 06:25:51 gongysh: Agree. I have seen some fixes to http => https , actualy => actually 06:25:55 diga: push a patchset to https://github.com/openstack/stackalytics 06:26:07 sridhar_ram: okay, thank you 06:26:13 https://review.openstack.org/#/c/254618/, for example 06:26:31 diga: https://wiki.openstack.org/wiki/Stackalytics#Company_affiliation 06:26:43 trinaths: Thanks! 06:26:50 do you guys have other stuff to talk? 06:27:47 if not, we will end the meeting. and we can discuss on tacker channel. 06:28:04 have a good week. 06:28:08 #endmeeting