14:01:14 <igordcard> #startmeeting network_common_flow_classifier
14:01:14 <openstack> Meeting started Tue May 30 14:01:14 2017 UTC and is due to finish in 60 minutes.  The chair is igordcard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:18 <igordcard> hi all
14:01:19 <openstack> The meeting name has been set to 'network_common_flow_classifier'
14:01:27 <davidsha> Hi
14:01:58 <igordcard> agenda: https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_30_May_2017
14:02:14 <hai_shi> Hi
14:02:43 <igordcard> hi hai_shi
14:02:49 <igordcard> hi davidsha
14:03:27 <igordcard> hai_shi: interested in the CCF?
14:03:34 <bcafarel> hello
14:03:39 <igordcard> hi bcafarel
14:04:10 <igordcard> alright let's dive in
14:04:18 <igordcard> #topic Closing the spec
14:04:42 <igordcard> the newly-submitted v16 spec: https://review.openstack.org/#/c/333993/16
14:05:25 <igordcard> (neutron-specs is kinda broken, sphinx dependency has to be capped at <1.6.1, will probably submit a patch to fix it soon)
14:06:04 <igordcard> anyway, we didn't have any critical issues or critical requests on the v15 spec
14:06:39 <igordcard> so I'd say we have enough agreement on the spec now and it can now be reviewed with the goal of merging
14:06:51 <davidsha> ack
14:07:34 <igordcard> like I talked with kevinbenton at the summit, I will now request him to give rights to the neutron-classifier repo
14:07:57 <igordcard> so we can start submitting and merging code
14:09:07 <bcafarel> nice
14:09:17 <igordcard> this is it, really
14:09:25 <igordcard> any questions?
14:10:10 <davidsha> cool, I'm good.
14:10:22 <igordcard> moving on...
14:10:32 <igordcard> #topic Access to the repository
14:10:49 <igordcard> well I've kinda addressed this topic already
14:11:13 <igordcard> going to ask for access to neutron-classifier, start commiting code and building the team from there
14:11:29 <igordcard> a first commit will "wipe" the existing neutron-classifier code
14:11:44 <igordcard> moving on...
14:11:48 <igordcard> #topic Open discussion
14:12:04 * bcafarel has his coffee ready for open discussion
14:12:30 * igordcard was exactly wondering if everybody had their coffees ready
14:12:45 <davidsha> So the first commit is just to wipe the repo correct?
14:13:05 <igordcard> davidsha: yep I think that's the safest
14:13:31 <igordcard> davidsha: so we don't swim in the old code
14:14:08 <davidsha> igordcard: ack, I suppose a deprecation period isn't necessary because there has never been a release of classifier
14:14:33 <igordcard> davidsha: exactly, as far as I understand it was a PoC
14:14:39 <davidsha> kk
14:15:05 <bcafarel> will the wipe pass the current gates for the repo?
14:15:42 <igordcard> we got some inspiration from that PoC, and we've credited them in the spec, but with a whole new codebase for it, there's no point in keeping the old code laying around the new code
14:16:09 <davidsha> bcafarel: Hopefully!
14:16:12 * igordcard removes the last comma
14:16:59 <igordcard> bcafarel: it might be a soft wipe, as in wipe everything PoC-specific, but keep what makes it an openstack repository
14:18:02 <bcafarel> igordcard: or even full wipe+cookiecutter, this should be enough for the generic gates
14:18:26 <igordcard> bcafarel: yep I'm not the most familiar with cookiecutter (yet), but that sounds about right from what I've heard/seen
14:19:42 * igordcard waves to reedip_
14:19:47 <davidsha> Will we need to look into expanding the test cases in neutron-classifier as well through the governance repo?
14:19:49 <reedip_> hi
14:19:52 <reedip_> just joined in
14:19:55 <reedip_> traffic ....
14:19:59 <davidsha> reedip_: hey
14:20:01 <reedip_> need to catch my breath
14:20:51 <igordcard> davidsha: for now the repo will be ungoverned so we can technically do whatever we want, but we should aim towards being compliant to then become neutron stadium or maybe neutron-lib
14:21:40 <davidsha> ack
14:22:10 <igordcard> the effort required to make the ccf compliant, and to maintain it over time, has to be evaluated and we have to know who is willing to participate on that
14:22:35 <igordcard> but for now let's just get an initial version out, then work on 1 or 2 consumer PoCs
14:23:39 <davidsha> kk, I'll try to work out a QoS one, when I get the chance.
14:25:08 <bcafarel> and I still hope to find some time to do one for SFC
14:25:46 <igordcard> great, great
14:26:04 <davidsha> bcafarel: sfc will be tricky won't it, you'll need to maintain support for the flow classifier plugin also correct?
14:27:58 <bcafarel> davidsha: indeed, I will probably try to parse the ccf first, then add local parameters (if any)
14:28:13 <bcafarel> not sure if it will be the end method, but for a POC it would be enough
14:28:33 <bcafarel> and for the demo only use ccf :)
14:29:33 <davidsha> bcafarel: ack, make sure to link me in the patch!
14:30:20 <bcafarel> davidsha: sure will :)
14:30:27 <igordcard> hmm the flow classifier plugin isn't needed for the sake of being needed
14:30:42 <igordcard> it's simply what the project has for defining traffic classifications
14:30:56 <davidsha> igordcard: it would need to be deprecated over a release though.
14:31:03 <igordcard> having said that, it should have a deprecation period
14:31:11 <igordcard> yes
14:31:57 <igordcard> the main sfc API (including create-port-chain --flow-classifier UUID) could be kept completely unchanged
14:32:10 <igordcard> but the UUID would internally come from a different source
14:32:18 <igordcard> the problem is that the flow classifier API is also being used
14:33:05 <igordcard> bcafarel: maybe we could make the sfc plugin lookup classifications in both the flow classifier tables and in the CCF? and have the flow classifier API as deprecated
14:33:13 <davidsha> igordcard: you could try with the flow classifier api and catch the exception if the ID doesn'thave a FC db entry.
14:33:46 <davidsha> then try classifier.
14:33:53 <igordcard> bcafarel: or change both APIs so that port-chain can choose either --flow-classifier or --classification-group, each would lookup in a different place
14:34:08 <igordcard> davidsha: yeah also
14:34:38 <bcafarel> hmm I like the general idea yes!
14:35:03 <bcafarel> both cases that leaves the existing flow classifier alone, which is simpler
14:35:09 <igordcard> but yeah for PoC is fine, the rest should be with the networking-sfc team and the neutron-lib experts
14:36:57 <igordcard> alright great people, I think this is it
14:37:13 <igordcard> thanks for coming
14:37:20 <davidsha> Thanks, cya!
14:37:36 <igordcard> I'm going to pursue access to the repo now, cya in gerrit!
14:37:40 <bcafarel> next meeting, we have a repository? ;)
14:37:51 <davidsha> +1
14:37:52 <igordcard> bcafarel: yesss
14:38:05 <igordcard> #endmeeting