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