16:00:36 <sridhar_ram> #startmeeting tacker
16:00:37 <openstack> Meeting started Tue May 10 16:00:36 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:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:38 <mlavalle> johnthetubaguy: thanks!
16:00:40 <carl_baldwin> We can discuss in the Neutron room if needed.
16:00:41 <openstack> The meeting name has been set to 'tacker'
16:01:17 <sridhar_ram> #topic Roll Call
16:01:26 <vishwanathj> o/
16:01:27 <sripriya> o/
16:01:28 <sridhar_ram> who is here for tacker meeting ?
16:01:30 <tung_doan> Hi all, I am Tung Doan. I am a member of Korea-OpenNetworking Project supported by Korea IT Minster project Fund. It is nice to work with all of you!
16:01:30 <s3wong> o/
16:01:30 <michael_bredel> o/
16:01:30 <janki91> o/
16:01:32 <dkushwaha> 0/
16:01:32 <tbh> o/
16:01:32 <twm2016> o/
16:01:38 <brucet> o/
16:01:46 <s3wong> tung_doan: welcome!
16:01:49 <sridhar_ram> howdy all !
16:01:49 <tung_doan> hope you guys recognize me!
16:01:57 <brucet> I do
16:02:07 <sridhar_ram> tung_doan: welcome, welcome ... ! glad to hear from you..
16:02:08 <brucet> I need tofinish my review for you
16:02:22 <s3wong> tung_doan: sure, saw your Ceilometer -> alarm spec on gerrit
16:02:24 <sridhar_ram> tung_doan: thanks for joining at this late hr in your side..
16:02:33 <sridhar_ram> tung_doan: appreciate it..
16:02:39 <sridhar_ram> lets get started..
16:02:47 <sridhar_ram> #topic Annoucements
16:02:50 <tung_doan> s3wong: I alread saw it
16:03:15 <sridhar_ram> #info  Newton Tacker Design Summit Recap
16:03:19 <sridhar_ram> #link  http://lists.openstack.org/pipermail/openstack-dev/2016-May/094401.html
16:03:53 <sridhar_ram> #info Official Newton schedule #link http://releases.openstack.org/newton/schedule.html
16:04:33 <sridhar_ram> Agenda for today's meeting ..
16:04:39 <sridhar_ram> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_May_10.2C_2016
16:04:50 <sridhar_ram> #topic Newton Working Plan
16:05:25 <sridhar_ram> I'd like to take few mins to communicate the expectation for the Newton cycle and hear community feedback...
16:05:43 <sridhar_ram> First, thanks for all those who took time to attend the Tacker design summit...
16:05:59 <sridhar_ram> it went really well, IMO (!).. lots of lively discussions
16:06:22 <vishwanathj> +1
16:07:05 <sridhar_ram> We went into big-tent in Mitaka..
16:07:19 <sridhar_ram> .. but we got to scramble a lot to make the release deadline..
16:07:52 <sridhar_ram> so my expectation is to take to the contribution load more towards the "front end" of the dev cycle...
16:08:06 <sridhar_ram> this means we need to get the specs going ASAP..
16:08:18 <sridhar_ram> .. and land most features before Milestone-3
16:08:43 <sridhar_ram> With this in mind I'd like to propose an intermediate Newton release ..
16:09:04 <sridhar_ram> .. coinciding with Milestone 2 - July 14, 2016
16:09:27 <sridhar_ram> #link http://releases.openstack.org/newton/schedule.html#newton-2-milestone
16:10:01 <sridhar_ram> .. and a final Newton release after milestone-3
16:10:09 <sridhar_ram> what do you think ?
16:10:13 <brucet_> Dates??
16:10:38 <twm2016> Aug 29-02 is the newton milestone-3
16:10:41 <sridhar_ram> brucet_: Sept 26, 2016
16:10:55 <brucet_> OK
16:11:25 <sridhar_ram> In summary, first midpoint newton release by July 14th, second / final newton release by Sept 26th
16:11:58 <sripriya> sridhar_ram: any specific specs/features that is scoped for mid-release?
16:12:29 <sridhar_ram> sripriya: I'm looking for the community to orient themselves towards one of these two releases...
16:12:39 <sripriya> sridhar_ram: ok
16:12:47 <sridhar_ram> Ofcourse, I'd like to avoid everyone choosing Sept 26th ;-)
16:13:17 <sripriya> :)
16:13:29 <sridhar_ram> trozet: are you here ?
16:13:59 <sridhar_ram> we need to spread big features across these two milestones..
16:14:21 <sridhar_ram> I'm looking towards VNF FFG and Alaram based auto-scaling for midpoint release
16:14:23 <brucet_> Where does refactoring come in?
16:14:50 <sridhar_ram> NSD, refactoring, CSAR, etc would be in the final release
16:15:14 <twm2016> I'd like to help with some of the specs if I can, I'm new to tacker so it will take some time but I think I can at least do some of the dirty work. So maybe I can work on some of the refactoring spec.
16:15:18 <brucet_> Bobh said Tosca / Heattranslator already has basic code for autoscaling
16:15:29 <tung_doan> sridhar_ram: Thank for your interest :)
16:15:33 <brucet_> I am planning on looking into this
16:16:31 <sripriya> twm2016: i'm looking into refactoring items, and i could work with you for few of the tasks
16:16:35 <sridhar_ram> twm2016: awesome.. the next set of tasks is to break down the different work items in the refactoring bucket.. please co-ordinate w/ sripriya
16:16:39 <sripriya> twm2016: thanks for your interest
16:16:47 <vishnoianil> sridhar_ram, it's good if we can target VNFFG for the July, because that's when ODL move toward functionality freeze
16:17:17 <sridhar_ram> brucet_: tung_doan: KanagarajM: same would hold for the Tacker auto-scaling..
16:17:21 <janki91> I would like to contribute in VNFFG
16:17:24 <brucet_> OK
16:17:36 <sridhar_ram> I didn't want to use the term "sub-team".. but that's what it would be..
16:17:38 <tung_doan> sridhar_ram: Ok. I will try
16:17:43 <trozet> sridhar_ram: yeah
16:17:53 <janki91> I am aware of ODL concepts/usage too
16:17:59 <sridhar_ram> bunch of interested folks pitching in and landing a feature..
16:18:16 <brucet_> I assume current blueprint for ceilometer alarm monitoring driver is different than autoscaling
16:18:33 <sridhar_ram> vishnoianil: great.. that will be perfect.. it the stars can be lined up :)
16:18:37 <sridhar_ram> s/it/if/
16:19:03 <vishnoianil> sridhar_ram, yeah, they are all supposed to line up, so lets give it a best shot :)
16:19:11 <sridhar_ram> brucet_: we will go more into VNF auto-scaling in few mins..
16:19:18 <brucet_> Ceilometer usage in autoscaling will be in Heat template
16:19:24 <brucet_> OK
16:19:37 <vishnoianil> janki91, if you would like to contribute toward ODL side or networking-odl, feel free to reach out to me
16:19:41 <sridhar_ram> Any questions on the way we are going to approach Newton release ?
16:20:09 <vishnoianil> janki91, and if you are looking toward contributing to VNFFG/ tacker plugin/driver, reach out to tim/sridhar
16:20:18 <janki91> vishnoianil: sure, I will definitely reach out. Infact we have talked in one of the ODL meetups before
16:20:29 <sridhar_ram> Next, in the Newton way of things...
16:20:57 <sridhar_ram> I'm pushing a patchset to tacker-specs to explicitly call out documentation for our features...
16:21:00 <sridhar_ram> #link https://review.openstack.org/314411
16:21:52 <sridhar_ram> First, I'd like to thank vishwanathj and sripriya for pushing the user docs for EPA and MultiSite
16:22:23 <sridhar_ram> however, going forward it doesn't make sense to accept a feature without a write up / doc describing how the operator community can use it
16:22:47 <sridhar_ram> so, going forward a devref in doc/source/devref/feature is mandatory ...
16:22:58 <sridhar_ram> .. it needs to be treated like code..
16:23:15 <sridhar_ram> any quick thoughts ?
16:23:23 <sridhar_ram> make sense ?
16:23:33 <sridhar_ram> perhaps, I'm moonlighting ? ;-)
16:23:33 <santoshk> +1 from user side...
16:23:40 <janki91> +1
16:23:42 <dkushwaha> +1
16:23:42 <trozet> sounds good
16:24:24 <sridhar_ram> alright, we can discuss if you've any concern in the above gerrit review
16:24:26 <sridhar_ram> moving on...
16:24:35 <sripriya> sridhar_ram: i'm assuming we can still post a WIP for features?
16:24:59 <sripriya> sridhar_ram: even if it means all mandatory stuff is not included
16:25:19 <sridhar_ram> sripriya: absolutely, we can always break your feature into multiple patchsets..
16:25:27 <sripriya> sridhar_ram: ok
16:25:52 <sridhar_ram> the recommendation is to push it as part of your primary patchset...
16:26:17 <sridhar_ram> part of it, it will force you to code in a way that is appropriate in the usage side..
16:26:50 <sridhar_ram> #topic VNF FFG - Descriptor Template
16:27:16 <sridhar_ram> #link https://review.openstack.org/#/c/292196/6/specs/newton/tacker-vnffg.rst,unified
16:27:32 <sridhar_ram> I'd like to land this spec at the earliest ...
16:27:54 <sridhar_ram> .. we will soon go into a "last call" mode soon
16:28:35 <sridhar_ram> Lot of folks signed up to review.. don't see all of them in the review
16:28:36 <trozet> sripriya: can you please respond to my comments?
16:28:37 <sridhar_ram> :)
16:29:07 <vishwanathj> i signed up and will review starting today
16:29:16 <sripriya> trozet: will respond ASAP
16:29:26 <sridhar_ram> trozet: few specific question on the template shown in L160 - L198
16:29:26 <trozet> sripriya: thanks
16:30:04 <sridhar_ram> trozet: how are you planning to get the neutron port ID corresponding to a particular CP ?
16:30:23 <sridhar_ram> trozet: I'm assuming you would need that to invoke neutron-sfc api
16:30:40 <trozet> sridhar_ram: well just regular neutron API, but yeah
16:31:22 <trozet> sridhar_ram: i could also ask heat I guess for the port ID
16:31:26 <sridhar_ram> trozet: but looking at "--vnf-mapping VNF1:vnf1-test,VNF3:vnf3-test'
16:32:01 <sridhar_ram> trozet: here is the constraint.. we can't have vnffg plugin directly calling into heat APIs
16:32:35 <sridhar_ram> trozet: we need to maintain the layer of separation between vnffg and vnfm components..
16:32:58 <trozet> sridhar_ram: maybe VNFM should store the port ids for its instances in it's db?
16:32:59 <sridhar_ram> trozet: at the least, it needs to using well define vnfm call / api
16:33:50 <sridhar_ram> trozet: I thinking along the same lines, we need to enhance GET /vnf call to have more "detailed" response
16:33:51 <vishnoianil> trozet, i like the idea of storing the port id for VNFM
16:34:31 <vishnoianil> probably a orchestrator specific metadata for VNF
16:34:35 <sridhar_ram> trozet: vishnoianil: I'm not if we need to store in vnfm db.. but offer an vnfm instrospection API to get those details
16:34:37 <s3wong> sorry, guys. Need to get going (driving)
16:34:46 <sridhar_ram> s3wong: np !
16:34:56 <vishwanathj> s3wong drive safe
16:34:59 <s3wong> talk to you guys next week. Will check the log, as VNFFG stuff is (obviously) relevant to me
16:35:02 <s3wong> Thanks!
16:35:10 <sridhar_ram> s3wong: yes, need your inputs
16:35:23 <trozet> sridhar_ram: how i do it in my code now is you always name the neutron port with the same ID as the tacker id
16:35:32 <trozet> sridhar_ram: so i can just go query neutron to find the port that way
16:35:51 <trozet> sridhar_ram: obviously its hack, so it would be better if that data is in the VNFM and i can just query VNFM for it
16:35:53 <sridhar_ram> trozet: no, that would be bad w.r.t layering..
16:36:09 <vishnoianil> sridhar_ram, i think API should also work, but just wondering why we don't want to store it in db? it's because of duplication of data? or maintenance  of it ?
16:36:41 <sridhar_ram> vishnoianil: duplication for most part, it is store in heat .. we can get it whenever we want.. plus..
16:36:55 <trozet> sridhar_ram: the heat stack knows the ID of the port it created, just add the api VNFM to query heat then
16:37:10 <sridhar_ram> vishnoianil: .. port id might change at anytime due to respawn / selfhealing, etc...
16:37:23 <sridhar_ram> trozet: exactly...
16:37:34 <vishnoianil> sridhar_ram, yeah, that's what i am guessing
16:37:44 <sripriya> probably with a vnf-show --details
16:37:48 <vishnoianil> trozet, sridhar_ram what's the cost of this API call?
16:38:16 <sridhar_ram> trozet: .. however, we can make it bit generic .. that is applicable for anyone looking for "detailed" vim infra level details about different VNF node_type instancesx
16:38:54 <sridhar_ram> vishnoianil: it would be heat api dip
16:39:01 <trozet> sridhar_ram: sure
16:39:25 <vishnoianil> sridhar_ram, okay
16:39:40 <sridhar_ram> trozet: other things to keep in mind is cross-feature interaction of VNFFG w/ other features like multisite and auto-scaling..
16:40:07 <trozet> sridhar_ram: so does that need it's own spec as well ? :)
16:40:11 <sridhar_ram> trozet: for e.g. of a VDU gets auto scale out / scale in.. the SFC chain needs to be altereed
16:40:32 <sridhar_ram> trozet: I would think so... :)
16:40:40 <trozet> sridhar_ram: not VDU necessarily...
16:40:59 <trozet> sridhar_ram: the external port to the VNF may remain the same, in which case SFC wouldn't care what is happening with VDUs
16:41:13 <trozet> thats my understanding anyway...
16:41:15 <sridhar_ram> trozet: in fact, I don't think the first version of VNFFG should support these things.. like multisite and auto-scaling.. but it needs to factor them in its design
16:41:22 <trozet> agree
16:41:50 <sridhar_ram> tung_doan: I know you've some thoughts captured in your spec on SFC and auto-scaling...
16:42:09 <sridhar_ram> please review trozet's spec with that in mind and provide your comments
16:42:09 <tung_doan> sridhar_ram: yeah,, right
16:42:26 <sridhar_ram> time to move on to the next topic..
16:42:40 <tung_doan> sridhar_ram: OK. thanks
16:43:11 <vishnoianil> sridhar_ram, multisite is tempting but i think ODL is not yet there, so that won't be able to support it, no sure about openvswitch driver
16:43:22 <sridhar_ram> again, please review vnffg spec .. specifically with user / operator in mind.. imagine you are the one writing the devref for this feature ?
16:43:27 <sridhar_ram> ;-)
16:43:58 <sridhar_ram> vishnoianil: agree, it is a huge topic by itself..
16:44:13 <vishnoianil> sridhar_ram, yup
16:44:40 <sridhar_ram> I'm just trying to make sure we don't pick some design choices in the initial version that will make it difficult to move into those areas for VNFFG
16:45:00 <vishnoianil> sridhar_ram, make sense
16:45:09 <sridhar_ram> I know we are in good hands ...
16:45:14 * sridhar_ram is now looking at trozet
16:45:26 * trozet looks behind him
16:45:30 <trozet> :)
16:45:33 <sridhar_ram> LOL
16:45:34 <vishwanathj> :)
16:45:45 <sridhar_ram> #topic Alarm based VDU Scaling - Scope, What it is and What it isn't
16:46:10 <bobh> sridhar_ram: hello, sorry I'm late
16:46:17 <sridhar_ram> bobh: howdy !
16:46:58 <sridhar_ram> tung_doan: as you might have realized.. alarm based monitoring and scalign is a huge topic by itself..
16:47:08 <sridhar_ram> tung_doan: first order of business is to clearly scope this initial effort...
16:47:24 <sridhar_ram> brucet_: are you in the channel ?
16:47:25 <tung_doan> sridhar_ram: agree
16:47:51 <sridhar_ram> tung_doan: can you describe what you had in mind w.r.t scope of this work ?
16:48:02 <sridhar_ram> brucet: ^^
16:48:12 <brucet> got lost
16:48:12 <tung_doan> sridhar_ram: yah.. right. my spec is focus on 3 points
16:48:55 <tung_doan> sridhar_ram: 1- VDU scaling, 2- High availability for SFC and 3- multi-site
16:49:16 <brucet> This is ceilometer spec?
16:49:52 <tung_doan> brucet: Hi brucet, I used Ceilometer to trigger alarms
16:50:14 <sridhar_ram> brucet: I'd like to converge on one spec... https://review.openstack.org/#/c/306562/
16:50:32 <tung_doan> brucet: let me know your opinion :)
16:51:00 <sridhar_ram> tung_doan: Obviously I'd suggest to keep the deliverable scope the 1 - VDU Scaling that factors in the design going into areas like 2- High availability for SFC and 3- multi-site
16:51:44 <tung_doan> sridhar_ram: agree
16:52:09 <tung_doan> sridhar_ram: That is my plan
16:52:13 <sridhar_ram> tung_doan: brucet: KanagarajM has captured some notes on how to leverage Heat + Ceilometer for this .. https://etherpad.openstack.org/p/tacker-scaling
16:52:21 <sridhar_ram> tung_doan: great...
16:52:42 <brucet> I added notes to his spec on what we basically agreed to
16:52:54 <sridhar_ram> tung_doan: there are few specific areas related to tacker on scale ..
16:53:18 <sridhar_ram> tung_doan: .. for e.g. mgmt-driver marked for that VDU might need to be called
16:53:21 <brucet> Autoscaling can be driven off a couple attributes in Tosca template
16:53:47 <tung_doan> sridhar_ram: sound good. I will consider...
16:54:10 <sridhar_ram> tung_doan: brucet: also user-data to be injected into the scale out VM..
16:54:30 <brucet> user-data for what??
16:54:54 <sridhar_ram> brucet: for the scale up VM
16:55:11 <brucet> The ceilometer monitoring driver can be used to trigger "manual" scaling events.
16:55:16 <sridhar_ram> brucet: I meant, for the new VM spawn due to a scale-out trigger
16:55:37 <brucet> But if first goal is autoscaling, that can be done totally through Tosca / Heat translator
16:55:41 <sridhar_ram> brucet: ah, manual scale out / in is another scope question...
16:56:03 <brucet> Autoscale will be easier
16:56:10 <sridhar_ram> tung_doan: we have requirements to support manual scaling as well..
16:56:22 <tung_doan> sridhar_ram: OK
16:56:30 <brucet> Please see discussion in Kanjaram spec
16:56:37 <bobh> sridhar_ram: once we have auto-scaling we get manual scaling almost-for-free
16:56:41 <sridhar_ram> brucet: link please
16:56:45 <brucet> Both can be done with one featrure
16:57:02 <sridhar_ram> bobh: agree...
16:57:05 <brucet> Don;t have it
16:57:10 <tung_doan> agree with bobh
16:57:46 <sridhar_ram> brucet: I'd let you, tung_doan and KanagarajM to see if you've bandwidth to do auto-scale + manual-scale in one spec...
16:57:55 <brucet> That's easy
16:58:20 <brucet> I bit more implementation for manual scaling since I assume that should be done from monitoring driver interface
16:58:22 <sridhar_ram> I'm also looking for this group to give me guidance when they would land
16:58:28 * sridhar_ram almost out of time...
16:58:39 <brucet> Bobh will you work on this as well?
16:58:53 <bobh> brucet: sure
16:58:58 <sridhar_ram> Folks - we need to wind down for today..
16:59:11 <brucet> OK. I'll need your help for Tosca / Heat changes
16:59:17 <sridhar_ram> tung_doan: thanks for joining us...
16:59:18 <tung_doan> Thank you guys
16:59:29 <sridhar_ram> lets continue the discussion in the gerrit...
16:59:41 <sridhar_ram> #link https://review.openstack.org/#/c/306562
16:59:49 <tung_doan> sridhar_ram: sure!
16:59:52 <sridhar_ram> #topic Open Discussion
17:00:07 <sridhar_ram> thanks everyone... lets get busy w/ Newtom..
17:00:19 <sridhar_ram> I'm excited with our pipeline..
17:00:21 <sridhar_ram> bye all
17:00:30 <sridhar_ram> #endmeeting