17:00:22 <igordcard> #startmeeting network_common_flow_classifier
17:00:23 <openstack> Meeting started Tue Nov 22 17:00:22 2016 UTC and is due to finish in 60 minutes.  The chair is igordcard. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:27 <openstack> The meeting name has been set to 'network_common_flow_classifier'
17:00:31 <igordcard> hi all
17:00:34 <igordcard> let's wait 3 minutes to improve the chances of everyone being around
17:00:43 <davidsha> Hi
17:01:14 * njohnston lurks
17:02:43 <davidsha> njohnston: How are you?
17:03:23 <igordcard> agenda:
17:03:27 <igordcard> #link https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Discussion_Topic_22_November_2016
17:03:36 <igordcard> I'll start with the OVS Flow Manager today
17:03:42 <igordcard> #topic OVS Flow Manager: new patch available at https://review.openstack.org/#/c/323963/
17:03:46 <igordcard> #link https://review.openstack.org/#/c/323963/
17:04:07 <davidsha> Reviews are appreciated!
17:04:52 <igordcard> ;) I'm hoping to have a look at it, been a while since the last time I checked it
17:05:10 <igordcard> do you want to discuss something about the flow manager in general?
17:05:53 <njohnston> /msg davidsha Doing all right, not allowed to work on OpenStack as much now... which makes me sad.
17:06:07 <davidsha> igordcard: There isn't much really, that patch is basically a new version of the flow manager divorced from the agent extensions API
17:08:07 <igordcard> alright
17:09:39 <igordcard> keep the code and the reviews flowing!
17:09:47 <igordcard> moving on...
17:10:08 <igordcard> common classification framework
17:10:11 <igordcard> #topic We have converged to Approach 2 at https://review.openstack.org/#/c/333993/
17:10:20 <igordcard> #link https://review.openstack.org/#/c/333993
17:11:05 <igordcard> at the summit meeting we converged to approach 2
17:11:31 <igordcard> as such, I've now deleted approach 1 and 3 from the spec so we can focus on improving approach 2
17:12:08 <davidsha> igordcard: cool, I was reading over it earlier and left a couple of comments.
17:12:28 <igordcard> however, we were still uncertain about whether a an API for users should be provided as well, i.e. to define classifications as resources
17:12:44 <igordcard> #topic Should this approach include a user-facing API?
17:13:39 <ralonsoh> Can you elaborate this question?
17:13:45 <ralonsoh> user-facing API?
17:13:54 <ralonsoh> Sorry if this is irrelevant
17:14:12 <njohnston> By "user" do you mean "thing that consumes flow classifier" or "tenant"?
17:14:24 <igordcard> ralonsoh: whether classifications should be tenant API resources, or simply definitions in code that can be reused and extended by neutron projects
17:14:44 <igordcard> njohnston: tenant
17:14:50 <ralonsoh> igorcard: thanks
17:15:16 <njohnston> I vote the latter; if multiple things use flow classified then a tenant could get confused
17:15:16 <igordcard> ralonsoh: nothing is irrelevant :)
17:16:28 <igordcard> the latter is developer-friendly, while the former tries to be user-friendly as well, in an attempt to have users define their own classifications (within the scope of what the framework supports at a certain release)
17:16:50 <davidsha> By the later you mean API extensions through Mixins? The former would need to be a service plugin correct?
17:18:01 <njohnston> Let's say FWaaS and SFC both use the classifier. I would rather have them define things in FWaaS and SFC and have those manage the classifier behind them.
17:18:37 <njohnston> As an example
17:19:19 <davidsha> njohnston: that's the plan, the hope is it's all back end agnostic. This is just deciding weather the extensions consume to individual values or a reference to a classifier resource to extract values from.
17:20:03 <igordcard> njohnston: In the tenant API approach, FWaaS and SFC can still manage the classifier but the classification definition would come from an ID, essentially
17:20:13 <igordcard> davidsha: right
17:21:36 <davidsha> with the later you could keep reusing the same classifiers across multiple extensions.
17:22:11 <davidsha> later for what I said*
17:22:39 <njohnston> Latter?
17:22:58 <davidsha> "a reference to a classifier resource to extract values from."
17:23:44 <igordcard> for the sake of clarity, let's call the approach with the API resources "resource-based" and the one without API "definition-based"
17:24:33 <davidsha> +1
17:24:54 <igordcard> I also recommend a distinction between classification and classifier, if you agree
17:25:39 <davidsha> Sure, but I'm prone to mixing them up :P
17:25:43 <igordcard> classification as whatever refers to a traffic classification/kind, and classifier as the component that evaluate the classification of the traffic
17:25:51 <njohnston> I am fine with either, as long as: if a tenant wants to modify an existing resource it is never ambiguous the use that resource is being put to. So they don't change an SFC-consumed classification when they meant to change an FWaaS-consumed classification.
17:26:43 <njohnston> Just because this is uncommonly abstract of a thing for a tenant to have to deal with. Abstraction makes sense for developers, not for many customers.
17:27:34 <davidsha> njohnston: That's a good point, but it would be similar to modifying QoS Rules then, they would need to define a new classification for the single instance they want to change.
17:27:46 <igordcard> njohnston: a fair concern.. I would vote for a non-updatable classification resource
17:29:44 <njohnston> +1
17:30:33 <davidsha> +1
17:30:54 <igordcard> let me echo davidsha's question
17:31:36 <davidsha> From the Summit?
17:32:06 <igordcard> how would we do the definition-based approach? though mixins applied to each neutron extension that wants to supports classifications?
17:32:14 <igordcard> s/though/through
17:32:44 <davidsha> It was to add mixin classes to neutron-lib or neutron classifier and just have extensions include them in their service plugins and extend their backends.
17:35:45 <davidsha> the problem with it is that long detailed classifications would need to be repeated for all the extensions that needed it enabled, it also has the extensions database classes extending to hold all the possible classifications
17:37:40 <igordcard> right, the different projects would mirror the classifications structures within their local tables
17:37:56 <davidsha> exactly
17:38:10 <igordcard> so every project would have to sync immediately with new versions of the classifications structures?
17:39:03 <davidsha> igordcard: not if the classification types were broken into different mixins
17:39:46 <njohnston> If there is a case for new version upgrades, would they be versioned?
17:41:28 <igordcard> davidsha: I see.. but then it would be a "mixin spaghetti"
17:41:47 <davidsha> njohnston: They would probably need to be, but the idea is that the different types would be static.
17:42:20 <davidsha> you have a mixin for IPv4, IPv6, NSH, etc...
17:45:33 <igordcard> alright, we have a good deal of info here to help us decide on the spec, I'm moving to the next topic now (still related) while we have time
17:45:38 <igordcard> #topic Completing the spec and starting the code
17:46:03 <igordcard> what do both approaches have in common?
17:46:40 <igordcard> can we start working on openstack/neutron-classifier to provide the foundation for classification, either exposed as resources or not?
17:46:48 <davidsha> igordcard: almost nothing, resource based requires a service plugin and definition based requires mixins
17:48:29 <igordcard> I will update the spec to clarify the resource-based approach and will add my understanding of the definition-based approach
17:48:50 <igordcard> will greatly appreciate feedback njohnston davidsha
17:49:07 <igordcard> and ralonsoh
17:49:13 <davidsha> ack
17:49:16 <ralonsoh> sure!
17:49:42 <igordcard> also feel free to submit a patchset providing more info njohnston
17:49:58 <igordcard> we can then attempt to converge to an approach, in gerrit
17:50:23 <njohnston> +1
17:50:26 <davidsha> +1
17:50:40 <igordcard> alright, moving on..
17:50:40 <igordcard> #topic Repo: new repo or neutron-classifier repo?
17:51:47 <davidsha> Just stick to neutron-classifier is my vote
17:52:27 <njohnston> what would be the advantage of a new repo?
17:52:32 <igordcard> I expect most of it would have to be rewritten, in either approach
17:53:22 <igordcard> so starting freshing is potentially cleaner, but reusing the neutron-classifier keeps the ecosystem less fragmented
17:53:43 <igordcard> I'm voting to stay on neutron-classifier as well
17:54:38 <njohnston> will this end up being packaged into a separate pypi module, like neutron-lib?
17:55:15 <davidsha> njohnston: don't think there is an advantage, presumably yes.
17:56:04 <davidsha> njohnston: but the service plugin approach would make it like any other extension.
17:56:26 <njohnston> ok
17:56:44 * njohnston thinks staying with neutron-classifier is wiser
17:57:08 <igordcard> which raises the issue of dependency between projects
17:57:25 <igordcard> moving on...
17:57:26 <igordcard> #topic Open discussion
17:57:56 <igordcard> * between extensions
17:58:09 <igordcard> anything else we need to discuss?
17:58:40 <davidsha> don't think there is enough time unfortunately.
17:59:10 <igordcard> next meeting is expected in 2 weeks, but until then get your thoughts onto the spec!
17:59:40 <igordcard> thanks everybody, cya all
17:59:42 <igordcard> #endmeeting