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