17:32:10 #startmeeting Networking Advanced Services 17:32:10 Meeting started Wed Apr 30 17:32:10 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:32:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:32:13 The meeting name has been set to 'networking_advanced_services' 17:32:20 Meeting agenda: #link https://wiki.openstack.org/wiki/Meetings/AdvancedServices 17:32:35 #info Wiki page 17:32:44 #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices 17:32:44 SumitNaiksatam: hi 17:32:51 Hi! 17:32:52 SumitNaiksatam: hi 17:33:03 nati_ueno Kanzhe: hi 17:33:19 going forward we will gradually start tracking our Juno progress on the wiki 17:33:41 meeting wiki page only for meeting agenda and suggesting topics of discussion 17:33:51 #topic Neutron Advanced Services' Framework 17:33:56 +1 to that SumitNaiksatam 17:34:02 mestery: sure 17:34:04 #link https://docs.google.com/document/d/1hshzNDfBrMj7C_3HnVaUlMSuAzea9MI7S3wLKH5eJmc/edit# 17:34:22 bassed on the discussions so far, we captured a design plan in the above document 17:34:32 i also share it with the PTL (mestery) 17:34:38 *shared 17:34:59 it should not be new to whoever has been participating in the IRC and discussions here 17:35:03 SumitNaiksatam: was [2] updated accordingly? 17:35:04 SumitNaiksatam: I liked how the plan was broken up into digestible pieces. :) 17:35:20 wanted to bounce it off everyone before we sent to the mailer and socialized more 17:35:24 mestery: thanks 17:35:29 hi 17:35:31 banix: no, 2 has not been updated 17:35:33 Swami: hi 17:35:55 banix: i was hoping to replace the references with actual gerrit bp links as they are posted 17:36:01 SumitNaiksatam: +1 to mestery: on that the doc has a nice overview leading off to the pieces parts 17:36:06 SumitNaiksatam: makes sense 17:36:15 banix: for now they are high level place holders 17:36:21 SridarK: ok 17:36:41 any more thoughts comments on this? 17:36:44 SumitNaiksatam: do you want the proposal of ServiceBase definition to go on [2]? If so, you may want to grant me edit right on that document 17:36:59 s3wong: sure, we can discuss offline 17:37:10 s3wong: i thought it was open, but perhaps not 17:37:18 its been a while :-) 17:37:21 not open 17:37:31 the detail is obviously in the details as far as that document is concerned 17:37:32 which is fine 17:37:47 which should come through each individual blueprint 17:37:55 and we will discuss here as well 17:38:00 banix: okay, will fix 17:38:16 enikanorov_ nati_ueno: any thoughts on the high level plan? 17:38:31 +1 17:38:35 :) 17:38:42 SumitNaiksatam: high level plan looks good. btw, is there a bp on review regarding service base definition? 17:39:15 enikanorov_: not yet, since its evolving, s3wong will put one 17:39:33 enikanorov_: or we might combine it with the service insertion bp that Kanzhe will add 17:39:38 enikanorov_: but one of those 17:39:49 nati_ueno: thanks :-) 17:39:50 hi folks! joinig late 17:39:51 ok. i'd like to focus on neutron-specs since i have to track too much in mailing list and in separate docs 17:39:54 so we will use google doc as draft? 17:39:56 joining* 17:40:05 enikanorov_: agreed 17:40:10 SumitNaiksatam: s3wong and I will sync up after the meeting. 17:40:10 +1 for discussing in gerrit 17:40:11 +! for neutron-specs 17:40:19 +1 even 17:40:20 mestery: process id? :) 17:40:27 ^) 17:40:38 yes we will try to put this into gerrit at the earliest 17:40:40 Hi, I am late 17:40:50 Kanzhe: definitely 17:41:10 mestery: do you propose that the high level plan be put in gerrit as well? or should we just keep it in the google docs and socialize over emails? 17:41:25 let's have them in the gerrit too 17:41:27 mestery: with the gerrit specs to follow with individual details 17:41:37 neutron-spec html looks really nice spec doc 17:41:46 I think checking in the high-level plan into gerrit, referencing the other BPs, may not be a bad idea 17:41:51 As long as we make it clear it's a high level plan. 17:41:53 Thoughts? 17:41:56 nati_ueno mestery: okay got it 17:42:13 well, the high level plan cannot be really reviewed on its own 17:42:20 will do that, i think it will help to have the other bps in teh queue too so that those can be referenced 17:42:27 banix: yes i agree 17:43:05 banix: if we make sure we agreed on high level in gerrit, we can just refer it, and We can prevent looping discussion 17:43:15 nati_ueno: ok sure 17:43:21 qish we could somehow have he high level plan on evey individual spec to give the reader the context 17:43:21 we will do it then 17:43:59 #action SumitNaiksatam to add high level advanced services framework bp to gerrit, will not contain details but reference other detailed bps 17:44:01 banix: nice sugestion. will add to port-chain as soon as I submit it to neutron-specs 17:44:05 c/quish/wish 17:44:19 banix: yes, I agree with nati_ueno here. The advanced service high-level idea itself has been circulating for a while, it is great to use gerrit as a channel to gather community feedback 17:44:48 mestery: hopefully this will be reviewed in that spirit, and we wont get stuck at the lack of details in the high level bp 17:45:06 nati_ueno: s3wong ok; people may not review it on its own but for referencing sounds good 17:45:18 banix: ya, let's link it 17:45:55 mestery: ^^^ ? 17:45:56 SumitNaiksatam: I will police the BP submission. :) 17:46:02 mestery: ah good! :-) 17:46:18 ok moving on (unless there is something else on this) 17:46:26 so every related spec can start with referncing the high level design 17:46:38 banix: ok 17:46:54 banix: sure 17:46:57 #topic Key/certificate management using Barbican for VPN and LBaaS 17:47:07 this was raised by Swami earlier 17:47:15 and we brought this up with mestery as well 17:47:24 yes, and we have a thread on this 17:47:37 Yes, thread on the ML. 17:47:47 Seems as if using Barbican here could benefit both VPNaaS and LBaaS. 17:47:53 right 17:47:53 nati_ueno mestery: so at this point this is resolved? 17:48:04 enikanorov_: are you agree with this plan? 17:48:10 but how neutron can rely on barbican? 17:48:11 Swami: does this work for you? 17:48:17 enikanorov_: good question 17:48:23 The only issue Barbican is in incubation :) 17:48:25 Hopefully out of Incubation soon. 17:48:30 yes 17:48:30 mestery: yes good point 17:48:39 so we need driver archtecture for this management 17:48:39 yep, that will solve the issue 17:48:46 +1 nati_ueno 17:48:53 we will need db impl for some time 17:48:54 With the end goal of moving it all to Barbican. 17:48:57 and also barbarian impl 17:49:03 * SumitNaiksatam thinks similar issue to Service VMs being in stackforge 17:49:04 yes 17:49:12 nati_ueno: i think a part of neutron community is against db impl 17:49:13 +1 SumitNaiksatam 17:49:18 YEs 17:49:25 DB implementation will have challenges. Is there an alternative? 17:49:28 enikanorov_: yes, so they can choose barbarian impl 17:49:39 barbican +1 17:49:45 nati_ueno: i think the main point is security concerns 17:49:59 enikanorov_: it depends on how we define system security 17:50:01 that better be avoided rather then offered as a "unsecure option" 17:50:13 enikanorov_: I don't think it is unsecure option 17:50:30 enikanorov_: If DB ID/PW get stolen, it is same 17:50:42 enikanorov_: But I do agree there are more secure option 17:51:04 enikanorov_: I'm new to barbarian, so I'm still not sure how it is more secure than db impl yet 17:51:24 barbarian :) 17:51:39 :) 17:51:40 oops typo 17:51:44 * SumitNaiksatam thinks that ^^^ was coming :-) 17:51:49 ;) 17:51:56 I thought that was the name first time I saw it 17:52:08 he he he 17:52:16 anyway, let's decide the option 17:52:19 mestery: so is this the plan of record to use barbician, or are we still evaluating this? 17:52:32 (1) Jump to Barbican (2) have two option 17:52:37 I think we should plan to move to barbican, if we need a stopgap, that's what we can discuss on the ML still. 17:52:39 Swami: have you evaluated using barbician? 17:53:00 so (1) ? 17:53:31 *barbican 17:53:41 oops 17:53:45 nati_ueno: 1 17:53:47 I think 17:54:04 Sure, so we don't need driver arch here 17:54:23 let's have a Barbican manager in the neutron 17:55:11 ok for now the plan of record is to use barbican, i was hoping Swami would have been able to chime in 17:55:14 BTW barbican is two way it can also notify that a cert has changed 17:55:38 enikanorov_, mestery: perphaps you can notify the LBaaS team as well 17:55:39 aka new certs comes barbican kicks off a new LB 17:55:49 german_: ok good to know 17:55:51 SumitNaiksatam: Yes, we will do that. 17:55:52 SumitNaiksatam: sure... 17:56:07 mestery enikanorov_: thanks 17:56:29 That's all for me on keys/certs, thanks SumitNaiksatam! 17:56:30 i did not mention VPNaaS since i think we have the entire team here (nati_ueno and pcm_ :-P) 17:56:44 mestery: thanks much for joining 17:56:51 he he, so we agreed on how we store cert 17:56:56 next topic 17:56:59 how we save it on the file system? 17:57:09 SumitNaiksatam: No idea, but I haven't work w/cert stuff. 17:57:23 plain? or it should be encrypted? 17:57:50 I don't know how we can encrypt & automation yet 17:58:23 who else uses barbican? 17:58:26 nati_ueno: we need a library in neutron? 17:58:42 SumitNaiksatam: library for what? 17:58:43 nati_ueno: These are all good questions, I'm not sure. 17:58:45 banix: good question, they will face the same issue 17:58:58 nati_ueno: to do the encryption 17:59:06 perhaps this is for oslo? 17:59:13 mestery: he he I'm expecting your nice answer 17:59:27 SumitNaiksatam: hoping they have already and have a solution/lib 17:59:29 nati_ueno: :P 17:59:31 SumitNaiksatam: even if we encrypt it, how we manage the key for encription 17:59:36 nati_ueno: More discussion needed here. :) 17:59:48 ya, it is more than this meeting timeslot 17:59:50 german_: anyone else uses barbican today? 17:59:53 so let's keep discussion in the ML 18:00:06 ...after we know some more about barbican :) 18:00:08 nati_ueno: +1 18:00:11 Rackspace does and some at HP are evaluating 18:00:35 german_: ok perhaps we have more questions for you 18:00:37 german_: Good to know! 18:00:47 german_: cool! where is good how-to doc? 18:01:17 #action nati_ueno mestery Swami to take barbican support and local cert/key management discussion to mailer 18:01:20 I will check with and get back to you via mailing list 18:01:30 #undo 18:01:30 german_: Thanks!! 18:01:31 Removing item from minutes: 18:01:41 : #action nati_ueno mestery german_ Swami to take barbican support and local cert/key management discussion to mailer 18:01:48 #topic Flavors Framework 18:02:08 #link https://review.openstack.org/#/c/83055 18:02:19 enikanorov_: noticed that updated based on comments till date 18:02:20 i've pushed pretty much complete description 18:02:26 enikanorov_: thanks 18:02:28 yes 18:02:37 did anyone get a chance to review the latest revision? 18:02:43 i am unfortunately behind on this 18:03:08 so am I 18:03:15 This is the spec https://review.openstack.org/#/c/90070/ 18:03:16 so i think we had a consensus on general idea 18:03:29 nati_ueno: oh, thanks 18:03:33 you're right 18:03:35 there were some discussions about not using the word flavor 18:03:50 nati_ueno: thanks, sorry i mixed up the links 18:03:51 so i think what still worth discussing is how to specify capabilities in flavor object 18:03:56 and probably how to match them 18:04:18 german_: i think majority is in favor of 'flavor' 18:04:28 because it's similar concept to nova's 18:04:32 enikanorov_: so elaborate on “capabilities"? 18:04:37 also I am wondering how the flavor system relates to the nova scheduler (GANT) which is being spun off and can select a machine "flavor" 18:04:46 * nati_ueno put review the spec in today's todo 18:04:58 SumitNaiksatam: it's a list of (name, value) pairs that flavor object is keeping 18:04:59 nati_ueno: thanks 18:05:18 german_: it's same idea 18:05:28 enikanorov_: you mean issues like wildcarding the match? 18:05:32 german_: it's described in the spec btw, scheduling part 18:05:48 thanks -- neat 18:05:52 banix: i don't think we need to support wildcarding, but it's an interesting option 18:06:10 haven't thought of it 18:06:29 enikanorov_: wouldnt wild card be the default option, so to say? 18:06:55 so we are evaluating GANTT for that (https://github.com/openstack/gantt) 18:07:15 SumitNaiksatam: a good question 18:07:28 german_: good to know 18:07:31 i think i need to work more on defaults and migration 18:07:31 how do the flavors get expressed by the client? dict? wondering how easy to specify for user. 18:07:41 pcm_: falvor_id 18:08:01 pcm_: right now the idea is that flavor specified by admin only 18:08:03 enikanorov_: so flavors created separately, and then specify by ID 18:08:08 yes 18:08:16 user just lists them and specifies the id 18:08:35 gotcha 18:09:03 doesn't the user have to specify a key/value to find a matching flavor 18:09:06 there's a small discussion on that in the 1st patchset between me and salvatore 18:09:30 hemanthravi: no, and btw, key-value is apparently a wrong name for capability 18:09:32 enikanorov_: will look at it. 18:09:37 it's better to say (name, value) 18:09:43 enikanorov_: :-) 18:09:47 matching happens on selecting providers 18:10:01 it's just because names can duplicate 18:10:14 keys imply uniqueness 18:10:19 enikanorov_: ah got it 18:10:49 banix: isn't flavor the mech to select a provider? 18:10:59 enikanorov_: so flavor would contain "provider" info, so that feature could then select the driver? 18:11:21 pcm_: not necessarily 18:11:30 pcm_: but that's possible 18:11:41 enikanorov_: trying to understand how to support providers 18:11:43 hemanthravi: yes but the user does not specify the list of name values 18:11:45 enikanorov_: of course, even with "value", you can have multiple providers matching the criteria 18:11:50 pcm_: you can create flavor that will point to provider, btw, that was implemented as an example in PoC patch 18:12:10 s3wong: you can. you select some provier that satisfies all capabilities 18:12:31 enikanorov_: based on “vendor” name (per pcm_’s question)? 18:12:49 pcm_: look at UTs: https://review.openstack.org/#/c/83055/ 18:12:54 SumitNaiksatam: yes, like that 18:12:57 *possible* 18:13:09 enikanorov_: will do 18:13:12 that's just if some admin want to imitate existing workflow with providers 18:13:19 ok, lets get some more eyes and comments on this gerrit bp at the earliest 18:13:37 ya, this is really important bp. 18:13:39 this is in the critical path of other work services’ work 18:13:41 may guys depends on this 18:13:46 What is the plan for current STF patch? 18:13:46 yep 18:14:00 so either we all agree on this and move ahead, or we suggest improvements at the earliest 18:14:09 we cannot linger in this state for too long 18:14:12 garyduan: id like STF to be integrated with services 18:14:32 enikanorov_ has done his job by posting the review, we all need to respond 18:14:35 garyduan: as you remember, you need to move provider out of API, but preserve it as a dispatching mechanism 18:14:42 banix: got it, flavor-id is the list of name/value pairs to find a provider 18:15:03 enikanorov_: yes, I understand the flow 18:15:03 garyduan: i think in such variant the patch should be fine with those (like Mark) who -1ed it 18:15:07 enikanorov_: do we have consensus with the other cores on using the STF at the backend? 18:15:17 SumitNaiksatam: not yet i think 18:16:01 so we wait for for flavor framework 18:16:06 no, I need to see how it relates to gantt since we have a complex scheduling environment 18:16:28 will put my comments in today 18:16:29 wait for flavor framework to get in first? 18:16:30 german_: it doesn't 18:16:36 so STF selects driver based on provider on backend, and flavors gives a way to select provider (based on caps or vendor selection)? 18:16:40 enikanorov_: do you mention STF integration in the bp? 18:16:49 SumitNaiksatam: no 18:16:52 * pcm_ needs to look at the PoC 18:17:07 SumitNaiksatam: integration is needed to actually apply Flavors to fwaas/vpnaas 18:17:27 enikanorov_: yep 18:17:30 but it isn't needed to implement API, DB and common code for plugins part 18:17:32 enikanorov_: actually that should be fine since we can have that discussion independent of the user facing flavors abstraction 18:17:43 enikanorov_: yes 18:17:44 SumitNaiksatam: agree 18:17:57 ok, all please comment on the review 18:18:12 #topic Service context with Service Interfaces 18:18:21 #undo 18:18:22 Removing item from minutes: 18:18:24 enikanorov_, SumitNaiksatam: so if STF is to be the backend, get STF in, hide provider selection is one path to move forward 18:18:27 #topic Service Insertion with Service Interfaces 18:18:38 garyduan: i agree 18:18:40 garyduan: right 18:18:54 #link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit# 18:19:04 Kanzhe: you want to update on the latest round of discussions? 18:19:21 we will have to keep it quick since we have a couple of other agenda items 18:19:22 SumitNaiksatam: sure, a quick update. 18:19:46 There are some feedback on serviceInsertion proposal. 18:20:03 * nati_ueno may be,, neutron-spec police is comming 18:20:43 The main point is to introduce an new object that can be used as service insertion point. 18:20:47 nati_ueno: gerrit spec is coming soon, until then we will bribe the police :-) 18:21:03 It could be a neutron port, or extended to L1 port in the future. 18:21:24 I will update the doc and convert to BP in gerrit later the week. 18:21:35 Kanzhe: Thanks! 18:22:22 over. :-) 18:22:23 Kanzhe: the doc in its current form is close to the last round of discussions ? 18:22:24 Kanzhe: thanks 18:22:44 Not yet. didn't have time to update with the latest design. 18:22:46 Kanzhe: are we merging serviceBase and serviceInterface into one spec? 18:22:49 Will do it later today. 18:23:08 I think so. 18:23:12 s3wong: Kanzhe combining makes sense 18:23:13 Kanzhe: ok will wait on that 18:23:15 s3wong: +1 18:23:27 banix Kanzhe: cool 18:24:05 the only reason they might be different is if they need to first make things backward compatible 18:24:17 we need to think through 18:24:36 and will need input from enikanorov_ and nati_ueno on this 18:24:43 good point; wasnt thinking about that 18:24:48 SumitNaiksatam: Sure! 18:24:55 with regards to LBaaS and VPNaaS 18:25:13 SumitNaiksatam: OK, makes sense 18:25:17 things aer quite complex on lbaas front :) 18:25:29 ythat conversation should happen before the submission to review. no? 18:25:35 enikanorov_: :-) 18:25:50 banix: yes, that is hte reason we are doing this on gdoc 18:26:04 yup 18:26:06 to at least get some critical mass to converge on the basic idea 18:26:33 perhaps we need some explanation in the doc for this 18:26:41 i guess Kanzhe will follow up 18:26:45 next topic 18:26:50 yeah; in this particular case we need VPNaaS and LBaaS onboard 18:26:53 SumitNaiksatam: yes. 18:26:58 Kanzhe: thanks 18:27:17 enikanorov_: btw, forgot to mention thanks for the earlier update on flavors 18:27:19 #topic Port Chaining Proposal 18:27:31 #link https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU/edit 18:27:38 cgoncalves jsoares: there? 18:27:43 \o/ 18:27:49 yup 18:27:56 you will see that this is incorporated into the bigger plan 18:28:16 does everyone agree with this as the traffic steering building block? 18:28:28 so this week we got some feedback from some of you (thanks!) 18:28:56 and we've removed the idea of Flow and Endpoint as per SumitNaiksatam suggestion 18:28:58 updates that lead to relevant updates :) 18:29:10 cgoncalves jsoares: thanks 18:30:34 so if there are no major objections, cgoncalves and jsoares can move this to the gerrit bp process 18:31:13 i also think this is an independent peice, so can be worked on in parallel 18:31:18 SumitNaiksatam: yes, that would be the next move I suppose. if all agree, I will do it this week 18:31:41 Is service chain still needed even if we have GP? 18:31:57 nati_ueno: yes 18:31:59 nati_ueno: yes 18:32:23 :) 18:32:26 yes on the service_chain 18:32:40 Yes +1 18:32:45 nati_ueno: we tried to explain that a little in the high level document 18:33:06 nati_ueno: the service chain abstraction can make use of the traffic sterring abstraction 18:33:11 so if we have a chain or graph of services in the contract policy rule action, we can do this, right? 18:33:46 nati_ueno: are you referring to group policy? 18:33:50 yes 18:34:05 at least as GP is defined now we refer to a service chain as defined in services 18:34:17 banix: yeah 18:34:33 banix: yeah, but isn't it more simple? 18:34:39 service chain will rely on port chain, and GP on service chain. that's the plan if i'm not mistaken 18:34:43 and that service chain in turn might use the traffic steering to actually achieve the chain 18:34:53 cgoncalves: yeah, meant to say that 18:35:03 nati_ueno: it is easier to use a chain defined elsewhere :) 18:35:11 banix: agree 18:35:16 nati_ueno: we don't really define service chain in GP; only that the policy enforced between a group going to another group 18:35:28 s3wong: agree 18:35:33 okay we running over time 18:35:41 nati_ueno: we can perhaps take this offline? 18:35:47 nati_ueno: we have thought of what I think you are suggesting though. 18:35:47 i have one more agenda item 18:35:54 hmm I'm worring about resource model getting really complex.. 18:36:26 do we have complete horizon wireframe for this? 18:36:29 nati_ueno: agree but at least this way there is a seperation … 18:36:45 nati_ueno: what is a wireframe? 18:37:01 banix: a wireframe is a design of UI workflow 18:37:07 nati_ueno: we are looking for a volunteer to do horizon work, do you want to volunteer? :-) 18:37:08 SumitNaiksatam: sorry you wanted to discuss something else 18:37:08 banix: you can see example in tripleo-ui 18:37:23 SumitNaiksatam: ya, if I can understand models :) 18:37:34 SumitNaiksatam: so please help me 18:37:45 nati_ueno: do you have a pointer? is that part of dashboard already? 18:37:49 nati_ueno: only if you are willing to :-) 18:37:55 SumitNaiksatam: I do! 18:38:08 nati_ueno: you got it! :) 18:38:29 "I do" famous words often said and regretted later :-) 18:38:31 nati_ueno: on a more serious note, ronak who is not here, has volunteered for horizon support 18:38:36 banix: this is ample http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/ 18:38:40 but we are going off topic here 18:38:46 nati_ueno: great. thx. 18:38:47 SridarK: he he he 18:38:51 we have group policy meeting tomorrow where we can bring this up 18:39:02