14:00:01 <igordcard> #startmeeting network_common_flow_classifier
14:00:02 <openstack> Meeting started Tue Apr  4 14:00:01 2017 UTC and is due to finish in 60 minutes.  The chair is igordcard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:05 <openstack> The meeting name has been set to 'network_common_flow_classifier'
14:00:08 <igordcard> hi all
14:00:12 <igordcard> let's wait 2 minutes for people
14:00:17 <davidsha> Hi
14:00:26 <igordcard> hi davidsha
14:01:18 <bcafarel> hi folks
14:01:23 <igordcard> hi bcafarel
14:01:26 <davidsha> bcafarel: Hey
14:01:39 <igordcard> how's the weather bcafarel ?
14:02:35 <igordcard> tmorin offline, others in the fwaas meeting
14:02:45 <igordcard> pcarver: ping
14:02:46 <bcafarel> igordcard: almost good enough to attend the meeting outside :) (but almost)
14:02:55 <reedip> o/
14:03:01 <igordcard> hi reedip
14:03:16 <bcafarel> tmorin was in US time zone last week, maybe coming back home
14:03:23 <reedip> hi all ...
14:03:37 <bcafarel> hello reedip
14:03:52 <davidsha> reedip: hey
14:04:10 <igordcard> alright
14:04:13 <igordcard> agenda:
14:04:15 <igordcard> https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Discussion_Topic_4_April_2017
14:04:37 <igordcard> #topic PoC status
14:04:54 <igordcard> davidsha has published the PoC about 3 weeks ago
14:04:57 <igordcard> #link https://review.openstack.org/#/c/445577/
14:05:01 <igordcard> I'm slowly reviewing it but should finish soon
14:05:03 <igordcard> one thing I'd like to ask is for some quick instructions on how to deploy it
14:05:06 <igordcard> I only tried pointing at the devstack plugin, but stacking failed and I moved on
14:05:51 <davidsha> igordcard: you just need to add it to the list of service plugins I think, give me 1 sec
14:06:17 <igordcard> np, add some info to the commit message perhaps
14:06:31 <davidsha> ack
14:06:36 <igordcard> it might also be failing because of the recent neutron commits
14:06:48 <igordcard> hi tmorin
14:07:06 <tmorin> hi igordcard, hi eveyrone
14:07:25 <davidsha> kk, I'll need to fill out the other resource types and put in the classification groups.
14:07:32 <reedip> you need to consider the neutronlib migration as well , I think thats what davidsha is pointing to
14:07:34 <davidsha> hi tmorin
14:07:43 <igordcard> tmorin: you didn't lose much: http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2017/network_common_flow_classifier.2017-04-04-14.00.log.txt
14:07:50 <tmorin> hi davidsha :)
14:08:36 <igordcard> davidsha: so the PoC has some initial Classification Types
14:08:37 <reedip> morning tmorin
14:08:42 <tmorin> hi reedip
14:08:48 <igordcard> davidsha: and not grouping yet , right?
14:09:11 <davidsha> igordcard: IPV4 is the only one that works in PoC
14:09:29 <igordcard> davidsha: OK
14:09:47 <igordcard> davidsha: API, CLI, service plugin all there as far as I understand
14:10:20 <davidsha> igordcard: yup, I may remove the neutron client stuff once I get the Openstack client stuff working.
14:10:30 <igordcard> davidsha: I have some pending comments, I'll drop them now on the review and do a deeper review later
14:11:01 <davidsha> kk, there is also RPC stuff so l2-extensions can retrieve the classifications using the id
14:11:25 <igordcard> davidsha: oh right, the RPC conversation is an interesting one
14:11:44 <igordcard> which should be addressed in the spec too
14:11:48 <igordcard> I'll add a TODO there
14:13:12 <davidsha> If you guys get the chance it would be great to get your feedback on the PoC: https://review.openstack.org/#/c/445577/1
14:14:46 <igordcard> alright, anything else regarding the PoC? perhaps someone would like to contribute a Consuming Service PoC :p ?
14:15:41 <davidsha> igordcard: I had started a dscp patch to consume it. but it will need more work.
14:16:06 <igordcard> great davidsha
14:16:10 <igordcard> moving on...
14:16:13 <igordcard> #topic Live discussion of some of the spec's pending debates
14:16:26 <igordcard> #link https://review.openstack.org/#/c/333993/
14:16:47 <igordcard> this is the spec, your feedback is highly valuable so make sure to review it
14:17:36 <igordcard> there are certain pending questions/debates and, unless someone gets there and provides alternative solutions, the solutions that we are converging to will become final decisions
14:17:58 <tmorin> davidsha: I'll put it on my list, but not promising when I'll have a look
14:17:59 <igordcard> so let's start with the question of validating classifications
14:18:08 <davidsha> tmorin: thanks
14:18:48 <igordcard> we are trending towards not having any kind of classification validation at the CCF side
14:19:04 <igordcard> (except basic attribute checking, of course)
14:19:33 <igordcard> it will be up to Consuming Services to validate before consuming, and where and how they do it is completely out of scope
14:20:12 <tmorin> I already commented on the spec: +1 to that
14:20:16 <igordcard> I'll give you a couple of minutes to comment here, I understand some people are also watching or participating on the fwaas meeting
14:20:33 <reedip> :)
14:21:01 <reedip> yeah igordcard  : I think I will review the spec once more ( I saw it some days earlier but havent seen the latest iteration )
14:21:32 <igordcard> I hope to submit a new version this week
14:22:04 <igordcard> alright, let's move on to the question of grouping classifications together
14:23:34 <igordcard> we have 2 main possibilities right now: AND grouping only or AND/OR/NOT as defended by ihar
14:24:22 <igordcard> I'd prefer not to start with fully fledged AND/OR/NOT yet, and I'm not sure existing potential Consuming Services need that
14:25:01 <reedip> igordcard, but we need to ensure that we dont push ourselves to a corner with AND :)
14:25:24 <igordcard> reedip: yeah... the data model should be almost AND/OR/NOT -compatible
14:25:55 <igordcard> reedip: a small change and api extension should make it possible to enable AND/OR/NOT
14:26:32 <reedip> igordcard : it would be best if we can do the change before the official P release , just saying to avoid migration:)
14:26:56 <igordcard> I'll think a bit more about how much work is truly needed to support AND/OR/NOT from day one, if it isn't that much let's do it - before the official P release yeah
14:28:42 <reedip> :)
14:28:45 <igordcard> the spec doesn't yet specify anything about classification groups, but the next patchset will
14:28:57 <igordcard> let's move on to the question of having special "modifiers" as part of the classification resource
14:29:19 <igordcard> the trend seems to be to not having modifiers
14:29:35 <igordcard> making it out of scope and have the CSs add their own modifiers
14:29:50 <davidsha> igordcard: as in update existing classifications?
14:30:28 <igordcard> so a modifier would be something common to the whole Classification
14:30:39 <igordcard> instead of a type-dependent attribute
14:30:42 <igordcard> like a direction
14:30:53 <davidsha> igordcard: kk, ack
14:31:02 <igordcard> Classification X: type:{def}; direction; other-modifier;...
14:31:41 <igordcard> but then it also begs the question: is a modifier compatible with any possible type defined?
14:33:06 <igordcard> hi ralonsoh
14:33:32 <davidsha> igordcard: in the direction example I don't believe so, particularly when some of the classification have explicit source and destination addresses
14:33:34 <tmorin> igordcard: sorry for the delayed answer: I think the spec could describe the fullfledge AND/OR/NOT-compound groups, but that we can then give a lower priority to implementing OR and NOT and "recursivity" in compound groups
14:35:59 <igordcard> tmorin: alright, I'll investigate that further.. I'm concerned that it might significantly impact the implementation, and delay
14:36:09 <igordcard> davidsha: yeah that's an example
14:36:45 <tmorin> igordcard: the real question is whether or not we can delay the implementation of the fullfledged combination
14:37:32 <igordcard> tmorin: if the delay is between ccf v1 and ccf v2, it's fine but we'll have an api extension just for that
14:38:08 <igordcard> v1 is aimed at Pike
14:39:05 <igordcard> if there are no further requests about modifiers/common attributes, I'll make that explicitly out of scope
14:39:10 <tmorin> igordcard: I don't know, perhaps this needs to be discussed: even if we implement the fullfledged version in v1,  if no consuming service supports it, then there is no value for API users to have advertised that we support the fullfledged version  => hence, why would we have to advertise support for the fullfledged version with an additional api extension ?
14:40:20 <tmorin> I think we might perhaps fully specify the fullfledged, implement only a part of it, and initially no consumer will support it
14:40:21 <igordcard> tmorin: exactly, makes sense... so either do it all in v1 or wait until the "need"
14:40:34 <tmorin> yes
14:41:03 <igordcard> tmorin: implement only a part of it?
14:41:17 <tmorin> the real relevant question for users in terms of exposing what is supported is whether a given type of classification or compound is supported by consumer service foo
14:41:27 <tmorin> and this can't be done with a simple API extension anyways
14:41:49 <tmorin> igordcard: yes, the part of it initially implemented would be AND-compound
14:42:25 <igordcard> tmorin: yes, in the end it's the CS's responsibility to support a certain set of classification capabilities
14:42:43 <igordcard> independently or with the help of CCF
14:43:29 <igordcard> tmorin: but if you only implement part of the API, why have a fully fledged API? non-AND composition calls would fail
14:44:34 <tmorin> igordcard: yes, but if no consumer service supports them, this is fine, right ?
14:44:54 <igordcard> tmorin: oh yes, sure
14:45:34 <igordcard> they can add support whenever they want, no CCF changes would be necessary
14:47:29 <igordcard> #action igordcard to investigate AND/OR/NOT modeling and potential issues
14:47:35 <igordcard> let's move on
14:47:42 <igordcard> any other things we have to debate and attempt to reach consensus?
14:49:25 <igordcard> next spec will be highly trimmed
14:50:03 <igordcard> focus/scope on the ccf specifically
14:50:39 <igordcard> what consuming services do essentially out of scope
14:51:29 <igordcard> it will also have a single answer for each of the 3 pending debates and, unless there's disagreement, we'll go with those answers for the implementation
14:51:39 <igordcard> the and/or/not grouping is the toughest to decide
14:52:21 <igordcard> there's also ihar's very important suggestion:
14:52:29 <igordcard> - governance matters (where the code goes, who is in the review and development team)
14:53:23 <davidsha> igordcard: ajo is leaving neutron, vikram and sean collins are the other 2 core reviewers in neutron classifier I believe
14:53:57 <igordcard> davidsha: right and that leads me to
14:54:18 <igordcard> davidsha: you mentioned not much code is being reused form the neutron-classifier on the PoC
14:54:44 <davidsha> igordcard: basically no code is reused.
14:55:09 <igordcard> davidsha: unless it's potential that a big portion of the code can be reused, I'd prefer to create a new repo
14:55:25 <igordcard> davidsha: or we would have to wipe the current on in neutron-classifier... which doesn't make much sense
14:56:39 <davidsha> igordcard: It's a repo that's already approved though. I'm not sure how long will it take to get a new one.
14:57:06 <igordcard> davidsha: we can work on the code while we wait for approval tho
14:57:25 <igordcard> davidsha: also neutron-classifier is not governed
14:57:32 <igordcard> in any way
14:57:51 <igordcard> and I believe that's the most critical question... how is the governance going to be?
14:58:55 <davidsha> what do you mean?
14:59:19 <igordcard> davidsha: exactly, I'll chat to ihar about this
14:59:22 <igordcard> #action igordcard to talk about governance with ihar
14:59:33 <igordcard> alright people, we're done for today!
14:59:34 <igordcard> bye all
14:59:38 <igordcard> #endmeeting