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