15:01:28 #startmeeting neutron_upgrades 15:01:29 Meeting started Mon Jul 25 15:01:28 2016 UTC and is due to finish in 60 minutes. The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:32 The meeting name has been set to 'neutron_upgrades' 15:01:45 helo 15:02:05 hi 15:02:11 * ihrachys waves at everyone 15:02:49 rossella_s: jlibosva: sc68cal: tonytan4ever: electrocucaracha: and whoever else I forgot. 15:02:58 #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda 15:02:59 * jlibosva waves back 15:03:13 * rossella_s waves 15:03:18 * electrocucaracha waves 15:03:26 I cleaned the agenda page just now, it's now thin and tidy 15:03:32 #topic Announcements 15:03:49 nothing specific, we are heading into N3 the end of next month 15:04:19 one thing, I will be off the next Monday (going to flock'16, the fedora conference), so we need someone to step in and replace me 15:04:35 I can chair 15:04:44 korzen: sold. thanks. :) 15:05:09 ok let's get into business 15:05:10 #topic Partial Multinode Grenade 15:05:31 the prev meeting we mentioned there were mtu related issues with the job. 15:05:34 those are solved now 15:05:48 hello 15:05:58 we also looked at linuxbridge flavour failure logs, and determined it's probably also mtu related 15:06:33 some patches landed in devstack that broke all linuxbridge jobs, those were quickly reverted 15:07:06 so now we look at a set of patches for devstack that should hopefully get us back on track with grenade multinode for linuxbridge 15:07:07 those are: 15:07:21 * sc68cal perks up 15:07:24 #link https://review.openstack.org/345707 15:07:49 ^ that one is a multi component fix that should get us to proper MTU setup for linuxbridge jobs. 15:07:55 #link https://review.openstack.org/346282 15:08:19 ^ that one is a 2nd order revert that should enable the proper defaults for all jobs 15:08:43 my understanding is that kevinbenton created this patch to validate the fixes: https://review.openstack.org/345449 15:09:25 that said, this is probably not enough for grenade because grenade jobs start with mitaka branch of devstack that won't see the fixes. 15:09:36 at least the 2nd order revert that changes defaults. 15:09:55 ihrachys: is there any etherpad for multinode grenade work ? 15:10:02 for that matter, I have a devstack-gate patch that should enable the new default mode of run in gate: 15:10:03 #link https://review.openstack.org/345426 15:10:19 manjeets__: there is one but it may be obsolete, searching 15:10:30 manjeets__: it's a good comment, we need to keep it updated. 15:10:40 #link https://etherpad.openstack.org/p/neutron-multinode-jobs-newton 15:10:44 yes good to get updates from there 15:10:48 thanks ihrachys 15:10:51 https://etherpad.openstack.org/p/neutron-multinode-jobs-newton 15:10:58 #action ihrachys to update etherpad on multinode with latest status 15:11:13 sc68cal: have I missed anything in my pitch? 15:11:27 I know sc68cal had concerns with us messing up with neutron-legacy 15:11:37 that is apparently very fragile 15:11:42 very fragile :( 15:12:02 we'll have to keep poking at it, it's definetly peak complexity and brittleness 15:12:08 to figure a way forward 15:12:35 sc68cal: where do we stand on getting some gate jobs running with new devstack lib? 15:12:43 I guess this is relevant? 15:12:44 #link https://review.openstack.org/#/c/278415/ 15:14:42 * ihrachys pokes sc68cal 15:14:50 * sc68cal looks 15:15:04 yeah that's relevant 15:15:12 that patch switches *everything* over 15:15:30 but we could do patches to project-config to switch jobs over individually... it may be messy though 15:15:49 ihrachys: we're down to 4 unit test failures that need to be diagnosed and fixed. I'm sure it's just missing configuration 15:15:59 between neutron-legacy and neutron 15:16:11 https://review.openstack.org/#/c/278417/ 15:16:20 sc68cal: unit tests? you mean integration? 15:17:10 the failure logs: http://logs.openstack.org/17/278417/11/check/gate-tempest-dsvm-neutron-full/d2f81b1/logs/testr_results.html.gz 15:17:44 the first one suggests port security extension driver for ml2 is not enabled. 15:18:13 yeah 15:18:26 yeah, it's empty in ml2_conf 15:18:34 the cross tenant SG one may take a little more digging 15:18:41 for sec group failures, it's not that obvious 15:18:54 ok cool, seems like you are on good track with the switch. 15:19:14 #topic Object implementation 15:19:37 we landed a significant set of dep patches for subnet work that korzen handles 15:19:38 yay 15:19:44 jupi :) 15:19:55 korzen: where do we stand on getting adoption patch ready to land from your perspective? 15:20:27 yes, I am now working on rebasing the subnet ovo patch for get_subnet/update/delete 15:21:03 I am wondering how about tenant_id -> project_id translation 15:21:12 should it be done in API 15:21:29 korzen: it's not the goal of our blueprint to change anything on API layer. 15:21:43 or in db_base_plugin 15:21:48 I think I recall a mailing list post where we'll translate it ? 15:21:49 korzen: there is obviously an implication for that other keystonev3 switch blueprint 15:21:49 but that should be solved there 15:21:53 korzen: I can check with dasm 15:22:22 sc68cal: right. but that belongs to the other blueprint that targets that, not the work korzen does with solely changing persistence layer for subnets. 15:22:28 ack 15:22:32 so the current problem is that API tests are passing the tenant_id and OVO integration is looking for project_id as input 15:23:11 korzen: we should convert that ourselves for now. later, maybe keystonev3 work will pass project-id right away and then we won't need to do it 15:23:21 for starter I can translate the tenant_id to project_id in db_base_plugin 15:23:43 korzen: I believe that's the way to go. somewhere closer to object API usage. 15:23:59 ihrachys, ok 15:23:59 ideally, where you pass arguments into get_objects and friends 15:24:09 the more isolated the change from our side the better. 15:24:18 +1 15:24:19 cool 15:24:30 korzen: anything more that would require discussion on subnet? 15:24:53 I guess the cidr 15:25:14 like str is needed to be converted to IPNetwork before we pass it to Subnet ovo 15:25:24 and it also to be done in db_base_plugin 15:26:05 korzen: right. we convert in plugin to authentic netaddr type, then pass it into the object field. what's about it? 15:26:20 yes 15:26:52 other than that I will have to register the plugin in fullstack tests 15:27:19 or any other test that is not configured with Neutron Manager get_plugin() 15:27:20 korzen: fullstack? don't we already run neutron-server with a plugin (ml2?) there? 15:27:35 ihrachys, sorry I guess it was something else 15:27:37 korzen: yes, unit tests need to register a plugin to use objects. 15:28:02 korzen: we may consider moving the registration upper a layer eg. into the base test class somewhere, so that it's always there 15:28:19 (with same base db plugin class unless it's specified otherwise) 15:28:30 then we won't need to duplicate it every time 15:28:48 ok, I will check 15:28:52 korzen: I would not block subnet work on that, just an idea. 15:29:20 korzen: for subnet, I would just patch it to pass the gate in a place or two and leave it as an excercise for the future. but I am known to be lazy. 15:29:40 ok, will see 15:30:18 maybe this week or next we will be able to see all gates passing 15:30:20 ihrachys: is that the same issue that I got in the morning? 15:30:42 electrocucaracha, I guess yes ;) 15:30:42 electrocucaracha: the core plugin registration? yes. though probably for different test classes. 15:31:01 korzen: I would really love to see this week, but I understand it's wishful thinking :) 15:31:04 electrocucaracha, like 5 PM morning :D 15:31:05 wait is gate still broken korzen ? 15:31:17 korzen: haha 15:31:22 korzen: :) 15:31:30 manjeets__: no, gate is fine, korzen means for his patches 15:31:44 ok, enough for subnets. 15:31:57 another good news is we landed port security objects including adoption in code: https://review.openstack.org/327257 15:31:58 ok 15:32:16 yay 15:32:26 I see armax had a blessing hand on Friday 15:32:27 I've seen many patch landed last week 15:32:36 there is a patch from korzen that starts documenting objects in devref 15:32:38 #link https://review.openstack.org/336518 15:33:03 folks please review that one ^ it's still early days but we need to agree on how it should look like from strategic pov 15:33:11 bird view at least 15:33:25 ihrachys, agreed 15:33:33 * manjeets__ already reviewed that and suggested some changes 15:33:38 I prefer we try to maintain as much of docs in code because it's less prone to become obsolete 15:33:46 yes, if someone would like to write an chapter, then I;m open to cooperation :) 15:34:10 with devref being a single entry point for newcomers to get the idea, where to start, maybe we can even autogenerate some of docs straight from the code 15:34:13 korzen: chapter on object implementation ? 15:34:28 ihrachys: ++ 15:35:01 there is a patch from manjeets__ that suggests to add some more object API methods: 15:35:03 #link https://review.openstack.org/344434 15:35:16 that is a bit controversial since it seems opinions are split. 15:36:31 there is a couple of places where one() is used 15:37:05 and if this places rely on raising an exception, maybe an method in object base class can be prepared 15:37:09 korzen: question is, why get_object/get_objects not enougj? 15:37:36 users can always craft a raising helper if they need it. like we do in qos plugin for get_object. 15:38:19 they way I see it, we are not forced to expose every single method from sqla as long as we provide a way to achieve something without a hit on scalability and such 15:38:26 ihrachys, +1 15:38:41 in my understanding, when you do the get_objects and then you need to parse in code how many results you've got, that is performance ;) 15:38:55 korzen: that one is; so why not get_object? 15:39:11 korzen: you can also paginate ;) 15:40:04 I also had one more concern 15:40:41 for some object we need a refactor to move models out of file which have mixins in itself 15:40:42 manjeets__: which one 15:40:55 manjeets__: right, the circular import issue right? 15:40:55 * manjeets__ looks for launchpad ticket 15:41:00 ye 15:41:01 yes 15:41:27 we need to rearrange models in the tree. I think there was even a RFE reported to track the work. was that you? 15:41:38 I have proposed instead handling it with each object make a design move all models definitions to one file 15:41:38 yes 15:42:08 https://bugs.launchpad.net/neutron/+bug/1597913 15:42:08 Launchpad bug 1597913 in neutron "refactor model definitions" [Wishlist,New] 15:42:22 I like the idea 15:42:46 specially because it's common to have to split models from mixins 15:42:57 that seems like a good idea, though we need to make sure we handle it in a way that is compatible (leaving shims with deprecations for external users) 15:43:10 electrocucaracha: mixins should burn in hell, but yeah 15:43:56 but the questions is, what could be the definitions? do you have a suggestion for that? 15:43:58 and don't create separate directory divide model definitions into categories and have them defined that instead of creating a new file of each object 15:44:19 manjeets__: are you going to push a devref proposal maybe on tree arrangement? I am pleased to help with reviews for the effort. 15:45:05 manjeets__: I suggest you describe briefly your vision in devref patch and we spin on it there. is it good for you? 15:45:38 ihrachys: a separate one ? or we can have it added to korzen's devref doc patch ? 15:45:49 manjeets__: that is a separate thing 15:46:07 manjeets__: overall there may already be a place for such a description. we need to check existing pages. 15:46:25 ok will take a look into it 15:46:40 manjeets__: cool. I will check after the meeting too. 15:46:58 sounds good 15:47:07 we have more objects in review, specifically service type from electrocucaracha https://review.openstack.org/304322 and dns from manjeets__ https://review.openstack.org/334695 15:47:23 the latter probably requires some rework based on feedback on get_one_object 15:47:40 for some reason gate is not being showering love on dns object since friday 15:47:50 electrocucaracha: what's the status for service type? I see it has a bit to adopt the object. great. where are we in terms of getting gate green? 15:48:03 manjeets__: rebase needed, it's in conflict 15:48:24 yes I saw it now 15:48:30 ihrachys: after the suggestion to configure the plugin, I'm getting an error saying AttributeError: 'NoneType' object has no attribute 'provider_name'" 15:48:55 ihrachys: I'm still checking the trace and figure out the possible causes 15:48:56 electrocucaracha: ok, let's see after the meeting where it gets from. I will ping you. 15:49:05 ihrachys: thanks 15:49:26 there are more patches in the queue in different state of readiness 15:49:31 #link https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db 15:50:02 port object, I should have got to it the prev week, and I failed. I will get to it tomorrow, it's first thing in my list right now. 15:50:09 can't we have model query type helper defined in object api instead of going convoluted way of using plugin ? 15:50:13 * ihrachys whips his back 15:50:33 manjeets__: sorry I don't follow. 15:50:57 manjeets__: the plugin registered is needed because get_object() relies on common_db_mixin that requires plugin to be available. 15:51:01 like decouple plugin and objects.db.api 15:51:40 korzen: we need to do that, but it's not easy because query and other hooks are registered on common_db_mixin and are themselves isntancemethods 15:51:43 not class methods 15:52:09 ihrachys, yeah, I think we have to live with it for now 15:52:19 though afaik there are no current users that require _model_query to be instancemethod 15:52:39 but that's an unsafe change that we should think through, it potentially breaks a a lot of things. 15:52:55 also of note, a lot of this stuff now is being moved into neutron-lib 15:53:13 #link https://review.openstack.org/#/c/303864/4/neutron_lib/db/utils.py 15:53:41 I prefer we don't get in that rabbit hole unless forced to :) 15:54:11 ok let's move on, we have few minutes to run thru the agenda 15:54:13 #topic Other patches on review 15:54:38 quick note, we landed the patch that converts networks to new MTU values on Friday 15:54:39 #link https://review.openstack.org/336805 15:54:49 the one we discussed the prev week. 15:55:21 another thing you should all be aware is: 15:55:23 #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/push-notifications 15:55:32 kevinbenton is going to use objects for DHCP agent 15:55:49 initially we were thinking he will need just subnets 15:55:55 but in https://review.openstack.org/340273 I see networks and ports 15:56:16 my thinking was it is all needed 15:56:19 which may be a pain and we may need to change direction for that bp a bit since those objects probably won't land before N 15:56:32 ok, I was under wrong impression :) 15:57:02 another thing, kevinbenton crafted some quick hack to push payload into agents that is very similar to rpc callbacks: 15:57:05 I hope that subnet work will open an short path to network and port adoption 15:57:07 https://review.openstack.org/336730 and https://review.openstack.org/340272 15:57:20 I suspect it's just for testing and is not meant to land as-is 15:57:51 korzen: we'll try, yes. but we should think of alternatives so as not to block his work in case of failure. 15:58:25 the patches that kevinbenton has for object amqp notifier do not seem to be compatible with rolling upgrades. 15:58:36 because they don't backport objects, that rpc callback does 15:58:50 so something to clarify with him in review, others are welcome to join. 15:58:56 any more patches to mention? 15:59:02 ok, thanks for links 15:59:49 ok, we don't have time for open discussion this time, sorry. 15:59:56 next week korzen will give a time slot for all concerns! 16:00:08 in the meantime, please reach in irc if you have anything to any of us 16:00:10 and keep up! 16:00:13 cool thanks 16:00:18 thanks, bye 16:00:19 #endmeeting