17:00:09 <igordcard> #startmeeting network_common_flow_classifier
17:00:10 <openstack> Meeting started Tue Feb 28 17:00:09 2017 UTC and is due to finish in 60 minutes.  The chair is igordcard. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:14 <openstack> The meeting name has been set to 'network_common_flow_classifier'
17:00:37 <igordcard> hi davidsha, all
17:00:44 <davidsha> Hi
17:00:49 <igordcard> let's wait 2 minutes for people
17:00:52 <davidsha> kk
17:02:03 <reedip> \o/
17:02:10 <reedip> though I am a bit sleepy ...
17:02:30 <igordcard> hi reedip
17:02:38 <reedip> hi igordcard
17:02:49 <reedip> hi davidsha
17:03:06 <davidsha> Hey reedip!
17:03:18 <igordcard> alright, let's kick this off!
17:03:25 <igordcard> #link https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Discussion_Topic_28_February_2017
17:03:30 <igordcard> #topic Post-PTG summary
17:04:02 <igordcard> more people became interested in this effort during the PTG
17:04:22 <igordcard> the spec got more reviews since then
17:04:42 <igordcard> #link https://review.openstack.org/#/c/333993
17:05:03 <igordcard> I'm correcting it and will submit a new patchset today or tomorrow
17:05:22 <igordcard> there seemed to be good agreement on the current approach
17:05:48 <reedip> I would be pushing it in the TaaS meeting , hopefully I can get some more people from Tap-as-a-Service to review this
17:06:05 <igordcard> reedip: great!
17:06:22 <davidsha> Thanks!
17:06:39 <igordcard> also, there was some discussion regarding the grouping of classifications
17:07:29 <igordcard> we didn't reach an agreement on how and in what way, but we seemed to agree that some grouping should be provided (from day one of the first CCF release)
17:08:13 <igordcard> some kind of validation of classificatons (when applied to consuming services) needs to occur, and the framework might even do part of it itself - more discussion needs to happen around this subject as well
17:08:17 <reedip> yeah , as well as the proposal on how to group them ( AND / OR )
17:08:34 <igordcard> reedip: exactly
17:09:02 <igordcard> there was good agreement that there is no need allow classification updates
17:09:18 <igordcard> and we seemed to be converging to a workflow where classifications shouldn't be deleted if they are being used - which also prevents duplication of information in the database, as a simple mapping between classifications and the consuming project's own resources, is enough
17:10:02 <igordcard> am I missing something important?
17:10:24 <reedip> CLI side ??
17:11:03 <igordcard> reedip: in regards to the validation of classifications?
17:11:05 <reedip> I mean the CLI based implementation was also discussed  and IIRC it was decided that CLI side implementation would be project dependent
17:11:15 <reedip> igordcard : umm, yup
17:11:44 <davidsha> reedip: You mean if a project supports a particular classification?
17:12:00 <igordcard> reedip: yes/no... so each project will have to make their own CLI changes to allow users to pass on classifications UUIDs
17:12:12 <igordcard> reedip: but still the CCF needs its own CLI to define the classifications
17:15:09 <reedip> davidsha ,igordcard : the problem / issue is when we use a common classifier with a project
17:15:29 <reedip> whose CLI needs a specific value ( which is a positional argument )
17:15:49 <reedip> but by linking the common classifier , the CLI can retrieve this information from the classified
17:16:31 <reedip> davidsha, igordcard : something like Network attribute for Subnets
17:16:38 <igordcard> reedip: right, that was the discussion on how/whether CLI should itself fetch the classification and validate it before passing it to the own project
17:16:41 <reedip> we cannot create a subnet without a network
17:17:20 <igordcard> right
17:17:22 <reedip> igordcard : there is a side-effect of common classifier with OpenstackClient 's implementation
17:18:07 <reedip> TL;DR , we need to modify the CLIs so that attributes which can be considered in a common classifier need to be made optional arguments in CLI
17:18:45 <reedip> in case they are NECESSARY in the current iteration
17:19:57 <igordcard> reedip: wait, does this also relate to the discussion where projects might already have their own "classifier APIs", and so the use of the CCF is optional or possible conflicting?
17:20:49 <reedip> igordcard : umm, I didnt consider it yet. This discussion was in terms of CLI implementation and modification.
17:21:05 <reedip> igordcard ; What I am saying is changes in the OSC project
17:21:22 <reedip> igordcard; your changes may be more in neutron-xyz projects
17:21:53 <igordcard> reedip: changes in the OSC project beyond the plain support of classifications UUIDs in neutron-xyz's resources?
17:22:28 <igordcard> reedip: in other words, networking-sfc's port-create CLI command allows --flow-classifier UUID to be passed...
17:23:12 <igordcard> reedip: would there be any change to that specific command after the CCF?
17:23:38 <xgerman> o/
17:23:48 <igordcard> (this is an example where a project already has a way to pass in classificatin UUIDs / other projects may not have this yet)
17:23:55 <igordcard> hi xgerman
17:23:57 <reedip> xgerman : Hi ( again )
17:25:02 <davidsha> xgerman: Hey
17:25:05 <reedip> igordcard : not for Networking-sfc project maybe . Because the flow-classifier is not a common classifier/attribute across different APIs ( is it ?)
17:25:18 <igordcard> reedip: visual clarification: "port-create --flow-classifier <UUID> my-port-chain"
17:27:53 <igordcard> reedip: alright, so is it fair to say that OSC will require the following changes? :
17:28:11 <igordcard> - OSC classification CRUD commands
17:28:53 <igordcard> - OSC classification consumption commands (in networking-sfc's example fashion above) per neutron-xyz/networking-abc/others project
17:30:08 <davidsha> Will we move on?
17:30:33 <igordcard> it's only been 2 minutes, he might still be typing
17:30:48 <reedip> igordcard : yes you are correct. But I think we need to discuss this once with dtroyer and the osc team :)
17:30:57 <davidsha> kk, sorry!
17:31:01 <reedip> davidsha : I am also discussing other bugs  in the OSC team :D
17:31:21 <reedip> sorry davidsha : took some time !
17:31:23 <igordcard> reedip: thanks, I will note that
17:31:44 <igordcard> anything else in terms of PTG summary?
17:31:58 <reedip> none that I recall
17:32:10 <igordcard> moving on...
17:32:13 <igordcard> #topic PoC status
17:32:27 <davidsha> reedip: no problem!
17:32:32 * igordcard hands over the mic to davidsha
17:33:57 <davidsha> So I have the resources made, the service plugin working, and it storing the classifications in a database. I'm working on the rpc server/client so that the classifications can be retrieved from the neutron classifier project.
17:34:49 <igordcard> davidsha: great
17:34:51 <davidsha> Once I get the RPC stuff working I'll realign the PoC to match the updates that are being added to the spec.
17:34:59 <reedip> +1 :)
17:35:01 <igordcard> cool
17:35:41 <igordcard> moving on...
17:35:44 <igordcard> #topic Next steps for the CCF
17:36:19 <igordcard> #action igordcard to address comments in spec
17:36:50 <igordcard> should we contact the OSC team at this point?
17:37:50 <davidsha> igordcard: Maybe wait until we can show them the PoC.
17:38:39 <igordcard> yeah.. if it pops up in a conversation great, otherwise let's get this a bit more refined, both spec and code, for now
17:39:12 <igordcard> #action davidsha to submit an initial PoC
17:39:30 <davidsha> ack
17:40:59 <igordcard> other next steps seem to be: clarifying the CLI, including if validation should be done there (there are 4 possibilities, which I'll document in the spec); and reach consensus on the grouping of classifications
17:41:16 <igordcard> which also has 3 or 4 possibilities
17:41:36 <igordcard> any other next steps?
17:43:02 <igordcard> alright, moving on...
17:43:06 <igordcard> #topic Open discussion
17:43:09 <reedip> igordcard : Lets discuss it with them after the PoC as mentioned by davidsha
17:43:28 <igordcard> alright reedip
17:43:29 <igordcard> anything else we need to discuss?
17:44:59 <reedip> none from my end
17:45:07 <davidsha> Nothing from me.
17:45:12 <igordcard> alright
17:45:42 <igordcard> I will likely not be able to attend/chair the (expected) meeting in 2 weeks
17:46:05 <igordcard> if there aren't critical items to discuss, I will cancel it closer to the date
17:46:17 <igordcard> otherwise a solution will be found!
17:46:40 <igordcard> okay folks, this is all
17:46:46 <davidsha> kk, We'll see anyways on the spec I can chair if people are about.
17:46:52 <igordcard> thank you for joining davidsha, reedip, xgerman
17:47:00 <reedip> :)
17:47:01 <igordcard> davidsha: yep
17:47:04 <davidsha> Thanks!
17:47:08 <reedip> great to meet again u guys
17:47:17 <igordcard> :)
17:47:17 <igordcard> bye
17:47:25 <igordcard> #endmeeting