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