17:01:07 <sridhar_ram> #startmeeting tacker
17:01:09 <openstack> Meeting started Tue Dec  8 17:01:07 2015 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:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:13 <openstack> The meeting name has been set to 'tacker'
17:01:19 <sridhar_ram> #topic Roll Call
17:01:22 <bobh> o/
17:01:34 <sridhar_ram> Hi Tackers -- who is here ?
17:01:38 <sridhar_ram> bobh: hi there!
17:01:44 <brucet> brucet
17:01:48 <vishwanathj> o/
17:01:59 <sripriya> hi
17:02:30 <sridhar_ram> lets start then...
17:02:34 <u_kozat> I am here also
17:02:57 <sridhar_ram> morning everyone!
17:03:22 <sridhar_ram> ... noon, or evening (depending on tz)
17:03:22 <tbh> morning sridhar_ram
17:03:30 <sridhar_ram> #topic Agenda
17:03:40 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Dec_8.2C_2015
17:03:47 <sridhar_ram> #topic Announcements
17:04:13 <sridhar_ram> We now have tacker packages in pypi...
17:04:25 <vishwanathj> cool
17:04:28 <sridhar_ram> #link  https://pypi.python.org/pypi/tacker/0.1.0
17:04:36 <sripriya> nice
17:04:37 <sridhar_ram> #link https://pypi.python.org/pypi/tacker-horizon/0.1.0
17:04:50 <sridhar_ram> #link https://pypi.python.org/pypi/python-tackerclient/0.1.0
17:05:02 <sridhar_ram> this is based of kilo release
17:05:22 <sridhar_ram> we finally got everything in place to make releases..
17:06:03 <s3wong> hello
17:06:05 <sridhar_ram> Will make a liberty release as well sometime soon..
17:06:24 <sripriya> sridhar_ram:will this be reflected in the tacker launch page also?
17:06:28 <sridhar_ram> .. we can decide on a time, perhaps mid-Dec ?
17:07:17 <sridhar_ram> sripriya: not sure, if launchpad will pick up automatically...need to check
17:07:40 <sripriya> sridhar_ram: ok thanks
17:07:50 <sridhar_ram> Folks - if you've any pending cherry picks to stable/liberty please do it now!
17:08:38 <sridhar_ram> we should decide on our release strategy ..
17:09:46 <sridhar_ram> our devstack installers can potentially use pypi based tackerclient and tacker-horizon for dependencies moving forward..
17:10:14 <sridhar_ram> any thoughts / suggestions on pypi / pkg releases ?
17:10:49 <vishwanathj> what do other projects do? like monasca, sfc
17:11:25 <s3wong> networking-sfc hasn't been released yet
17:11:26 <sridhar_ram> vishwanathj: some projects, particularly library projects like tosca-parser, make continuous releases .. every 5-6 weeks
17:11:26 <vishwanathj> trying to see if we there is a precedent and can follow best practices
17:11:50 <natarajk> sridhar_ram: I thought pypi jobs can be scheduled automatically along with releases
17:11:51 <sridhar_ram> "client" projects should also make regular releases...
17:12:07 <s3wong> but once you are tagged release: independent, you can release whenever and under whatever frequency as you want
17:12:29 <sridhar_ram> natarajk: we are not yet in governance, so release team won't do it for us.. we are on our own
17:13:19 <sridhar_ram> s3wong: we can do the same for us...
17:13:31 <s3wong> sridhar_ram: yep
17:13:47 <sridhar_ram> bottomline ... we need to move to regular client & horizon releases and tacker repo need to pull them using requirements.txt
17:14:05 <s3wong> we are NOT bounded by the half-year release cycle; even if we make it to big tent, as long as we are release:independent
17:14:14 <sridhar_ram> s3wong: true
17:14:51 <sridhar_ram> versioning wise 0.1.0 == kilo, 0.2.0 == liberty, 0.3.0 == mitaka ..
17:15:12 <sridhar_ram> .. for liberty we might do follow 0.2.1 with things like sfc
17:15:18 <sridhar_ram> *follow-on
17:15:42 <sridhar_ram> lets move on.. we can talk more on release in future mtgs
17:15:51 <sridhar_ram> #topic Mitaka Midcycle Plans
17:16:36 <sridhar_ram> with many big ticket items in flight - like sfc, enhanced vnf placement, tosca-parser, auto-resource - I thought we shd consider meeting face 2 face
17:16:56 <sridhar_ram> for a quick poll - how many of you would be interested in attending ?
17:17:11 <santoshk> sridhar_ram +1
17:17:14 <natarajk> +1
17:17:17 <sripriya> +1
17:17:21 <bobh> +1
17:17:22 <u_kozat> +1
17:17:25 <vishwanathj> +1
17:17:29 <s3wong> +1
17:17:32 <tbh> +1
17:17:44 <brucet> +1
17:17:56 <sridhar_ram> nice ...
17:18:11 <sridhar_ram> I'll send a doodle pool for some possible dates ..
17:18:42 <sridhar_ram> .. tentatively, would mid- to- 2nd half of Jan work for most of you ?
17:19:16 <bobh> yes
17:19:27 <sripriya> sridhar_ram: fine with me
17:19:32 <santoshk> +1
17:19:37 <s3wong> sounds fine --- at least for now :-)
17:19:39 <sridhar_ram> we can take this to finalize in an ML thread..
17:19:50 <tbh> sridhar_ram, yes
17:20:00 <u_kozat> I will be traveling Jan 9-16
17:20:08 <bobh> +1
17:20:45 <sridhar_ram> we need to find a way for remote attendance, without hampering the benefit of a F2F...
17:21:02 <sridhar_ram> tbh: you would need a remote dial-in ... ?
17:21:27 <tbh> sridhar_ram, yeah
17:21:51 <tbh> sridhar_ram, I need some way to connect
17:22:11 <sridhar_ram> alright.. we can decide the date/time/logistics outside this mtg.
17:22:15 <sridhar_ram> lets move on...
17:22:31 <sridhar_ram> #topic Mitaka Blueprint Updates
17:22:47 <sridhar_ram> #topic Enhanced VNF Placement (EVP)
17:23:42 <sridhar_ram> vishwanathj: and gongysh from China has come forward to get this going. I know tbh is also interested in contributing..
17:24:22 <sridhar_ram> I'm planning to host a one time adhoc / china / india friendly irc meeting on this topic..
17:24:24 <tbh> sridhar_ram, yes I want to be part of this BP
17:24:35 <sridhar_ram> it is 1am in Beijing :(
17:24:56 <sridhar_ram> tbh: sure
17:25:12 <tbh> sridhar_ram, is it possible to  have alternate timings each week
17:25:35 <tbh> like most of the other openstack projects follow to accommodate all contributors?
17:26:04 <sridhar_ram> tbh: absolutely.. lets starts with few adhoc meetings and see how it goes
17:26:16 <tbh> sridhar_ram, sure
17:26:42 <sridhar_ram> anyone here interested to discuss further on EVP ?
17:27:16 <sridhar_ram> btw EVP == numa topology awareness + cpu-pinning + pci-passthry + sr-iov...
17:28:02 <sridhar_ram> please watchout for a mtg invite and plan to attend..
17:28:08 <sridhar_ram> lets move on...
17:28:08 <brucet_> OK. brucet +1
17:28:20 <sridhar_ram> brucet_: sure, bruce
17:28:32 <sridhar_ram> #topic TOSCA parser updates
17:28:43 <sridhar_ram> bobh: any quick updates from your side ?
17:29:30 <bobh> I submitted a WIP patchset for the tosca-parser changes and created the BPs for heat-translator and tacker (I think - need to check that one)
17:29:58 <bobh> The next big hurdle is the object mappings from TOSCA NFV -> Heat in heat-translator
17:29:59 <sridhar_ram> bobh: link ?
17:30:11 <bobh> sridhar_ram: checking
17:30:35 <bobh> #link https://blueprints.launchpad.net/tacker/+spec/tosca-parser-integration
17:31:09 <bobh> #link https://blueprints.launchpad.net/heat-translator/+spec/tosca-nfv-support
17:31:36 <bobh> #link https://review.openstack.org/#/c/253689/
17:32:08 <sridhar_ram> bobh: cool.. this actually big deal, this is probably the first and only implementation of tosca-nfv profile (AFAIK)
17:32:11 <bobh> There needs to be some discussion around the specific object mappings to I'll start that conversation this week - maybe an etherpad is the best place for that
17:32:40 <bobh> sridhar_ram: probably - it's not completely implementable in it's current form
17:32:40 <sridhar_ram> bobh: etherpad is a good idea..
17:33:22 <bobh> Looking at the NFV spec has raised some questions in my mind about the Simple TOSCA spec
17:33:32 <sridhar_ram> bobh: understood, we have some mindful folks in tosca-nfv stds group (that's includes me) to incorporate our findings
17:33:39 <bobh> like why the basic Network object has IP addresses in it
17:33:53 <bobh> so it might end up triggering additional changes in the base spec if we do it right
17:34:07 <sridhar_ram> bobh:  I see..
17:34:41 <sridhar_ram> bobh: one thing, you might already know .. tosca-nfv profile is not a standalone spec as it stands. It build on top of tosca-simple profile namespace
17:34:46 <bobh> we can discuss in the etherpad and find the right solution - for now anyway
17:35:16 <bobh> right - but for example they define the "VirtualLink" as derived from Root not derived from tosca.nodes.network.Network
17:35:33 <sridhar_ram> sure, please send a ML email when you get the etherpad to going
17:35:48 <bobh> will do
17:35:55 <sridhar_ram> bobh: that VL reference is weird.. will take a look
17:36:16 <sridhar_ram> lets move on...
17:36:33 <sridhar_ram> #topic Multi-Site
17:36:41 <sridhar_ram> sripriya: please take over..
17:37:02 <vishwanathj> are multi-site and multi-vim synonymous ?
17:37:11 <sripriya> sridhar_ram: sure, multisite vim support v2 is out for review https://review.openstack.org/#/c/249085/
17:37:22 <sripriya> vishwanathj: IMHO no
17:38:13 <sridhar_ram> vishwanathj: there was bit of confusion, as multi-vim for some folks means different types of VIMs like openstack, vmware, aws
17:38:16 <vishwanathj> ok, my understanding as well was that they were not the same
17:38:43 <sripriya> vishwanathj: multi-VIM refers to types of VIMs (OpenStack, VMware, AWS, etc) where as multi-site ( multiple installations of same VIM) as i understand
17:39:22 <sripriya> sridhar_ram: one thing i wanted to discuss here was about the auto network creation in case of multisite scenario
17:39:23 <vishwanathj> sridhar_ram, sripriya, thanks for the explanation
17:39:31 <brucet> OK. Since this is multi site, did you see my comments about the potential use of Heat multi cloud?
17:39:40 <brucet> for this feature?
17:40:51 <sridhar_ram> brucet: my understand is that feature is still under development ?
17:41:01 <sripriya> brucet: heat mutlicloud is still a WIP right?
17:41:06 <sripriya> *multi
17:41:14 <brucet> The point is that you could incorporate a prive version of it into Tacker
17:41:34 <brucet> It assumes a standalone version of Heat
17:41:51 <brucet> So you could incorporate that standalone versiojn of Heat in Tacker
17:42:05 <brucet> When the feature is fully released, you could use the public version.
17:42:48 <sridhar_ram> brucet: that puts a dependency for operators to use this bleeding edge openstack feature before someone can use Tacker's multi-site
17:42:55 <brucet> Much easier than developing something new
17:43:05 <brucet> Nope
17:43:18 <brucet> The feature is extremely simple
17:44:26 <sridhar_ram> brucet: the scope of this spec is even basic than that..
17:44:31 <sripriya> brucet: i don't see any spec for the blueprint or i may be missing it. moreover it uses keystone federation (as the bp states) which needs some real effort to get it right
17:44:32 <sridhar_ram> brucet: see https://answers.launchpad.net/tacker/+question/276717
17:44:37 <brucet> If you find bugs in the feature, you can fix them in your standalone version of Heat and fold them into the version under development
17:45:09 <sridhar_ram> brucet: we need to support Tacker, sometime even on existing / operational OpenStack instances
17:45:27 <brucet> Standalone Heat in Tacker
17:45:30 <sridhar_ram> brucet: we CANNOT ask the operators to re-work their deployment at this point
17:45:44 <brucet> Works with existing OpenStack deployments
17:46:21 <sridhar_ram> brucet: have said that, we shd consider this (multi-cloud) and perhaps other things like keystone federation in follow on iterations of multi-site
17:46:49 <sridhar_ram> brucet: but it is not available now.. lets start with something that is available now and iterate
17:46:52 <brucet> But you understand my point about standalone Heat?
17:47:09 <brucet> I think a beta version is available now.
17:47:19 <sridhar_ram> brucet: can you explainn further on that ?
17:47:38 <brucet> Heat can be deployed as a standalone subsystem
17:48:07 <brucet> The multi cloud feature works with a stand alone Heat deployment
17:48:24 <brucet> You use the standalone Heat to instantiate stacks in other OpenStack clouds
17:48:48 <brucet> The standalone Heat variant could be incorporated in Tacker
17:49:06 <sripriya> brucet: this is the multi-region heat feature right?
17:49:14 <brucet> Separate from Heat in OpenStack that Tacker is running on
17:49:29 <brucet> Actually multi cloud
17:49:42 <brucet> I sent a link to the blueprint in my comment
17:50:02 <sripriya> where standalone heat can instantiate stacks in remote stacks and a single identity service is running across all sites
17:50:03 <brucet> Seems extremely simple
17:50:12 <sridhar_ram> brucet: I see. Standalone Heat talks to remote heat-engines ? or does it talk directly to remote nova/neutron ?
17:50:24 <brucet> Remote heat engines
17:50:43 <brucet> Remote heat engines instaniate stacks on remote OpenStack instances.
17:51:14 <brucet> The new multi cloud feature is based on multi region
17:51:50 <sridhar_ram> brucet: so you propose tacker --> standalone-heat --- > { remote-heat-engine-1, remote-heat-engine-2, .. }
17:51:56 <sripriya> brucet: with the requirement of keystone federation
17:52:18 <brucet> sridar: yes
17:53:07 <brucet> I think the new multi cloud fearture does not require keystone federation
17:53:48 <brucet> In any case, I think its worth looking into
17:54:12 <sridhar_ram> brucet: yes, that is an interesting feature..
17:54:38 <sridhar_ram> brucet: however lets keep in mind.  that higher order tacker user facing requirement here is .. target VIMs need to be exposed to NFV / VNF Orchestrators.
17:54:47 <sridhar_ram> brucet: .. apart from mult-site support
17:54:59 <sridhar_ram> lets continue the discussion in the spec..
17:55:04 <brucet> OK
17:55:11 <sripriya> brucet: not sure,as the BP says "Extend our existing multi-region remote stacks to multi-cloud, so that a remote stack can be created on a separate cloud with its own Keystone, provided that Keystone federation is supported between clouds."
17:55:17 <sridhar_ram> tbh: can give a quick update from your side ?
17:55:26 * sridhar_ram 5 mins mark
17:55:43 <sridhar_ram> #topic Automatic Resource Creation
17:55:45 <tbh> sridhar_ram, yeah, we have decided to create network resources on vnf-create tim
17:56:09 <tbh> sridhar_ram,  but I need some clarity on declaration of image details in TOSCA template
17:56:42 <tbh> sridhar_ram, if we use artifacts syntax, you mentioned in the comments
17:56:57 <sripriya> tbh: on the create network part, it will be good to understand its requirement in multisite use case
17:57:37 <tbh> then are we not going to support vm_image ?
17:57:50 <tbh> sripriya, sure, I will look into that direction
17:57:59 <sridhar_ram> tbh: no, we should support both for time being..
17:58:31 <sridhar_ram> tbh: leave your question in your spec.. I'll respond
17:58:32 <sripriya> tbh: thanks, you can provide your suggestions on the multisite spec as well
17:58:48 <tbh> sridhar_ram, but have concerns with artifacts syantax
17:58:53 <sridhar_ram> tacker team - pllease review https://review.openstack.org/#/c/250291/
17:59:10 <sridhar_ram> we need to land this, if possible, earlier in the Mitaka cycle
17:59:18 <tbh> sridhar_ram,  sure will update in the comments
17:59:28 <sridhar_ram> tbh: unfortunately we are out of time for today...
17:59:40 <sridhar_ram> lets continue in the gerrit
17:59:48 <sridhar_ram> #topic Open Discussion
18:00:05 <sridhar_ram> folks - watch out for an email on EVP mtg and plan to attend!
18:00:17 <sridhar_ram> that's it for today...
18:00:23 <sridhar_ram> bye
18:00:25 <s3wong> bye
18:00:26 <vishwanathj> bye
18:00:30 <sripriya> thanks bye
18:00:33 <sridhar_ram> #endmeeting