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