17:02:22 <cathy_> #startmeeting service_chaining
17:02:22 <openstack> Meeting started Thu Oct 15 17:02:22 2015 UTC and is due to finish in 60 minutes.  The chair is cathy_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:26 <Swami> hi
17:02:26 <openstack> The meeting name has been set to 'service_chaining'
17:02:27 <johnsom> o/
17:02:31 <vikram_> hi
17:02:37 <cathy_> hi everyone
17:02:42 <pcarver> hi
17:02:59 <s3wong> hello
17:03:00 <mohankumar> hi
17:03:12 <cathy_> any topic you would like to discuss today?
17:04:16 <vikram_> cathy_: I have few questions
17:04:20 <cathy_> One topic we need to discuss is how to ensure new update of the patches do not break the functionality, how to enforce running of the UT scripts. what do you think?
17:04:29 <cathy_> vikram_: sure, go ahead
17:04:54 <vikram_> cathy_: want to discuss about a comment received for the CLI patch
17:05:09 <vikram_> https://review.openstack.org/#/c/210008/
17:05:19 <cathy_> #topic discuss about a comment received for the CLI patch
17:05:36 <cathy_> let me take a look at the comment.
17:06:03 <cathy_> vikram_: which one?
17:06:14 <vikram_> Do we need to support empty flow_classifier list for port-chain update
17:06:20 <vikram_> https://review.openstack.org/#/c/210008/14/networking_sfc/cli/port_chain.py
17:06:26 <vikram_> L108
17:07:12 <vikram_> if yes then we need to have a separate cli option for this
17:07:22 <vikram_> may be --no-flow-classifier
17:07:33 <LouisF> hi
17:07:47 <vikram_> hi LouisF
17:07:48 <cathy_> LouisF: hi
17:08:05 <vikram_> what everyone thinks about this?
17:08:09 <vikram_> amotoki: ping
17:08:27 <amotoki> hi
17:08:53 <vikram_> amotoki: I think you are aware about --no-flow-classifier discussion
17:09:09 <amotoki> vikram_: yes
17:09:21 <johnsom> I think the option to not have a flow classifier is good.
17:09:24 <vikram_> amotoki: I am discussing the same with the team
17:09:54 <cathy_> amotoki: hi
17:10:15 <vikram_> My first question is do we need to support it?
17:10:32 <amotoki> Honestly I am not sure there is a case where we need to set flow-classifiers to []
17:10:40 <cathy_> vikram_: johnsom we allow no specification of FC when creating SC. I am still going through the comment. vikram_ could you clarify the question?
17:11:16 <s3wong> vikram_: that's my question too... a chain with all Neutron ports specified already but without classifier... how does that work?
17:11:25 <vikram_> cathy_: The doubt is about updating Portchain information with empty FC list
17:11:26 <cathy_> vikram_: later the user can add dynamically add more FC to the chain or remove some flow from a  chain
17:11:29 <johnsom> So it's a convenience option we are talking about
17:11:41 <amotoki> IMO it is better to provide a way to specify [] in general, as I stated in the review comment.
17:11:56 <amotoki> one question: do we need to specify FC when creating a port-chain?
17:12:08 <cathy_> amotoki: no
17:12:11 <LouisF> amotoki: no
17:12:31 <vikram_> s3wong: agreed.. I am just wanted to confirm whether we should support empty FC list in either create or update?
17:12:34 <amotoki> it means we allow empty flow classifiers for port-chain.
17:12:45 <Swami> I thought the FC is required for the port-chain to work
17:12:46 <vikram_> amotoki: +1
17:12:59 <s3wong> Swami: as do I...
17:13:05 <Swami> Is FC not a requirement for port-chaining.
17:13:08 <vikram_> Swami: I am with Swami.. I also fell we can madate this option
17:13:17 <vikram_> *feel
17:13:25 <amotoki> In my understanding, if FC is not specified, it matches all traffic from a neutron port.
17:13:26 <Swami> Because if we pass an empty classifier does it mean don't check the flow.
17:13:31 <LouisF> Swami: that is correct no traffic will enter the chain unless a FC is specified
17:14:09 <vikram_> LouisF: Is FC a mandatory param?/
17:14:12 <LouisF> it may be convenient to configure the port chain and then add FCs as needed
17:14:24 <amotoki> LouisF: my understanding looks wrong according to your comment above.
17:14:26 <LouisF> vikram_: no
17:14:30 <amotoki> LouisF: right?
17:14:43 <s3wong> LouisF: so in essence it is staging the port-chain, but basically not officially "deploying" the chain?
17:14:48 <cathy_> amotoki: if no FC is specified, then no flow will enter the chain
17:14:53 <LouisF> s3wong: correct
17:15:07 <Swami> I would say that a valid entry in the FC is required for the port-chain to work. But we can make the FC to be updatable.
17:15:08 <cathy_> s3wong: yes
17:15:27 <vikram_> Swami: +1
17:15:36 <amotoki> cathy_: thanks. no traffic matches to empty FC, so no traffic enters such chain. got it.
17:15:37 <LouisF> Swami: -1
17:15:55 <Swami> LouisF: what is your concern.
17:16:47 <LouisF> Swami: as i stated, it is question of staging the PC, it may initially be configured with no FC and then the FCs are added as necessary
17:16:48 <mohankumar> cathy: then we need to make FC as mandatory param
17:17:22 <Swami> LouisF: So my question is do you even want the agent to work on a port-chain configuration if there is no FC.
17:17:26 <amotoki> one possible use case is to disable a port-chain temporarily or conditionally.
17:17:28 <vikram_> LouisF: Anyways no point having a PC without a FC
17:17:38 <LouisF> Swami: so my argument is that FCs are not mandatory
17:17:41 <vikram_> LouisF: Then why we should allow such conf
17:17:45 <cathy_> Swami: there could be scenario that during some time period, no flow will go through a chain and then later some flows are added to the chain. This will avoid removing chain and then creating chain frequently.
17:17:53 <amotoki> or enable port-chain conditionally.
17:18:29 <Swami> cathy_: My point is if you don't have a valid FC, why do we even need the chain setup to be there.
17:18:46 <cathy_> amotoki: yes, no FC for a chain at that time means the chain is disabled or not used temporarily
17:19:09 <LouisF> Swami: operationally a PC can be created initially with no FCs: it is essentially dormant until FCs are added
17:19:22 <Swami> The problem with this you might be stressing the rpc a lot with the agent changes. If everything is in place, it will be single shot.
17:19:37 <LouisF> this provides the flexibility of doing this
17:19:44 <amotoki> Swami: a usecase in my mind is that we setup a port-chain first with no associated flow and then add flow(s) depending on a situation.
17:19:58 <LouisF> amotoki: agree
17:20:16 <vikram_> amotoki: IMO, user must have a usecase in mind before creating a PC
17:20:25 <Swami> So in this case do you expect all packets to flow through the chain or no packets to flow through the chain until there is an FC.
17:20:29 <vikram_> amotoki: Why to have the overhead..
17:20:29 <LouisF> amotoki: this allows for that use case to work
17:20:41 <cathy_> Swami: I understand your point. but the purpose is for handling the scenario that no flow goes through the chain temporarily and we do no need to end up deleting a chain and then recreating the same chain
17:20:58 <cathy_> Swami: the latter
17:21:08 <Swami> cathy_: thanks
17:21:17 <vikram_> cathy_: but how frequent this can happen
17:21:18 <cathy_> Swami: no packets to flow through the chain until there is an FC.
17:21:35 <amotoki> vikram_: agree in general and it is typical cases I think.
17:21:46 <amotoki> vikram_: I just imagine possible use cases.
17:21:53 <Swami> cathy_: If no packets flwo through the chain, then it's ok
17:22:01 <Swami> s/flwo/flow
17:22:20 <vikram_> if everyone okay then I have no issues
17:22:44 <vikram_> Now coming to next question how to specify an empty FC list in update cli
17:22:49 <amotoki> my impression is if we don't have a reason to disallow empty flow-classifier for port-chain, it looks better to allow empty FC.
17:23:03 <Swami> cathy_: the only concern that i have is in large scale deployment if you have too many requests coming in with chain creation and then with FC addition, it would cause some timing issues.
17:23:05 <vikram_> amotoki: agreed
17:23:28 <Swami> cathy_: if we are ready to deal with those scenarios, then it is ok.
17:23:39 <cathy_> it could happen. for example, a chain consists of a FW. And there is a Flow associated with the chain. Then after some check passes, the remaining packets of the flow do not need to go through this FW chain. Then another new tenant's flow comes and might need to go through this chain. Or this previous flow sees some security issue and then needs to go through this fW chain again.
17:23:49 <amotoki> Swami: API concept and acutla behaviors are different things.
17:24:01 <amotoki> API concent should work for all cases.
17:24:21 <amotoki> how to deal with racing conditions is a different topic.
17:24:27 <Swami> amotoki: agreed, but I am talking about the action taken based on the API
17:24:34 <cathy_> so there will be some period that the chain is not associated with any flow
17:24:53 <vikram_> How to specify an empty FC list in update cli? Currently it's unaddressed...
17:25:15 <cathy_> Swami: it is all up to the user. If the user knows that some flows need to go through a chain then he should create the chain with FCs.
17:25:32 <Swami> cathy_: agreed valid point.
17:26:01 <LouisF> amotoki: so you are suggesting the explicit use of the --no-flow-classifier option on a port-chain-update to remove all FCs from a PC?
17:26:01 <vikram_> cathy_:agreed
17:26:36 <LouisF> in the CLI command that is
17:27:30 <amotoki> LouisF: yes. it is my thought.
17:28:07 <LouisF> amotoki: i this is a clean way of doing it - what do others think?
17:28:16 <vikram_> +1 for no-flow-classifier
17:28:43 <cathy_> amotoki: so if we allow explicit use of --no-flow-classifier option on a port-chain-update, should we allow the explicit use on port-chain-create?
17:29:07 <vikram_> cathy_: No need
17:29:09 <LouisF> amotoki: as you mention in your comments there is precedent for using that approach elsewahere in neutron - correct?
17:29:22 <amotoki> cathy_: there is no good guidline at now, but it can be supported for consistency.
17:29:38 <amotoki> LouisF: yes.
17:29:44 <cathy_> amotoki: vikram_ yes, I think it is better to be consistent. thanks.
17:29:48 <vikram_> cathy_: FC is not a mandate param for create operation.. user can just keep it empty
17:30:03 <LouisF> cathy_: agree no neew
17:30:06 <LouisF> need
17:30:06 <cathy_> vikram_: I am thinking about consistency
17:30:12 <amotoki> LouisF: AFAIK, FWaaS CLI adopts a bit different way, but others have similar options.
17:30:17 <vikram_> to me it's confusing
17:30:30 <vikram_> more options always create confusion
17:30:49 <cathy_> vikram_: LouisF I think similar option in create and update will be good
17:30:53 <LouisF> cathy_: means that the user has to do that on every port-chain-create
17:31:12 <LouisF> with no FC
17:31:26 <amotoki> cathy_: at the moment, there are many inconsistency in neutronclient options. If a default value is empty, most sub commands do not provide --no-xxx option but it can be improved.
17:31:45 <cathy_> LouisF: It is just whether we would like to make it explicit in create port chain similar to update port chain
17:32:14 <LouisF> i'm open to leave it for consensus
17:32:40 <cathy_> I am open too although personally I like consistency
17:32:55 <LouisF> shall we vote?
17:33:00 <vikram_> I would like it for update only..
17:33:01 <cathy_> LouisF: yes
17:33:09 <LouisF> +1
17:33:12 <vikram_> +1 for update only..
17:33:40 <amotoki> +1 for update, either ok for create.
17:33:40 <LouisF> +1 on that is my preference
17:34:04 <amotoki> LouisF: what does "that' mean?
17:34:21 <LouisF> amotoki: only on port-chain-update
17:34:26 <johnsom> Yeah, a summary of the vote would be handy
17:34:27 <mohankumar> +1 for update only
17:34:28 <amotoki> LouisF: thanks
17:34:35 <cathy_> mohankumar: Swami s3wong johnsom ?
17:34:55 <Swami> cathy_:hi
17:35:01 <cathy_> vote?
17:35:02 <mohankumar> cathy_: voted for "update only"
17:35:17 <s3wong> +1 for update only
17:35:19 <Swami> I am ok with the proposal +1
17:35:20 <johnsom> +1
17:35:54 <cathy_> #agreed we will add no flow classifier to the port chain update
17:36:52 <vikram_> cathy_: I have one more question..
17:36:57 <vikram_> can I put it forward
17:37:05 <cathy_> #agreed we will still allow the case of a chain with no FC
17:37:15 <cathy_> vikram_: sure
17:37:48 <vikram_> I can find that there are no FC related interfaces in the drivers base class?
17:38:12 <cathy_> vikram_: what do you mean? could you clarify?
17:38:28 <vikram_> cathy_: 1 sec.. let me collect
17:38:50 <vikram_> https://review.openstack.org/#/c/227100/16/networking_sfc/services/portchain/drivers/driver_base.py
17:39:00 <vikram_> class PortChainAbstractDriver(object):
17:39:05 <LouisF> vikram_: you mentioned that you would likely need those FC related interfaces for the onos driver - right?
17:39:14 <vikram_> LouisF: Yes
17:39:41 <vikram_> My intention is we need to be generic
17:40:18 <LouisF> vikram_: so your idea is to add them in that file or in a separate file?
17:40:27 <vikram_> LouisF: same file
17:40:57 <vikram_> IMO, we can expose them to the driver and driver may or may not implement those..
17:40:58 <LouisF> vikram_: should be ok - anyone else?
17:41:08 <cathy_> vikram_: +1
17:41:36 <cathy_> vikram_: I thought we have added them.
17:41:37 <LouisF> vikram_: can you go ahead and add the needed FC related interfaces
17:41:48 <vikram_> Will do that
17:41:55 <LouisF> vikram_: thanks
17:42:00 <cathy_> vikram_: great thanks
17:42:15 <amotoki> vikram_: does it lead to different behavior per driver? or can users get consistent behavior regardless of drivers?
17:42:24 <s3wong> Yep, that sounds good. Make our driver APIs more usable for various SDN controller solutions
17:42:38 <LouisF> s3wong: +1
17:42:48 <cathy_> amotoki: user should get consistent behavior regardless of drivers
17:42:50 <vikram_> amotoki: End result would be same
17:42:57 <LouisF> amotoki: +1
17:43:02 <vikram_> I am done..
17:43:18 <vikram_> I think amotoki has some idea about the plugin framework
17:43:19 <amotoki> vikram_: cathy_: good. we are all in the same page :)
17:43:28 <cathy_> amotoki: Yes, that is a must :-)
17:43:35 <vikram_> amotoki: would you like to discuss it?
17:43:40 <s3wong> amotoki: I think it should be fine... in essence we are giving the driver a flow programming interface which should map directly to OpenFlow like constructs
17:44:46 <cathy_> #topic plugin framework
17:44:50 <amotoki> vikram_ seems to try to move new topic
17:45:13 <cathy_> amotoki: would you like to discuss the plugin framework?
17:45:14 <amotoki> in the last meeting, we discussed how many service plugins we should have.
17:45:16 <vikram_> cathy_: thanks for moving the topic
17:45:24 <cathy_> vikram_: sure
17:45:36 <amotoki> I think the general consensus was one.
17:45:38 <s3wong> amotoki: I think that is the topic vikram_ wants to move to, and you get the ball :-)
17:45:50 <amotoki> :)
17:46:03 <mohankumar> :)
17:46:21 <amotoki> what in my mind is to have one service plugin for 'sfc' and it loads all required extensions.
17:46:34 <vikram_> amotoki: I am with you ;)
17:46:44 <Swami> +1
17:46:53 <amotoki> our concern is how we can migrate to a generic flow classifier extension once it lands.
17:47:14 <amotoki> as far as I gathered, it is the only reason we have two service plugins.
17:47:30 <amotoki> is it correct?
17:47:45 <vikram_> yes
17:47:46 <cathy_> amotoki: yes
17:48:23 <amotoki> so I am now trying to have one service plugin for 'sfc' in the initial flow classifier extension patch.
17:48:35 <cathy_> amotoki: so it can be more decoupled and we can move it to the generic FC easier
17:48:37 <amotoki> the plugin would be very thin
17:49:35 <vikram_> amotoki: I feel the extension in the same patch would increae it's testability as well
17:49:46 <amotoki> cathy_: do you mean if we have a separate service plugin for flow classifier we need to query a correspondng service plugin
17:49:47 <vikram_> *increase
17:50:00 <amotoki> and we can decouple things more clearly?
17:50:38 <vikram_> amotoki: I think the original intention was to develop it as a separate service..
17:50:39 <amotoki> on the other hand, without plugin, we cannot test in a real neutron-server.
17:51:06 <vikram_> cathy_: please correct me if wrong
17:51:43 <amotoki> okay, a separate plugin for classifier sounds okay. all other features are implemented into 'port-chain' plugin?
17:52:03 <vikram_> amotoki: We need to add for FC..
17:52:09 <vikram_> amotoki: It's pending
17:52:19 <cathy_> amotoki: sorry I am back. yes we need to query a correspondng service plugin
17:52:21 <vikram_> Will do that
17:52:50 <vikram_> cathy_: We think we don't need 2 service plugins
17:52:51 <cathy_> amotoki: yes
17:53:04 <cathy_> amotoki: yes all other features are implemented into 'port-chain' plugin?
17:53:12 <cathy_> amotoki: yes all other features are implemented into 'port-chain' plugin
17:53:20 <amotoki> cathy_: understood now.
17:53:47 <vikram_> cathy_: Current patch doesn't handle FC stuffs in port_chain service plugins
17:53:49 <amotoki> so is it better to rename 'port-chain' pluign to 'sfc' plugin?
17:54:04 <vikram_> cathy_: we got to add those..
17:54:11 <s3wong> amotoki, vikram_: so with one service plugin, in the future, if other services (say FWaaS) wants to use FC, they would essentially be dependent on sfc service plugin?
17:54:29 <vikram_> s3wong: FC will be a CORE extension
17:54:39 <vikram_> s3wong: so no need ;)
17:54:51 <s3wong> vikram_: I see ...
17:55:04 <amotoki> what we need then is to query CORE plugin and consume methods from Core plugin.
17:55:25 <LouisF> amotoki: query for FC - right?
17:55:50 <amotoki> LouisF: yes at now and after generic FC lands it will be provided by core plugin.
17:56:13 <vikram_> I think we are all okay with one plug-in I believe
17:56:26 <Swami> +1
17:56:34 <vikram_> +2
17:56:36 <LouisF> +1
17:56:42 <mohankumar> +1
17:56:50 <amotoki> one plugin for all FC and others?
17:56:57 <s3wong> LouisF: once FC lands in Neutron, us in SFC would be calling FC APIs which then taps into whatever driver/plugin that implements the FC core extensions
17:57:07 <vikram_> one sfc plugin for networking-sfc
17:57:17 <cathy_> vikram_: hold on
17:57:42 <amotoki> Or one plugin for all features except FC and a separate plugin for FC?
17:57:43 <vikram_> cathy_: sure
17:58:28 <LouisF> s3wong: do you see a problem there?
17:59:19 <vikram_> s3ong: Common FC is only about maintaining a common DB
17:59:53 <vikram_> s3wong: Common FC is only about maintaining a common DB
18:00:19 <vikram_> I think time is UP..
18:00:26 <s3wong> LouisF: well, (a) the FC extension that eventually lands in Neutron NEEDS to be compatible with how SFC consumes FC today (else we all go in and give a -1, and amotoki can give a -2), and (2) the separation needs to be a coordinated effort between whoever doing it in Neutron
18:00:39 <s3wong> vikram_: no API change?
18:00:45 <s3wong> (yeah, time's up. Sorry)
18:00:49 <vikram_> s3wong: nope
18:00:52 <LouisF> s3wong: ok
18:01:04 <amotoki> i don't want to -2. it is emergency.
18:01:22 <LouisF> mohankumar: we have tested with you CLI and making good progress
18:01:24 <s3wong> amotoki: :-) yeah, a bit of a joke there :-)
18:01:32 <amotoki> :-)
18:01:47 <s3wong> oh no, cathy_ is gone. No one to #endmeeting...
18:01:51 <mohankumar> LouisF : ok
18:01:51 <amotoki> let's finish the meeting
18:01:55 <vikram_> i think cathy_ is not there.. We are out of time
18:02:02 <LouisF> ok
18:02:09 <LouisF> #endmeeting
18:02:12 <vikram_> bye
18:02:18 <Swami> bye
18:02:18 <mohankumar> bye
18:02:22 <cathy_> hi
18:02:24 <amotoki> LouisF is co-chair?
18:02:30 <s3wong> cathy_: please end meeting
18:02:32 <LouisF> actually not
18:02:34 <amotoki> cathy_: please end the meeting
18:02:37 <cathy_> worry I am disconnected
18:02:41 <LouisF> bye
18:02:46 <cathy_> #endmeeting