14:00:38 <davidsha> #startmeeting network_common_flow_classifier 14:00:41 <openstack> Meeting started Tue Oct 17 14:00:38 2017 UTC and is due to finish in 60 minutes. The chair is davidsha. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:45 <openstack> The meeting name has been set to 'network_common_flow_classifier' 14:00:58 <davidsha> Hey everyone! 14:01:17 <bcafarel> howdy davidsha 14:01:47 <davidsha> not too bad, you bcafarel? 14:02:22 <bcafarel> nice summer weather here, I'm not complaining :) 14:04:04 <davidsha> I'll wait 2 mins for the others then we'll start, It's nice weather here now as well, we had a Hurricane yesterday... 14:04:58 <davidsha> And meant to have another big storm on Friday. 14:05:10 <bcafarel> yeah I saw that, looks like it was not a good day to visit Connemara 14:06:10 <davidsha> Yup, looking at the power lines that are down, the damage looks very spread out though 14:06:31 <davidsha> tmorin reedip: ping 14:06:53 <tmorin> davidsha: hi everyone 14:06:56 <tmorin> o/ 14:07:04 <davidsha> Hey 14:07:10 <bcafarel> hi tmorin 14:07:15 <tmorin> hi bcafarel ! 14:07:40 <davidsha> We'll start now 14:07:47 <igordc> hello all 14:07:53 <davidsha> Agenda is here: https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#All_Meetings.27_Agendas 14:08:06 <davidsha> #topic CCF v0 - Update 14:08:31 <davidsha> So The database migration patch looks ready 14:08:52 <davidsha> https://review.openstack.org/#/c/498471/ 14:08:59 <davidsha> #link https://review.openstack.org/#/c/498471/ 14:09:38 <davidsha> Will I can merge the patch or will I ask a neutron core to have a look and have the final approval? 14:09:46 <bcafarel> loosk so, and if needed it can be fixed/updated until there is an "official" v0 14:10:52 <igordc> +1 14:11:06 <davidsha> +1 for neutron core or me? 14:11:26 <igordc> the non-question :p 14:11:33 <igordc> so bcafarel 14:11:37 <davidsha> Ah 14:11:57 <davidsha> So I'll merge it then and we can modify going forward 14:12:29 <davidsha> I'm almost finished updating the follow up patch https://review.openstack.org/#/c/499571/ 14:13:12 <davidsha> I'm going to draft the functional tests separate and submit a patch to infra to enable functional testing and py35 14:13:53 <davidsha> tmorin: have you any tips? 14:14:52 <tmorin> davidsha: I haven't looked at this one for a while 14:15:18 <tmorin> davidsha: I assume I'd better wait for you to finish the udpate first 14:15:38 <tmorin> davidsha: are you asking me about functional testing specifically ? 14:15:51 <davidsha> True, are there any questions? 14:15:58 <davidsha> tmorin: yup functional test 14:16:06 <davidsha> We'll wait for next topic 14:16:17 <tmorin> davidsha: I think that now that you can have in-repo zuulv3 test job definition, this is perhaps what you should target 14:16:50 <tmorin> py35 is a standard job and should be enabled via a change in project-config 14:17:02 <davidsha> tmorin: ack 14:17:36 <davidsha> If there are no questions we'll move on 14:17:55 <davidsha> #topic Functional tests 14:18:33 <davidsha> So we've kind of covered this, I should have waited till this topic before I brought it up. 14:18:51 <bcafarel> any feedback on OVOs by iharchys? (sorry catching up) 14:19:10 <davidsha> bcafarel: I haven't asked yet, wanted to have the patch updated first. 14:19:38 <bcafarel> ack 14:20:27 <davidsha> It should be up within the next 2 hours, I just caught somethings that needed to be changed. 14:21:01 <davidsha> I'll add some unit tests for it now and have it up soon. 14:21:47 <davidsha> If there's nothing on functional tests I'll move this to open discussion. 14:21:55 <tmorin> about OVO: to allow the push/pull RPC framework to work on objects defined outside neutron, I think that https://review.openstack.org/#/c/512336/ will be needed 14:22:11 <tmorin> this is at least what I concluded when working on OVO for BGPVPN 14:22:14 <davidsha> #topic Open discussion 14:23:06 <tmorin> there is one topic that I want to bring up related to DB, foreign keys and projects consuming CCF 14:23:42 <davidsha> tmorin: ok, sorry just looking at the patch 14:23:49 * bcafarel gets the coffee ready in the meantime 14:24:30 <davidsha> tmorin: go ahead, sorry 14:24:41 <tmorin> ideally we would like consuming projects to have foreign keys to cg or classifications 14:25:09 <davidsha> tmorin: yes 14:25:46 <davidsha> Well, it would cause an issue for DB migration though wouldn't it? 14:25:57 <tmorin> but there is I think one obstacle: I haven't found anything that would guarantee that the DB migration scripts creating the CCF tables will be run *before* the DB migration script of the project consuming CCF which would have foreign keys to CCF tables 14:26:06 <tmorin> davidsha: yes :) 14:27:39 <davidsha> tmorin: Ya, they would need to just be normal strings then. 14:28:37 <igordc> tmorin: "DB migration scripts creating the CCF tables" - do you mean the initial migration? 14:28:51 <davidsha> igordc: yes. 14:29:25 <tmorin> yes 14:30:27 <tmorin> davidsha: yes, not having a foreign key is a solution, but it means we will possibly need more "book-keeping" code to preserve consistency 14:32:32 <igordc> tmorin: what if ccf was under core neutron? 14:32:36 <davidsha> tmorin: True, you mean similar to how QoS does it with policies in the L2 - extension 14:32:51 <tmorin> igordc: that would be better I think 14:33:02 <reedip_> hi 14:33:08 <tmorin> we've discussed this briefly in Denver in fact 14:33:26 <bcafarel> moving the ccf in neutron itself? 14:33:33 <davidsha> tmorin: outside of the live stream? 14:33:54 <tmorin> davidsha: yes, with FWaaS guys during lunch 14:34:13 <davidsha> tmorin: Oh yes, you mentioned that. 14:34:53 <davidsha> bcafarel: yes, it was on the books, but it was later after it had been established and stable. 14:35:07 <tmorin> davidsha: well, we discussed how to check with consuming project whether we could delete a CCF resource, but we assumed we would have foreign keys 14:35:45 <igordc> tmorin: is the migration sequence tighly coupled to which repo the code belongs to? 14:35:49 <igordc> tmorin: atm 14:35:53 <davidsha> tmorin: We could add the classification base table into core neutron... 14:36:52 <igordc> davidsha: the group* 14:37:05 <davidsha> igordc: Was just about to correct it! 14:37:13 <tmorin> igordc: each repo can define one (or more, but usually one) entry point for neutron-db-manage 14:38:06 <tmorin> on installaion/upgrade neutron-db-manage needs to be called for each neutron-related project 14:38:32 <tmorin> neutron-db-manager --subproject foo 14:38:59 <tmorin> I don't know if there is a short cut to tell neutron-db-manage to do this for all subprojects 14:39:48 <tmorin> I haven't investigated deeply yet, but I don't know how to control the order in which subprojects db migration is trigger for the various subprojects 14:39:53 <tmorin> in devstack 14:39:57 <davidsha> tmorin: Are you proposing ordering the set up to put classifier first? 14:40:13 <tmorin> this would be a solution yes 14:40:30 <igordc> if that was possible it would be nice 14:40:40 <tmorin> but this is a topic/question that needs to be shared with the rest of neutron community 14:40:46 <davidsha> tmorin: I don't think this will work, the QoS extension is in neutron's main repo, the neutron repo needs to go first doesn't it? 14:40:50 <igordc> definitely 14:41:42 <tmorin> yes 14:42:47 <davidsha> I think asking if we can add the classification group table to neutron's database migrations is probably the best solution. 14:43:45 <tmorin> since this table has FK to other CCF tables, this would apply to all tables I think 14:44:02 <davidsha> For the moment though, we'll keep going with the patch we have and we can change it when we're ready 14:44:14 <davidsha> tmorin: I don't think classification groups do 14:44:51 <davidsha> No foreign keys in classification groups: https://review.openstack.org/#/c/498471/12/neutron_classifier/db/migration/alembic_migrations/versions/queens/expand/4e97d48da530_initial_ccf_database_.py 14:44:55 <tmorin> davidsha: we need to look closely to have an idea if FK are needed, really-better or sugar-on-top 14:45:50 <tmorin> davidsha: ah, ok, indeed the FK with the other is in the other direction 14:46:21 <davidsha> tmorin: ack, you think it's the best way to know if a CG or classification can be deleted though correct? 14:48:38 <tmorin> davidsha: I'm not 100% sure, but it seems hard to prevent races if we don't have FKs: we can have code to check if a consuming project using CG X, and if not then delete, but in the intermediate time between check&delete, the consuming project may be using it again 14:49:08 <davidsha> tmorin: kk 14:49:16 <tmorin> tmorin: but there may be a way to do without FKs that I haven't thought about 14:50:12 <davidsha> I'm trying to think of a similar resource and how they do it. 14:50:49 <davidsha> maybe QoS policies? 14:51:27 <tmorin> so the thinking was: have FKs to be raceproof, then add hooks so that on failure to delete CG X (because one of the consuming project is using CG X), ask all consuming projects whether and why they use CG X to provide the user with useful feedback on why the CG can't be deleted 14:51:54 <tmorin> davidsha: all QoS stuff is in neutron repo, so they're likely to use FKs 14:52:04 <davidsha> True 14:52:19 <tmorin> the issue is a foreign key to a resource defined outside neutron repo 14:52:55 <davidsha> kk 14:55:28 <davidsha> I was going to suggest asking mlavalle to join but he isn't in the channel. 14:57:31 <davidsha> If we have Classification Groups in the core Neutron migration, does this avoid the race condition of neutron-db-manage? 14:59:24 <davidsha> We're going to have to wrap this up 14:59:33 <reedip_> 30 seconds left ... 14:59:37 <davidsha> Thanks everyone for attending! 14:59:43 <igordc> bye all 14:59:45 <davidsha> #endmeeting