16:03:00 <sridhar_ram> #startmeeting tacker
16:03:01 <openstack> Meeting started Thu Jul  9 16:03:00 2015 UTC and is due to finish in 60 minutes.  The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:05 <openstack> The meeting name has been set to 'tacker'
16:03:30 <sridhar_ram> Agenda - #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_July_9.2C_2015
16:03:40 <sridhar_ram> #topic Announcements
16:04:19 <sridhar_ram> #info Liberty-2 deadline is  July 28th
16:04:39 <sridhar_ram> #info Summit talk deadline approaching fast - July 15th
16:05:16 <sridhar_ram> #topic Ease of Installation
16:05:27 <Rajkumar_> I've question - how to deploy VNF thru heat templates?? want to know the resource types and seems not present like OS::Tacker::Instance??
16:06:20 <sridhar_ram> Rajkumar_: Tacker doesn't have its own resource types
16:06:51 <sridhar_ram> we map to existing nova, neutron, .. resourcetypes
16:07:02 <sridhar_ram> this will evolve as we integrated with heat-translator
16:07:33 <Rajkumar_> Sridhar - it would be helpful if you could share us some samples? either in mail which i sent you guys
16:08:06 <sridhar_ram> Rajkumar_: sure, lets run thru' the Agenda first and we can get your questions. In fact many of the your are spot on and we should discuss it later in this call.
16:08:17 <sridhar_ram> *yours
16:08:23 <sridhar_ram> sripriya: can you give an quick update on devstack patch ?
16:08:30 <Rajkumar_> thanks..
16:09:13 <sripriya> sridhar_ram:sure
16:09:27 <sripriya> the devstack plugin is currently under review
16:09:37 <sripriya> https://review.openstack.org/#/c/199753/
16:09:39 <s3wong> sorry, guys... late due to traffic
16:09:46 <sridhar_ram> s3wong: hi, np
16:10:04 <sripriya> Please test the patchset and provide your feedback/comments
16:10:24 <sridhar_ram> sripriya: thanks
16:10:24 <sripriya> It also integrates tacker-horizon installation
16:10:30 <sripriya> and creating tacker networks
16:11:09 <vishwanathj> sripriya, i can test out the patchset
16:11:17 <sridhar_ram> we also need to bring heat repo w/ port_security_enabled
16:11:31 <sripriya> it include the local.conf.sample which you should use on devstack stable/kilo
16:11:41 <sridhar_ram> we need that in stable/kilo branch
16:11:48 <sripriya> vishwanathj: thanks
16:11:53 <sripriya> sridhar_ram:agree
16:11:59 <s3wong> sridhar_ram: is that patch merged (for Heat)?
16:12:04 <s3wong> (I haven't checked recently)
16:12:16 <sripriya> we need to cheery pick the patchset from master to stable/kilo
16:12:20 <sripriya> s3wong:yes
16:12:26 <sridhar_ram> s3wong: yeah, it merged
16:12:56 <s3wong> well, for tacker, since we have only tested till stable/kilo, we still need to cherry pick it
16:12:59 <sridhar_ram> any volunteers to have this cherry pick / merge to stable/kilo ?
16:13:07 <sridhar_ram> s3wong: exactly
16:13:19 <sripriya> sridhar_ram:i'm currently testing that
16:13:30 <sridhar_ram> sripriya: cool, thanks!
16:13:43 <sridhar_ram> Here is the current standing Tacker Installation guide
16:13:47 <sridhar_ram> #info https://wiki.openstack.org/wiki/Tacker/Installation
16:14:10 <sridhar_ram> sripriya: I guess you will be updating this once your patchset merges ?
16:14:21 <sripriya> yes
16:14:55 <sridhar_ram> cool.. after these efforts our repo will be on par w.r.t devstack integration .. inline w/ new best practices !
16:15:06 <sridhar_ram> sripriya: awesome effort so far
16:15:27 <sripriya> sridhar_ram: thanks, we also need to take care of updating global_requirements in our repo
16:15:57 <vishwanathj> sridhar_ram, the installation guide assumes that ovs-vsctl packages are pre-installed, is there going to be an update on what needs to be done when installing a brand new OS install
16:16:19 <sripriya> vishwanathj: that has been handled in devstack plugin
16:16:47 <sripriya> it will create the bridges only after ovs is installed
16:16:49 <sridhar_ram> sripriya: agree, devstack install shd pull required ovs pkgs
16:17:07 <vishwanathj> sripriya, ok, so the installation guide will be updated, right?
16:17:38 <sripriya> infact, I will also add Readme.md to the devstack dir. itself under tacker repo
16:17:51 <sripriya> it should be fairly simple to install tacker
16:18:06 <sridhar_ram> in general, the next thing in this space is transitioning from stable/kilo to master
16:18:11 <sripriya> with just enable_plugin tacker <github_repo> in local.conf
16:18:31 <sridhar_ram> when do you think we shd take that effort ?
16:19:09 <sridhar_ram> vishwanathj: lets wait for the new devstack plugin based installation and update the install docs as needed
16:19:26 <adityavajjha> Will there be any additional instructions for a non-devstack setup? (Plain OS install?)
16:19:27 <vishwanathj> sridhar_ram, sounds good
16:20:08 <sridhar_ram> adityavajjha: there is no official instructions planned. it is usually left as an exercise for the user :)
16:20:25 <sridhar_ram> adityavajjha: we sure can help
16:20:34 <sridhar_ram> reach out to us in the #tacker channel
16:20:38 <adityavajjha> sridhar_ram: :) okay
16:20:46 <adityavajjha> thank you
16:20:52 <sripriya> adityavajjha: i can also try to help
16:21:14 <adityavajjha> sripriya: thank you. I will reach out to you in the tacker channel
16:21:31 <sripriya> adityavajjha:sure
16:22:00 <sridhar_ram> My personal thought on stable/kilo --> master is - we could wait a bit. we spent decent amount of time in installation / setup and now we should focus on the feature set
16:22:22 <sripriya> sridhar_ram: agree
16:22:29 <sridhar_ram> anything else on installation / setup ?
16:22:53 <sridhar_ram> #topic API Transition
16:23:05 <sridhar_ram> a quick background ...
16:23:34 <sridhar_ram> in the last iteration we changed the python-tackerclient CLIs to use MANO lingo (vnf, vnfd, etc)
16:23:54 <sridhar_ram> but the Tacker APIs are still based on the servicevm
16:24:11 <sridhar_ram> we should plan to transition to that.
16:24:47 <sridhar_ram> I'd prefer to this in Liberty cycle as we can come out in a good shape
16:24:58 <sridhar_ram> *do this
16:25:38 <sridhar_ram> cing: I believe you are using Tacker API directly from your apps ?
16:25:57 <cing> <sridhar_ram>:yes
16:26:32 <sridhar_ram> Is it possible to absorb an API change at this point in your development ?
16:26:47 <cing> we use device-template, device, service-intance api
16:27:41 <sridhar_ram> Here are the two choices: (a) fork lift existing users to new API (b) leave existing API as v1 and introduce v2 based on MANO
16:27:48 <sridhar_ram> what do you all think ?
16:27:52 <cing> I do not consider for this change
16:28:06 <bobh_> I vote for v2 based on MANO
16:28:15 <vishwanathj> +1
16:28:15 <s3wong> sridhar_ram: up to user
16:28:29 <s3wong> cing: if you aren't interested on API change, then we will move to v2
16:28:45 <s3wong> cing: while still preserving v1
16:28:49 <cing> ok
16:29:03 <sridhar_ram> sure, sound good to me
16:29:30 <sripriya> b) vote for v2
16:29:39 <sridhar_ram> #info Tacker V2 API with MANO based semantics will be introduced
16:29:58 <sridhar_ram> thats unanimous ! like it :)
16:30:03 <s3wong> sridhar_ram, bobh_: going with v2 route, similar to how LBaaS v2 does it, we would need a different URL for API endpoint
16:30:13 <s3wong> for a while, they were using lbaasv2, I believe
16:30:36 <sridhar_ram> yeah, vpnaas is also at v2 and we are discussing v3
16:30:56 <sridhar_ram> we should enough boilerplate references to take up this effort
16:31:00 <s3wong> sridhar_ram: so are you doing tackerv2 then?
16:31:38 <sridhar_ram> s3wong: sure, I can take it up. I also need some help in the tempest / functional test
16:32:24 <bobh_> There is no easy way to differentiate API versions on a single endpoint?
16:32:44 <bobh_> Though I agree we need to change the endpoint from servicevm to tacker at some point anyway
16:32:45 <sridhar_ram> #action sridhar_ram will take up Tacker v2 efforts
16:33:03 <s3wong> bobh_: since all the APIs are different by naming convention, we could in theory do it directly on tacker/
16:33:16 <sripriya> sridhar_ram: please include me, i would like to help on v2 efforts
16:33:32 <s3wong> bobh_: but it would be tremendous handcuff moving forward, if we have anything that could potentially name-clash
16:33:34 <sridhar_ram> sripriya: sure thing, thanks!
16:34:05 <bobh_> ok - it has always been confusing to me - some projects use different endpoints per version and some don't
16:34:09 <sridhar_ram> bobh_: that's a good point
16:34:36 <s3wong> bobh_: API versioning is the direction OpenStack is moving toward
16:34:46 <bobh_> As a client I would prefer to look for a single endpoint and then do versioning on top of that
16:35:19 <s3wong> bobh_: that said, since we don't have much versioning for tacker v1, and that there is still user on those APIs, we have to do it via a more primitive method...
16:36:08 <s3wong> speaking of which ---- what is our endpoint now? is it servicevm or tacker?
16:36:09 <sridhar_ram> anyway, this effort will required a spec in tacker-specs
16:36:30 <bobh_> I believe it's servicevm - checking
16:36:39 <sridhar_ram> servicevm .. that's why bobh_ comment keep me thinking
16:37:08 <s3wong> bobh_, sridhar_ram: then life is easy, we can move to tacker/ without any backward compatibility issue
16:37:34 <sridhar_ram> but we need servicevm path alive as well for cing's needs
16:38:21 <s3wong> sridhar_ram: that would be fine --- we can treat servicevm/ basically as v1, just ensure it goes to the same tacker API server
16:38:38 <sridhar_ram> sure, that works for me .. lot cleaner
16:38:56 <sridhar_ram> but how this can be achieved in the code is something I'm not clear..
16:39:17 <sridhar_ram> let me & sripriya study this a big and come back to the group
16:39:21 <sridhar_ram> *bit
16:39:28 <s3wong> sridhar_ram, sripriya: given this minor fiasco --- I would recommend once we start using tacker/, let's think about versioning from day 1
16:39:37 <sridhar_ram> absolutely
16:39:59 <sridhar_ram> lets move on .. I'd like to hear out Rajkumar_
16:40:14 <sridhar_ram> #topic Health Monitoring
16:40:16 <s3wong> sridhar_ram: yeah, it would be an interesting problem to look at --- for LBaaS, they are going to two different backends
16:40:30 <Rajkumar_> Hi All.. I just sent mail with list of features set
16:40:51 <Rajkumar_> Even we can have teleconf if needed and let me know your convinient time
16:40:54 <sridhar_ram> #topic User Input
16:41:13 <s3wong> Rajkumar_: I started to briefly look at your list of requests
16:41:36 <sridhar_ram> Rajkumar_: first of thanks for the detailed gap analysis :)
16:41:36 <Rajkumar_> Thanks Stephen....
16:41:45 <sridhar_ram> really helpful ..
16:42:07 <s3wong> Rajkumar_: I would also like for you and Rakesh to prioritize which ones are more important vs others
16:42:07 <Rajkumar_> Sridhar - I would request you share us the samples to deploy VNF thru Heat templates
16:42:31 <Rajkumar_> Sure Stephen...
16:42:31 <s3wong> Rajkumar_: would like to see which ones we should put into Liberty cycle roadmap
16:43:03 <Rajkumar_> Please can we have teleconf? sometime early next week
16:43:06 <sridhar_ram> #link https://etherpad.openstack.org/p/liberty-tacker
16:43:29 <sridhar_ram> I added the request from Rajkumar_ into the liberty etherpad for reference
16:43:56 <sridhar_ram> Rajkumar_: I can share some samples
16:44:28 <Rajkumar_> Thanks Sridhar...
16:44:40 <sridhar_ram> or better yet sripriya: can you include a sample VNF in the devstack patchset ?
16:44:55 <sripriya> sridhar_ram: will do
16:45:04 <sridhar_ram> sripriya: thanks
16:45:29 <sridhar_ram> Rajkumar_: I think we need sometime to go through your inputs
16:45:44 <s3wong> sridhar_ram: +1
16:45:49 <Rajkumar_> Sure Sridhar..looking forward to it
16:45:53 <sridhar_ram> my quick thought is - the items goes into three buckets
16:45:59 <s3wong> stuff like GBP integration would be unlikely to happen during Liberty
16:46:24 <sridhar_ram> 1) few things in those request are already in line for Tacker Liberty - we can prirotize that
16:46:37 <s3wong> also there are tons of NSD related additions which we need to examine, as well as working with the TOSCA side of things...
16:46:38 <Rajkumar_> Stephen - GBP can be in low priority
16:46:39 <sridhar_ram> 2) Others like NSD are indeed in the roadmap
16:46:49 <sridhar_ram> s3wong: +1
16:47:24 <sridhar_ram> 3) there are few something totally new, like Tenant placement
16:48:46 <sridhar_ram> okay, I can give a shot in bucketizing them for the next IRC call
16:49:10 <sridhar_ram> lets move on...
16:49:16 <sridhar_ram> #topic Health Monitoring
16:49:38 <sridhar_ram> bobh_: prashantD: any update ?
16:50:19 <s3wong> sridhar_ram: prashantD is on vacation this week
16:50:33 <bobh_> I started work on the spec but haven't finished enough to publish yet - hoping to have something by Monday
16:50:49 <sridhar_ram> bobh_: sounds good, thanks!
16:50:53 <bobh_> I'm thinking it will be limited to one or two additional monitoring types for this cycle
16:51:17 <s3wong> bobh_: sure --- we shouldn't want to boil the ocean during the Liberty cycle :-)
16:51:52 <sridhar_ram> bobh_: in fact, the first order of business to make even the existing icmp into a loadable component
16:52:06 <s3wong> sridhar_ram: +1
16:52:16 <bobh_> I was also thinking about reducing the ping to one instead of the default 5
16:52:23 <bobh_> separately
16:52:37 <s3wong> bobh_: beware that the ping is running as a thread on the server now
16:52:49 <sridhar_ram> sure, infact ping monitoring driver could take an arg
16:53:13 <s3wong> bobh_: which obviously is not a scalable nor proper solution, so if we can move it away from tacker server that would be good
16:53:21 <bobh_> I need to look into how that is implemented and see if it is extensible or if we need to do something different
16:53:48 <sridhar_ram> in fact we should consider BFD for reachability check
16:53:55 <s3wong> bobh_: the code today isn't extensible at all :-)
16:54:15 <bobh_> s3wong: Away from tacker server might mean Monasca at some point :-)
16:54:45 <sridhar_ram> folks - time check, 5 mins mark
16:54:55 <s3wong> bobh_: in fact, the server reaction code (i.e. reacting to ping loss in 5 sec) is directly hooked into a method in the tacker server side
16:55:39 <sridhar_ram> lets move on..
16:55:43 <s3wong> bobh_: I would say we should first examine moving the ping code as some sort of driver, even if it still runs in server context, separating it out in the future would be easier
16:55:56 <sridhar_ram> s3wong: +1
16:56:01 <bobh_> s3wong: +1
16:56:03 <cing> for trove, guest agent report the state to server
16:56:11 <bobh_> ok, I'll take a look at it
16:56:31 <sridhar_ram> once we have the spec we can use to collect these ideas
16:56:48 <sridhar_ram> lets move on .. few quick things from me !
16:56:49 <s3wong> cing: too bad we don't really have guest agent :-)  though I am not sure it would be something to think about for at least the reference implementation for monitoring
16:57:04 <s3wong> my take is the design is up to bobh_ and prashantD
16:57:32 <sridhar_ram> #topic Bugs
16:57:52 <sridhar_ram> bobh_: Thanks for lot for knocking off some of the bugs. really appreciate it
16:58:07 <bobh_> sridhar_ram: More coming :-)
16:58:22 <sridhar_ram> bobh_: awesome!
16:58:25 <sridhar_ram> team - we need more folks helping out here. please jump in.
16:58:56 <sridhar_ram> quick update on CI testing: I'm going to add a gate job for testing beyond pep8
16:59:16 <sridhar_ram> Rajkumar_: can you team help out adding some tests ?
16:59:21 <s3wong> sridhar_ram: what are the new tests?
16:59:27 <vishwanathj> Friendly reminder: We have one minute left
16:59:39 <sridhar_ram> for now I'll just have a placeholder
16:59:49 <sridhar_ram> we need volunteers to add specific tests
17:00:00 <Rajkumar_> Yes Sridhar.. we're testing it
17:00:20 <sridhar_ram> Rajkumar_: thanks, can you also help adding testcases to Tacker code base ?
17:00:22 <Rajkumar_> I'll collate the issues/bugs and share it in mail to you all
17:00:43 <s3wong> sridhar_ram: I will still add some unit tests --- apology for delay, didn't quite make the progress I hoped for during the 4th weekend
17:00:49 <Rajkumar_> yeah.. Please let me know the procedure the log in test cases
17:01:06 <sridhar_ram> Rajkumar_: sure, can guide you
17:01:12 <sridhar_ram> folks - we are out of time
17:01:20 <sridhar_ram> #endmeeting