16:00:26 #startmeeting tacker 16:00:27 Meeting started Tue Dec 6 16:00:26 2016 UTC and is due to finish in 60 minutes. The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:30 The meeting name has been set to 'tacker' 16:00:39 #topic Roll Call 16:00:46 who is here for tacker meeting? 16:00:49 o/ 16:00:51 o/ 16:00:53 o/ 16:00:57 o/ 16:01:02 o/ 16:01:10 o/ 16:01:28 howdy all !! 16:01:30 o/ 16:01:40 let's start... 16:01:46 #topic Agenda 16:02:15 #info https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Dec_6th.2C_2016 16:02:40 #chair sripriya s3wong tbh bobh 16:02:41 Current chairs: bobh s3wong sridhar_ram sripriya tbh 16:02:54 * sridhar_ram notes that a lots of cores in the table! 16:03:13 #topic Announcements 16:03:34 thanks for all those who responded to the doodle poll for tacker meeting timeslot.. 16:03:46 #link http://lists.openstack.org/pipermail/openstack-dev/2016-December/108405.html 16:03:56 new time -> Wednesdays 0530 UTC 16:04:15 i understand might be challenge to some of you to attend.. 16:04:38 * sridhar_ram looks at bobh 16:04:46 * bobh was already sleeping.... 16:05:22 #info new Tacker meeting time starting next week at Wednesdays 0530 UTC 16:05:35 Next.. 16:05:46 Ocata is a short dev cycle... 16:05:54 #link https://releases.openstack.org/ocata/schedule.html 16:06:11 We only have 7 weeks left until feature freeze :( 16:06:31 we got to rush on things at flight to wrap by then... 16:07:09 this also means we need to punt some specs that are too big to fit to Pike (we can continue to the work, but will land only after Pike opens) 16:07:34 any thoughts / questions on these two annoucements ? 16:08:45 btw, the meeting next week will be in this same channel .. #openstack-meeting 16:08:49 moving on... 16:08:58 #topic dsvm gate job update 16:09:09 #link https://bugs.launchpad.net/tacker/+bug/1646807 16:09:09 Launchpad bug 1646807 in tacker "dsvm failure: devstack plugin is not enabled to reuse multiple times" [High,In progress] - Assigned to Tung Doan (tungdoan) 16:09:19 tung_doan: any update ? 16:09:33 tung_doan: my patch: tung_doan 16:09:43 tung_doan: my patch: https://review.openstack.org/#/c/404797/ 16:09:51 sridhar_ram: we have a bunch of errors with event/functions. I am still figuring out what happened to them. 16:10:20 sridhar_ram: I found a bug with unique name issue: http://logs.openstack.org/97/404797/5/check/gate-tacker-dsvm-functional-ubuntu-xenial-nv/a04da3a/console.html#_2016-12-05_03_43_13_15505 16:10:29 not sure if it impacts to others... 16:10:30 tung_doan: I see, good news that it is proceeding further from that enable_plugin issue.. 16:10:59 sridhar_ram: another question... 16:11:36 KanagarajM: is this something you can help to isolate, the issues related to eventing ? 16:12:22 tung_doan: what is your question? 16:12:25 sridhar_ram: can we we keep the same approach? 16:12:26 sridhar_ram, i have checked the logs once and every where the test cases expect an event count 1 16:12:53 and i believe that something wrong on the functionality issues , for example when we create vnfd 16:12:57 sridhar_ram: actually Murano has the same approach like us: https://review.openstack.org/#/c/404882/ 16:13:01 tung_doan: yes, we can.. no need for the trove solution as you've solved it another way (moving the source openrc line) 16:13:20 corresponding create count would be 1 but it reports 0 16:13:45 KanagarajM: I see 16:13:47 so i suspect something wrong on the create one, so i have asked tung_doan to test it locally to isolate the issue 16:13:56 tung_doan, any updates ? 16:14:13 sridhar_ram: KanagarajM: I will test locally today 16:14:43 sridhar_ram: this is a bgs related to unique name issue 16:14:49 tung_doan: in case you are not aware, make use of this script .. https://github.com/openstack/tacker/blob/master/tools/prepare_functional_test.sh 16:15:16 tung_doan: run this before running 'tox -e functional ' in your local system 16:15:17 sridhar_ram: I saw that. thanks 16:15:42 tung_doan: thanks a lot for taking this up, it is layers of errors 16:16:04 moving on 16:16:04 sridhar_ram: np 16:16:10 #topic Spec: VNF creation without VNFD onboarding 16:16:20 #link https://review.openstack.org/#/c/405381/1/specs/ocata/vnf-inline-template.rst 16:16:37 janki: can you give an update? 16:16:45 sridhar_ram, sure. 16:16:55 The spec explains almost everything 16:17:21 So what I intend to do is add an argument on CLI to specify the type of the template 16:17:51 "inline" in this case and "vnfd" when the template used is onboarded as VNFD 16:18:25 VNF DB will store the template. But the template won't be visibile to everyone 16:18:32 janki: why will you need to specify the type? 16:18:45 server will drop the template from "show vnf" output 16:18:56 janki: okay.. "inline" will carry the whole template as a json attribute ? 16:19:08 sripriya, just to differentiate between the 2 methods 16:19:16 sridhar_ram, yes, as JSON 16:19:24 I'd like to pause here for a sec... 16:19:46 quick heads up / poll for the members here, particularly the cores... 16:19:50 sripriya, and also to implement the DB logic to drop the template 16:20:37 bobh: s3wong: tbh: KanagarajM: this spec talks about creating a VNF by directly passing a VNFD template as part of the create VNF API 16:21:14 this is useful when the VNF / NS catalog is maintained in an NFVO running above tacker (imagine Open-O, Cloudify, etc) 16:21:18 sridhar_ram, i reviewed once and i liked this idea 16:22:02 KanagarajM: cool , that's exactly what i'm looking for .. whether you all see this as a useful addition 16:22:12 sounds good to me 16:22:20 How and why we are adding "private" flag to the template 16:22:36 bobh: thanks 16:22:52 tbh: fair question, now we can dig a bit on the mechanics.. 16:22:55 .. and will the "private" field apply to the templates which are onboarded using vnfd-create too 16:23:20 tbh, the flag is to be added to DB so that not authorised user cannot see the template. and no, it wont be applied to onboarded vnfd 16:24:19 I remember talking to sridhar_ram about handling the case where deployers dont want to reveal their template to others and hence the "private" flag 16:24:59 i think we no need to differentiate, from taker point of view, once its posted over POST json, let tacker store it in vnfd table and when it returns the vnf details, it would give reference to vnfd id 16:25:07 janki: and this gets applied only for inline template case 16:25:09 janki, in that case it must apply to onboarded templates too 16:25:10 janki, because the user can use tacker-nfv or open-o? 16:25:41 janki: we still have a pending work item on proper multi-tenancy 16:25:51 making vnfd as public or private would be different use case, imo 16:25:58 janki: meanwhile, my understanding is, this flag (what we call that is a diff thing) will differentiate VNFD that got onboarded vs vnfd that came in directly through a vnf-create call 16:26:05 KanagarajM, tbh the whole point here is not storing the template to DB 16:26:47 i think template is required, in case of scaling . 16:26:53 but not storing in DB will create confusion when too many vnfs are deployed and couldnot be matched with the template used. so store it on db but hide it from users 16:26:57 janki, ^^ 16:27:14 KanagarajM: yes, template in VNFD DB is required for various features to work.. including VNFFG 16:27:36 tbh: onboarded means its all available to user to view. here we dont want user to see the template 16:27:58 KanagarajM, sridhar_ram we are storing the template in DB but hiding it from user using "private" flag 16:28:09 "private" flag applies to DB. 16:28:21 NOw here, we can have 2 ways: 16:28:24 sridhar_ram, janki IMO, we no need to hide the vnfd from user as part of this blueprint. but we could add that feature to make a given vnfd is available public or only to owner, similar to glance image 16:28:30 janki: the intention is not to "hide" from a specific user .. the intention is just to differentiate onboarded VNFD vs inline VNFD 16:28:41 KanagarajM, +1 16:29:25 sridhar_ram, sripriya to differentiate between onboarded and inline, its "--template-type" argument on CLI. 16:29:36 KanagarajM: agree we don't need to hide, but the concern is .. if there are tons of inline-VNFs .. your 'show vnfd-list' will be too long 16:29:45 janki: even for inline template, you internally invoke the vnfd create and store it in db? 16:30:01 KanagarajM: we can introduce a 'show vnf-list --inline' to show them .. there is no need for hiding.. 16:30:13 sridhar_ram, I remember discussing this hiding feature long time back. so just included it here 16:31:08 sripriya, for inline, just call the tosca-parser internally. and store the template as is in VNF DB and NOT VNFD DB 16:31:09 folks - keep in mind, this inline-vnfd that sneaks into VNFD DB as part of a VNF create and it will also be "removed" after a VNF-delete 16:31:19 sridhar_ram, let us not hide, but if we want to really filter the vnfd list, we could bring up the tagging concept, and when user post via POST JSON, tacker could tag it internally 16:31:43 janki: but i believe vnfd_is in vnf sb is a foreign key of vnfd db 16:31:50 vnfd_id * 16:31:54 sridhar_ram, i agree with you on not hiding . 16:32:35 KanagarajM: ack, we can have some sort of a "filter view" to show / not show these types of VNFDs in the VNFD DB 16:32:46 sridhar_ram: i dont think there is an entry in vnfd db 16:33:03 sripriya: sorry, what you mean? 16:33:11 janki, sripriya, yeah so internally we need to invoke vnfd-create? 16:33:35 sridhar_ram: as janki mentioned, there is no vnfd create call internally for inline template 16:33:50 sridhar_Ram: so vnfd db is not touched here 16:34:04 * sridhar_ram scanning the spec quickly... 16:34:22 sripriya: ack.. 16:34:26 hmm... 16:34:35 sridhar_ram, sripriya I am thinking to store the template in VNF DB and not VNFD DB 16:35:04 janki: my concern is on the design of this spec since the backend has vnfd_id as a FK constraint in vnf table 16:35:12 many features in tacker relies on an entry in VNFD template.. they need to intercepted to handle this variation 16:35:24 janki: so this will fail on the backend when you create a uuid for vnfd and store in vnf db 16:35:38 but then since we are dropping the hiding thing and there is a foreign key constraint, we can store in vnfd db 16:35:44 sripriya, ^ 16:35:54 * sridhar_ram notes, we have 5mins left for this topic 16:35:57 sridhar_ram, sripriya , janki I was assuming if we add flag to VNFD in VNFD DB(to mean it is inline template) we can easily use the same procedure as we are using now. And when vnf-delete is carried on we can check the flag and remove the VNFD too 16:36:19 tbh: i assumed that as well ;-) 16:36:37 if we don't use vnfd table, it leads to affect the tacker model, as tacker already models vnfd and it should be followed across 16:36:51 tbh: KanagarajM ack 16:36:52 janki: any reason a solution that tbh proposes won't work ? 16:37:04 sridhar_ram, tbh it will work 16:37:34 I thought the same before, but beacuse of "hiding" thing proposed to use VNF DB 16:37:35 janki: now that we are all in the same page, any downsides to such an approach ? 16:37:52 none that I can think of currently 16:38:11 janki: okay.. 16:38:13 janki: are we going to show to a user in vnfd list if an entry is inline template or onboarded ? 16:38:14 infact this will also reduce VNF DB changes 16:38:39 sripriya, yes. 16:38:59 sripriya: we should not by default, unless there is a explicit flag asking to show inline templates 16:39:17 sridhar_ram +1 16:39:48 sridhar_ram: so list will NOT contain inline template entries right? 16:39:58 sripriya: yes 16:40:04 sridhar_ram: thanks 16:40:16 sridhar_ram, sripriya "list" must show the entry but not show the template content 16:40:29 folks / cores - please review this spec, particularly with any downsides .. 16:40:42 janki: do you think this will fit Ocata dev cycle ? 16:40:49 sridhar_ram, yes it will fit 16:40:56 sridhar_ram, sure. 16:41:10 alright, lets move on to the next topic... 16:41:10 sridhar_ram, ack 16:41:25 #topic Spec: Containerized VNFs 16:41:34 sridhar_ram, sripriya "vnf list" wont show the template content. "vnf list --flag" will show the content too 16:41:43 #link https://review.openstack.org/397233 16:41:52 again, back to janki :) 16:42:00 janki: we can take it up on gerrit 16:42:27 we discussed this in one of the meetings. Appropriate option is to use Zun 16:42:54 But I am encouraging on starting the implementation with Magnum/Kuryr and then keep on evolving later on 16:42:55 first - based on Barcelona summit, is there enough interest in this topic ? 16:43:15 sridhar_ram: yes IMO 16:43:27 sridhar_ram, yes there is. Nokia guys discussed this in kuryr design session 16:43:27 sripriya: okay.. 16:44:21 Now, my suggestion is put away all the technologies and projects names .. zun, magnum, kuryr, etc.. and think what we won't to offer to tacker users 16:44:48 I'm afraid we are starting backwards by picking the technology first and then working to see what we can do 16:44:55 to run VDU as a container instead of VM 16:44:56 i think it shd be the other way around 16:45:34 sridhar_ram: seems like that should be an attribute of the VNFD - specify container instead of image 16:45:35 janki: then, lets start by imaging a TOSCA template that describes VDUs as Container node types.. 16:45:51 tacker already supports this sridhar_ram 16:45:52 s/imaging/imagining/ 16:46:40 janki: that you mean ? this spec needs to show a sample TOSCA NFV template with containers 16:46:55 sridhar_ram, done. will do that 16:47:06 bobh: +1 16:47:42 anyone know if tosca-parser team is taking up any container node_type work ? 16:47:43 bobh, in the tosca_nfv_profile, can we specify container nodetype? 16:48:22 tbh: I think you could define your own container nodetype - I don't know that there is one pre-defined 16:48:48 sridhar_ram: I don't know of anything specific but I can see if spzala knows of anything 16:48:59 bobh: thanks.. 16:49:08 i think we need to start from there... 16:49:26 VDU node_type --> map to a container runtime definition 16:49:55 image artifact -> map to some sort of a container registry like dockerhub 16:50:25 bobh, we have customed defined type like this https://github.com/openstack/tosca-parser/blob/d59e1503cc9d3fa524f2209fdc645459f98e181a/toscaparser/tests/data/containers/test_container_docker_mysql.yaml#L20 16:50:27 CP -> map to perhaps kuryr ports ? 16:51:19 tbh: right - custom type will work but there is nothing native at this point 16:51:34 bobh, got it, thanks 16:51:38 janki: my suggestion is to first flush out the "top half" of this feature first .. the TOSCA parser, the usage flow, etc... 16:52:00 sridhar_ram, got it... 16:52:01 janki: for this exercise, don't worry what magnum / zun can or cannot do 16:52:29 sridhar_ram, yes 16:52:48 janki: sounds good.. 16:53:23 let's cook this spec a bit more... ! 16:53:40 it is an interesting area to indulge... 16:54:02 anything else in this container-vnf topic ? 16:54:30 #topic Open Discussion 16:54:44 sridhar_ram, I will update both the specs based on the discussion tomorrow morning 16:54:55 janki: sounds good 16:55:04 sridhar_ram, sripriya I also want to disucss the removal of mgmt_driver from CLI bug 16:55:18 janki: we have few mins, go ahead 16:55:28 janki: gerrit patch link? 16:55:39 so we remove passing mgmt_driver from the client and it will be fetched from the template itself right 16:55:49 sripriya, server patch is WIP not ready for review 16:55:49 sridhar_ram: it will be good if we can support container life-cycle managemnt 16:55:59 sridhar_ram: i am standing for that :) 16:56:17 tung_doan: ack! thanks for the input, it helps 16:56:24 janki: okay.yes, we need to remove sending that from cli parser as well as the API arg in vnfd 16:56:40 now, if we are getting the value from template, mgmt_driver must be a compulsory attribute in the vnfd 16:57:25 sripriya, got it. we will get it from template. and there are few templates that dont mention mgmt_driver AFAIK 16:57:39 so in case cases, the server should put "noop" by default 16:57:41 ?? 16:57:46 sridhar_ram, sripriya ^ 16:57:48 janki: it should not be exposed as an API param 16:57:56 sripriya: +1 16:58:25 sripriya, yes. I have removed it on the client side. it wont be in API anymore. 16:58:31 mgmt_driver should be removed en masse from the API / CLI 16:58:43 janki: cool 16:58:44 i was deprecated in newton 16:59:01 my query is it will be fetched internally from the template right? 16:59:04 sridhar_ram: you were deprecated? :P 16:59:28 sripriya: that will happen in the next cycle ;-) 16:59:36 janki : yes 16:59:42 alright times up... 17:00:06 i think we will miss US East coast folks in the Tacker meetings good forward.. 17:00:11 sripriya, so when the template doesnot have mgmt_driver, server should default it to noop? 17:00:20 particularly miss bobh :( 17:00:26 times up 17:00:28 sripriya, sridhar_ram link to the patch https://review.openstack.org/#/c/396245/ 17:00:41 bye guys 17:00:44 janki: lets take in the channel 17:00:51 sridhar_ram, yes 17:00:52 #endmeeting