17:01:16 <sridhar_ram> #startmeeting tacker
17:01:16 <openstack> Meeting started Tue Jan  5 17:01:16 2016 UTC and is due to finish in 60 minutes.  The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:20 <openstack> The meeting name has been set to 'tacker'
17:01:27 <sridhar_ram> #topic Roll Call
17:01:31 <vishwanathj> o/
17:01:34 <sridhar_ram> who is here for tacker ?
17:01:37 <sripriya_> o/
17:01:38 <s3wong> o/
17:02:06 <sridhar_ram> vishwanathj: sripriya_: s3wong: good morning !
17:02:15 <vishwanathj> Happy new year to all the Tackers
17:02:21 <s3wong> hello all
17:02:33 <sripriya_> morning and happy new year!
17:02:35 <bobh> o/
17:03:10 <sridhar_ram> Glad to be back after a break. Happy new year to you all!
17:03:14 <sridhar_ram> lets start
17:03:22 <sridhar_ram> #topic Agenda
17:03:34 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Jan_5.2C_2016
17:03:42 <sridhar_ram> #topic Announcements
17:04:20 <sridhar_ram> Tacker mitaka mid-cycle will be held on Jan 28, 29
17:04:22 <sridhar_ram> #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/083327.html
17:04:37 <sridhar_ram> please mark you calendars and plan to attend
17:05:27 <sridhar_ram> First Liberty drop to pypi (version 0.2.0) should happen sometime this week .. just an heads up
17:05:35 <vishwanathj> Will there be an option to attend remote?
17:06:31 <sridhar_ram> vishwanathj: there are few requests so far for remote attendance option...
17:07:05 <sridhar_ram> vishwanathj: .. I plan to attend at least provide a conference bridge
17:07:22 <vishwanathj> cool...that will be awesome
17:07:49 <sridhar_ram> F2F will be preferred for all the whiteboarding :)
17:08:34 <sridhar_ram> #topic Mitaka blueprint updates
17:08:55 <sridhar_ram> lets go around for a quick status...
17:09:06 <sridhar_ram> sripriya_: any further updates on Multi-Site ?
17:09:27 <sripriya_> sridhar_ram: uploaded new version implementing the comments before the holidays
17:09:42 <sripriya_> sridhar_ram: so far not received any new comments on the spec
17:10:00 <sripriya_> sridhar_ram: also started the implementation in parallel for the spec
17:10:40 <sridhar_ram> cool.. any blockers / major issues at this point ?
17:10:59 <sripriya_> sridhar_ram: the only new update i wanted to provide was on allocating a special 'nfv' tenant to tacker users than the default 'service' tenant which is the current default behavior
17:11:43 <sripriya_> sridhar_ram: with a special user name and password to access the tenant, probaly this could evolve to more fine grained control such as multi tenancy and RBAC
17:11:56 <sripriya_> probably*
17:12:20 <sridhar_ram> sripriya_: I think it is a good idea to call out a special tenant .. even today 'service' tenant comes from devstack tacker.conf. we are indeed abusing 'service' tenant
17:12:20 <sripriya_> sridhar_ram: i plan to upload a new spec with those changes
17:12:29 <vishwanathj> can the admin not specify their own tenant instead of tacker using a service or nfv tenant?
17:12:31 <sripriya_> sridhar_ram: agree
17:13:25 <sridhar_ram> sripriya_: it make sense to tackle multi-tenancy in a follow on spec / RFE...
17:13:29 <sripriya_> vishwanathj: that can be done, but it is a bit more involved in terms of vim privileges and which users can control that
17:13:45 <sripriya_> sridhar_ram: yes
17:14:22 <vishwanathj> sripriya_ got it
17:14:38 <sripriya_> this special tenant is assumed to exist in the remote vim created by the operator on the remote site
17:15:00 <sripriya_> i plan to document this as part of the implementation
17:15:15 <sripriya_> i hope to have a WIP soon with these changes
17:15:18 <trozet> heh when I was doing the SFC demo I was wondering why the service tenant was always being used, thought it was a bug...
17:15:36 <sripriya_> trozet: no :-) thats hard coded on the tacker.conf
17:16:03 <sridhar_ram> trozet: it made sense when tacker used to be for service-vms .. but not any more for NFV scope
17:16:08 <trozet> sripriya_: shouldn't it be whatever user and tenant is calling the client? why restrict to service tenant?
17:16:13 <trozet> ok
17:16:35 <sridhar_ram> sripriya_: great progress. IMO, this spec is the only one without much dependency on others .. so get this sailing!
17:16:57 <sridhar_ram> sripriya_: anything else ?
17:17:21 <sripriya_> trozet: yes that should be the behavior, and discussed this offline with sridhar_ram, but its good to support this as part of multi tenancy in the right way
17:17:54 <sripriya_> sridhar_ram: that's it as far as updates
17:17:59 <LouisF> sridhar_ram: there is a separate service vm tenant?
17:18:48 <sridhar_ram> LouisF: no, today tacker piggyback on the "service" tenant created in OpenStack... this is the tenant different services like nova, neutron runs
17:19:12 <LouisF> sridhar_ram: ok thanks
17:20:04 <sridhar_ram> folks - please review the multi-site spec.. leave your comments / +1s / +2s .. thanks!
17:20:15 <sridhar_ram> #topic SFC updates
17:20:58 <sridhar_ram> trozet: I saw you uploaded a new version ..
17:21:09 <trozet> sridhar_ram: yeah, tried to incorporate vnffg changes
17:21:40 <sridhar_ram> trozet: I'm quite happy how it shaped..
17:21:55 <sridhar_ram> s3wong: any further thoughts from your side ?
17:21:58 <trozet> sridhar_ram: that's great to hear, the vnffg looks ok?
17:22:11 <s3wong> yes, I like that now there is only one vnffg driver
17:22:25 <s3wong> now the flow classifier is a mechanism driver
17:22:31 <sridhar_ram> trozet: vnffg nomenclature looks better
17:23:13 <s3wong> sridhar_ram, trozet: I will take one more look before putting my +2, should happen later today
17:23:35 <trozet> s3wong: thank you
17:23:41 <sridhar_ram> s3wong: sounds good! thanks!
17:23:55 <sridhar_ram> #topic TOSCA Parser
17:24:16 <sridhar_ram> bobh: please take over ..!
17:24:59 <bobh> Thanks - I think...  I have two patchsets waiting for review in tosca-parser, one allows tosca-parser to be used from a server process instead of the command-line, and the other is for the NFV changes
17:25:40 <bobh> The basic changes required for NFV Profile support should be roughly complete, but I need to format some tests and make sure it actually works with "real" examples
17:26:06 <bobh> The examples in the OASIS document aren't really useful - or particularly accurate
17:27:16 <sridhar_ram> bobh: agree, on those usefulness of OASIS spec examples.. I'm trying to fix it on that side, going to be one of my first contributions there :)
17:27:24 <bobh> If I can get the first patchset approved and released we could start using tosca-parser/heat-generator without the NFV specific changes
17:27:31 <bobh> then add in the NFV support when it is available
17:28:01 <vishwanathj> bobh do you mind sharing the link to the patchsets, thanks
17:28:02 <bobh> we will need to determine how to specify our "vdu" and "mgmt_ip" tags in official TOSCA
17:29:02 <bobh> #link https://review.openstack.org/#/c/256952/
17:29:16 <bobh> #link https://review.openstack.org/#/c/253689/
17:29:55 <bobh> There are some other issues too, like the fact that a "VDU" is defined as a "SoftwareCOmponent" that requires a Container, so you would have to specify the Compute separately from the VDU
17:30:23 <bobh> so I think this will be a progression of changes as it evolves, but we should be able to get the base support in place fairly soon
17:31:15 <sridhar_ram> bobh: yes, this was heavily discussed on the tosca wg.. SoftwareComponent vs Compute. Agree, this will be a progression as we march along..
17:32:08 <bobh> sridhar_ram: I was originally thinking that the NFV Profile would "overlay" the Simple profile, but it appears it will be more of a "mixin"
17:32:09 <sridhar_ram> bobh: any word on the dependency ? I know tbh depends on your work...
17:33:12 <bobh> sridhar_ram: I'll ping the tosca-parser reviewers this week.  I wanted to give them a day or two to get back up to speed.  If they can approve the first patchset I'll start the tacker changes to support tosca-parser/heat-translator
17:33:38 <sridhar_ram> bobh: yes, most of NFV contructs are introduced as "requirements" for a SoftwareComponent (a.k.a VDU)..apparently this makes the syntax easier (that was the reason given when I challenged them)
17:34:19 <bobh> sridhar_ram: if this is the easy version, not sure I'd want to see the complicated one...
17:34:42 <sridhar_ram> bobh: for tacker side of things .. are you planning a spec or RFE write up ?
17:35:17 <sridhar_ram> bobh: same here!
17:35:28 <bobh> I think it could be an RFE - not extensive changes in code, though specifying the vdu and mgmt_ip will need to be resolved
17:36:02 <sridhar_ram> bobh: sounds good
17:36:07 <bobh> there is no "official" way to support those tags in TOSCA Simple profile today - unless we want to create custom nodes
17:36:11 <sripriya_> sridhar_ram: bobh: just to be sure, the vim specific properties in tosca template will still be handled by tacker only right?
17:36:56 <bobh> sripriya_: yes, that's the plan.  tacker should be able to "prune" the tree generated by tosca-parser and remove the tacker-specific objects
17:37:15 <sridhar_ram> bobh: I think we need to be open for some NFV customizations of tosca-parser for Tacker needs.. we can't be restricted to Simple Profile...
17:37:46 <sripriya_> bobh: ok
17:37:53 <sridhar_ram> bobh: worst case we can create a tosca-nfv parser library that frontends tosca-parser (which is for simple-profile)
17:38:16 <sridhar_ram> bobh: .. and make tacker depend on tosca-nfv library
17:39:06 <bobh> sridhar_ram: I think the NFV extensions to tosca-parser will help with that, so then we need to decide whether to push the cusomizations into the NFV profile or generate our own node templates
17:39:37 <bobh> sridhar_ram: or maybe both
17:40:36 <sridhar_ram> bobh: for now I'm equating our customizations, particularly coming from Automatic Resource creation and enhanced VNF placement, as *the* NFV profile
17:40:51 <sridhar_ram> ... again, here our code would be bit ahead of the spec
17:41:23 <sridhar_ram> IMO only the monitoring tag and mgmt_ip will be our pure tacker customization..
17:41:46 <bobh> sridhar_ram: ok, then we should probably define them as our own node types and they can be imported from a server-side library
17:42:10 <bobh> sridhar_ram: I'll try to put together an example - maybe this needs a spec after all
17:42:23 <brucet_> bobh: Have you created a doc that maps Tosca NFV profile to Heat resources / properties yet?
17:42:34 <sridhar_ram> bobh: agree, this is significant enough .. it warrants a spec
17:42:58 <bobh> brucet_: no, I need to get started on that - I want to list them in an Etherpad so people can suggest mappings
17:43:21 <brucet_> OK. Good idea.
17:43:44 <bobh> brucet_: there may not actually be that many mappings to translate, but need to walk through them all
17:44:05 <brucet_> Doesn't everything have to translate??
17:44:36 <bobh> brucet_: well, that's a good question.  If you look at the "VNF" definition in the profile, I don't see that it translates to anything in Heat
17:45:04 <bobh> brucet_: VDU inherits from SoftwareComponent so that may be already handled
17:45:20 <brucet_> Are you envisioning that the translator does all the translation in a single pass and then does a Create-Stack?
17:46:02 <brucet_> I'm hoping that's the case.
17:46:31 <brucet_> Then someone could use either Tosca NFV templates for direct Heat templates with Tacker
17:46:41 <bobh> brucet_: as far as I can tell, the tosca-parser would take the YAML VNFD/parameters and generate a ToscaTemplate object, which can then be manipulated by Tacker as needed, then passed to heat-translator to create the stack template
17:47:09 <sridhar_ram> bobh: brucet_: this is the reason .. we need a tacker side spec :) It is a 2 step process, tacker --> tosca-parser, followed by tacker --> heat-generator
17:47:58 <brucet_> OK. Didn't know it was a 2 step process. I think a spec is needed.
17:48:24 <bobh> i'll get started on a spec this week
17:48:51 <sridhar_ram> bobh: great thanks.. meanwhile if you can unblock tbh in someway that would be great
17:49:06 <bobh> I'll see what I can do
17:49:13 <sridhar_ram> bobh: thanks!
17:49:24 <sridhar_ram> #topic Enhanced VNF Placement
17:49:47 <sridhar_ram> gongsyh: vishwanathj: any updates on this spec ?
17:50:27 <vishwanathj> I made some initial updates providing a VNFD structure with examples for CPU Pinning, Huge Pages and NUMA topology to the spec....
17:51:10 <vishwanathj> gongsyh and I had a chance to discuss my changes early today and we are both in sync and agreement with the modifications that I made...
17:51:41 <sridhar_ram> vishwanathj: great.. my understanding is this spec depends on tbh auto-resource creation ?
17:52:06 <vishwanathj> I need to add some additional text to the spec providing a brief about CPU pinning, Huge pages, NUMA topology that I will do mid this week...
17:53:15 <vishwanathj> sridhar_ram,  if we were to translate directly from the VNFD to heat resource, I am thinking if we need the dependency, but I still need to evaluate that though...
17:53:42 <sridhar_ram> vishwanathj: okay.. please evaluation on that and advice
17:53:50 <sridhar_ram> vishwanathj: anything else ?
17:54:27 <vishwanathj> nothing more....looks like gongsyh could not  make it as it is midnite there at this time
17:55:08 <sripriya_> vishwanathj: sridhar_ram: tbh is handling auto resource creation only for flavor, network and images right?
17:55:09 <sridhar_ram> yeah, we need to discuss to make this alternative tz mtg... lets discuss in the midcycle
17:55:20 <sridhar_ram> sripriya_: yes
17:55:45 <vishwanathj> I tested flavor and image creation using heat resource and it turned out to be trivial...
17:55:52 <sripriya_> i'm trying to understand the dependency here
17:56:46 <vishwanathj> but network creation could end up duplicating networks with same name and same subnet CIDR when done through Heat...looks like Neutron APIs allow creating duplicate networks with same subnet CIDR which I think is a bug
17:57:24 <sridhar_ram> sripriya_: the overarching dependency is VNF-placement (vish,yongsheng) --> auto-resource (tbh) --> tosca-parser (bobh). You are welcome to join this for your multi-site, but I'd advice against it.
17:58:23 <sridhar_ram> vishwanathj: agree, in fact, overlapping subnet range shd error out as well..
17:58:30 <sridhar_ram> folks - we are out of time
17:58:45 <sridhar_ram> lets continue the discussion in the specs...
17:58:55 <sridhar_ram> vishwanathj: thanks for the update...
17:59:04 <vishwanathj> you are welcome
17:59:22 <sridhar_ram> Overall nice progress in mitaka blueprints.. we are covering lot of ground..
17:59:35 <sripriya_> sridhar_ram: i politely decline, we dont want a cyclic dependency :-)
17:59:42 <sridhar_ram> reviewers, nfv architects here  - please continue to help!
18:00:02 <sridhar_ram> sripriya_: wise choice!
18:00:10 <sridhar_ram> #topic Open Discussion
18:00:43 <sridhar_ram> quick shout out to sripriya_: s3wong: bobh: for keeping the reviews and merges going during the holiday break!
18:00:56 <sridhar_ram> 16 patchsets merged over two week
18:00:59 <sridhar_ram> thanks folks!
18:01:06 <sridhar_ram> bye all
18:01:10 <LouisF> bye
18:01:14 <sridhar_ram> #endmeeting