07:00:26 #startmeeting networking_midonet 07:00:26 Meeting started Tue Feb 23 07:00:26 2016 UTC and is due to finish in 60 minutes. The chair is yamamoto. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:00:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:00:29 hello! 07:00:30 The meeting name has been set to 'networking_midonet' 07:00:42 #topic Agenda 07:00:44 #link https://wiki.openstack.org/wiki/Meetings/NetworkingMidoNet 07:00:56 #topic Announcements 07:01:07 i have no announcements. does anyone have any? 07:02:09 #topic Bugs 07:02:42 there's no bugs which is critical and new 07:02:50 nice! 07:03:04 does anyone have any bug which needs wider attention? 07:03:29 i don't 07:04:33 #topic make tempest jobs voting? 07:04:47 i propose to make our tempest jobs voting 07:05:23 i'm ok with that 07:05:26 it has been non-voting for reasons but we now can disable tests with devstackgaterc 07:05:35 right we can take fast action 07:06:05 i'll submit project-config patch. 07:06:06 is this just a tempest job via devstack? 07:06:19 so, single-node all-in-one? 07:06:27 and just upstream tempest tests? 07:06:30 kitsuneninetails: yes 07:08:25 #topic what to do for stadium concept discussion? 07:08:45 #link https://review.openstack.org/#/c/281628/ 07:09:22 ryu made a commet on the review. thank you. 07:10:29 yeah, I am conflicted about this patch 07:10:42 my understanding is ideally we want "midonet" as a big-tent project and make networking-midonet a part of it, right? 07:11:31 they don't necessary have to be the same, but i think it makes sense to put them together if they can be 07:11:41 so being out of neutron staduim is not bad. 07:12:01 if networking-midonet can become a big tent project, then we can always add midonet there as well right? 07:12:27 i think that is more realistic 07:12:29 i'm not sure. i guess we should avoid playing tricks. 07:13:16 it may be considered trickery but i don't know if it really is 07:13:33 but i guess that's a conversation to have later 07:13:35 ryu25: do you know what was a blocker of midonet as a big-tent project? 07:14:06 not in detail, but at one point, i believe Java/Scala got in the way 07:14:15 though apparently that was not really a true blocker 07:14:39 but it also demanded that the openstack infrastructure is updated to handle java projects 07:14:46 then, just a matter of priority on our side? 07:15:20 that and also a question to whether such effort is really worthy at all 07:15:25 i can't really answer that part myself 07:16:01 i see 07:16:30 but i would say that it's still something to consider 07:16:35 i think the conversation has stopped though 07:16:41 but not completely dead 07:17:00 so we can leave it off as a priority issue for now and that's not far from the truth 07:17:13 ok 07:17:17 thank you for explanation 07:17:40 there may be other reasons that I'm not aware of though 07:17:42 np! 07:17:50 let's move on 07:17:50 #topic Open Discussion 07:18:24 python-midonetclient repository will be removed (or at least deprecated) 07:18:54 today i tried doing pip install of networking-midonet and got stuck with midonetclient dependency missing. And noticed that python-midonetclient package is not hosted in pypi 07:19:07 anyone know anything about that? 07:19:58 btw, I still think that we can move the python client code used in neutron to networking-midonet project and lose the dependency to python-midonetclient completely... but that is a separate discussion 07:20:30 we haven't had it on pypi afaik 07:20:30 i'll be happy to discuss it offline if anyone is interested 07:20:49 really? i thought Jaume put it up there at one point. Maybe i'm forgetting something 07:20:54 ok well that explains it 07:21:18 why the repository will be removed? 07:21:33 in favor of the one in midonet repo? 07:22:19 yes, that is the preferred approach (not mine) and it will not be changed 07:23:23 #link https://review.openstack.org/#/c/283026/ 07:23:32 is this a part of the move? 07:24:09 yes i believe so 07:25:01 this is one reason why I prefer to move the neutron API code out of midonet and into networking-midonet 07:25:12 the dependency is very small 07:26:12 are there folks to prefer to keep it in midonet? 07:27:02 yes, at least I know the main midonet contributors prefer it that way 07:27:12 oh wait, are you referring to the neutron client code? 07:27:19 that one, i don't think anyone cares too strongly 07:27:28 python-midonetclient project, people have strogn preferences 07:28:04 yes, my question was about neutronclient 07:28:17 maybe mdts or something uses it? 07:28:20 yes there are strong supporters. 07:28:27 yup mdts does 07:30:34 i tend to think mdts and python-midonetclient should be out of midonet repo but i guess this meeting is not right place to discuss. 07:31:12 i agree with that though i certainly see their view with regards to simplifying maintenance 07:32:06 kitsuneninetails: do you have any idea when zephyr gets ready to consume for networking-midonet gate jobs? 07:32:58 would it need to run in a devstack env? 07:33:29 if it can just run by itself and execute tests, whenever we want to create the jenkins jobs for it should be fine 07:33:45 if it has to run with devstack, it'll be a little bit 07:34:08 kitsuneninetails: that would be very cool to be able to run with devstack 07:34:33 It's planned, but it'll take some dev work 07:35:35 understood, and i'll be more than happy to help out on that effort 07:35:37 kitsuneninetails: it doesn't have a way to run against an existing deployment? 07:36:56 it's planned, but no, not currently. Currently it uses the running neutron deployment, but will bring up and tear down the midonet environment (including tearing down any neutron data along with the midonet-specific data) 07:38:10 I am trying to get it running against an existing env without creation/teardown, but devstack is hard-locked to using "screen", and I am trying to come up with a way to send a ctrl-C to a screen session so I can restart midolman when necessary 07:38:55 do you need to restart neutron server as well? 07:40:15 kitsuneninetails: I wonder if killing/restarting the screen session itself would work 07:40:59 I will try that out and play with it a bit. I might not even need to restart, now that I think about it some more 07:41:10 i tend to think networking-midonet jobs should use midonet from packages rather than via devmido in the first place. 07:41:12 I will have to devote some time to getting it to work with devstack 07:41:55 yamamoto: i agree on the CI jobs. devmido was created only if you want to do parallel development 07:42:39 kitsuneninetails: do all tests require agents to be restarted? 07:42:51 is that part of the setup or something? 07:43:27 just a part of the physical layer startup, not the test system 07:43:39 test system just assumes everything is running 07:43:57 ah ok so with some tweaks, we may just be able to run these tests with a devstack environment 07:45:14 basically, we just need a PTM manager which just sets itself up to an already running physical layer, rather than setting itself up. 07:47:10 kitsuneninetails: thank you for explanation 07:47:24 does anyone have any other topic to discuss? 07:47:36 nope 07:47:52 let me go back to bugs 07:47:58 #topic Bugs 07:48:13 any volunteer for bug deputy for this week? 07:49:01 i haven't done it in a while, so i can take it if no one volunteers 07:49:46 it might be time to revisit if the bug deputy process is worth for us though. 07:50:13 ryu25: thank you 07:52:36 let me give you back a several minutes 07:52:41 thank you for attending 07:52:44 #endmeeting