14:00:02 #startmeeting network_common_flow_classifier 14:00:07 Meeting started Tue Jul 25 14:00:02 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:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:11 The meeting name has been set to 'network_common_flow_classifier' 14:00:16 hi all 14:00:54 hey igordcard 14:03:34 give me 4 minutes, as I have to change rooms, thanks 14:04:34 that's a big building :) 14:05:55 back 14:06:05 alright, agenda: 14:06:12 https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_25_July_2017 14:06:23 #topic CCF v0 - first wave of code 14:08:02 so the plan was to submit the code before pike-3 14:08:49 like, in 2 days? 14:09:18 david and thaynara are trimming a few rough edges and will submit the code by the end of the day 14:09:59 one thing it will not have is consistency with the API endpoints defined in the spec, yet 14:11:16 but most of the rest will be aligned already 14:12:14 david, what other info have you got? 14:13:52 Ya, It has the Ethernet, IPv4, IPv6, TCP and UDP. The problem with API inconsistency was that I made a resource for each one instead of specifying a type in a "Classification" resource. 14:14:21 so /classifications vs. /ipv4_classification and all the rest 14:14:40 The other way around, but yes 14:15:28 I'll submit the incorrect version just so people can see and test the general idea, and try to have the correct version up asap. 14:15:35 yes, current state is latter example right? 14:15:41 yes 14:16:42 so most of the parts will be the same except how the resources are expressed in the API right? 14:19:01 Yes, I'm not sure over internal database stuff will I make a generic "classification" object and make it the same as the API or actually store them in different tables based on type. 14:20:38 But this probably isn't so important if everything will be retrieving classifications through the API rather than accessing it directly. 14:21:38 in terms of tables the schema from the spec should work with both API approaches 14:22:07 ack, then it's fine as it is. It's just translate the new API on top of it. 14:22:09 and then at the API you'll have a generic classification object 14:22:11 or resource* 14:22:38 kk, cool. 14:22:54 definition validation will be handled by the plugin instead of the extension 14:24:18 davidsha: after this patch we split in different patches with the different logical pieces 14:24:38 Ya, we're planning on adding a little bit of validation. but just checking that for example an IPv6 address isn't passed into a IPv4 classification. 14:24:49 davidsha: when would those pieces be ready? (this is including the API change work) 14:24:54 davidsha: cool 14:27:05 igordcard: We'll aim for the next meeting. 14:27:20 alright davidsha 14:28:01 meanwhile with the patch from today we can start reviewing and discussing 14:28:04 moving on... 14:28:12 #topic Open discussion 14:28:21 bcafarel's favourite part 14:28:25 * bcafarel gets the coffee ready 14:28:28 :) 14:28:29 I'm actually literally going to get a coffee now 14:28:34 :D 14:29:16 If there are any pastries could someone pass me one.... 14:29:47 Are there any Questions about v0 code? 14:30:18 sadly none from my part, I did not even have the time to open the review :( 14:30:34 only time to +1 igordcard's repo cleanup commit 14:31:03 bcafarel: the code isn't there yet :p 14:31:09 Someone submitted an RFE for security groups and the neutron drivers recomended they adopt neutron classifier into security groups rather than extending the existing API. 14:31:19 Just as a heads up. 14:31:29 davidsha: was just about to link it here 14:31:34 https://bugs.launchpad.net/neutron/+bug/1690921 14:31:34 Launchpad bug 1476527 in neutron "duplicate for #1690921 [RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor Duarte Cardoso (igordcard) 14:32:19 generally the CCF looks enough to achieve this 14:32:37 igordcard: ah that's why :) (I was thinking about the current poc review) 14:32:43 but depending on the very specifics of the use case there might a shortcoming or two 14:33:01 nice, that could mean more people here (with interest on security groups) 14:33:04 so I'll conttinue to follow this discussion 14:34:08 bcafarel: yeah, more people from SG here would be good, to get some info about their plans and what it would take / and how long, to migrate to CCF 14:34:14 igordcard: Did you take up the task to actually implement the consumption of classifications in security groups? 14:35:00 we can also start having conversations with them, but the focus now is to wrap up v0 and then start doing incremental changes and open the window for enhancements 14:35:50 davidsha: no, why? 14:36:42 igordcard: you marked yourself an assignee 14:37:26 davidsha: that's the original common classifier RFE, you're looking at the wrong link 14:37:46 igordcard: Oh, moving on! 14:38:44 actually not sure whether that origianl RFE should be closed by now... 14:38:56 ihar created a blueprint specifically for the CCF some time ago: 14:39:20 https://blueprints.launchpad.net/neutron/+spec/common-classification-framework 14:39:39 but armax marked the SG RFE as duplicate of the original CCF RFE 14:39:52 Ya 14:40:17 probably too early in the morning for you armax, but if you're there do you think the RFE should be closed? 14:41:15 igordcard: which one? 14:41:28 https://bugs.launchpad.net/neutron/+bug/1476527 14:41:28 Launchpad bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor Duarte Cardoso (igordcard) 14:41:45 armax: taking into account that this was created recently: https://blueprints.launchpad.net/neutron/+spec/common-classification-framework 14:42:11 armax: comment from RFE link: https://bugs.launchpad.net/neutron/+bug/1476527/comments/38 14:42:51 the RFE would close as released when there’s something being released, no? 14:43:40 armax: makes sense, was just wondering if it was still needed with the blueprint created to track the progress 14:44:50 armax: thank you; we are in open discussion, let us know if you have any question about ccf 14:45:05 the state change happens on its own typically once there’s a patch that markes the bug to be closed 14:46:58 armax: halright.. so the plan is to have an initial version soon, but the first consumable version only by Queens - that means the final Closes-Bug patch would be by Queens only correct? 14:47:30 yeah, I would think so 14:47:39 armax: perfect, thanks 14:48:34 any other questions? 14:49:39 I'm good 14:50:05 alright folks, this is all 14:50:20 thanks! 14:50:24 I actually got tea instead of coffee, but that should count too bcafarel? 14:50:30 bye all 14:50:33 :) 14:50:43 igordcard: I will think about it until next time 14:50:56 okay bcafarel! 14:51:04 #endmeeting