15:01:10 #startmeeting neutron_upgrades 15:01:11 Meeting started Mon Apr 18 15:01:10 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:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:14 The meeting name has been set to 'neutron_upgrades' 15:01:24 hi everyone! 15:01:36 hello 15:01:38 hello 15:02:25 rossella_s: 15:02:32 hi 15:02:34 hey! 15:02:37 Hello 15:02:39 hi all! 15:02:51 hi 15:02:57 Hey 15:03:08 ok. it's nice to see everyone here :) let's roll 15:03:19 #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda (sortof) 15:03:39 #topic Summit planning 15:03:59 OS_AUS_RIBF6ZE 15:04:03 I remind that we will have a design session that should cover upgrade matters, among other things 15:04:08 sorry wrong window 15:04:08 #link #link https://etherpad.openstack.org/p/newton-neutron-future-neutron-architecture etherpad 15:04:41 #topic Actions from the last meeting 15:04:54 the only action we had is "#action ihrachys to talk to armax about bp for ovo work" 15:05:10 so I talked to armax, and he agreed we better have a blueprint for ovo work 15:05:16 so here you go: 15:05:17 #link https://blueprints.launchpad.net/neutron/+spec/adopt-oslo-versioned-objects-for-db 15:05:27 please use the blueprint in commit messages for ovo work from now on 15:05:41 example: https://review.openstack.org/#/c/268274/ 15:05:56 though it should probably be 'Partially-Implements' 15:06:10 anyway, it should not matter that much 15:06:19 questions on that one? 15:06:44 ok, let's move on 15:06:49 #topic Partial Multinode Grenade 15:07:03 we have a patch to enable voting for the existing job: 15:07:04 #link https://review.openstack.org/#/c/299843/ 15:07:19 sc68cal will need to respin it, he planned to reach me on the matter today. 15:07:39 another thing is dvr job 15:07:45 which now is moved into check queue: 15:07:46 #link https://review.openstack.org/#/c/299844/ 15:08:01 korzen: ^ we may need to track its success rate and consider test coverage. 15:08:13 the idea is that eventually it will replace non-dvr flavour 15:08:31 #topic Object implementation 15:08:31 ihrachys nice:) 15:08:54 on objects front, a lot of progress is done. we are not there yet with huge resources, but we move in the right direction. 15:09:08 #link https://review.openstack.org/#/q/topic:ovo+status:open 15:09:23 subnet patch had no reviews :( except for electrocucaracha 15:09:49 even when we have the bp, we're going to be using the ovo for topic right? 15:09:57 electrocucaracha: yes, topic is the same 15:10:18 korzen: ack. it's a bad time of the cycle :( 15:10:36 folks, please review subnet patch when you have spare cycles: 15:10:36 #link https://review.openstack.org/264273 15:10:41 korzen I will try to review it tomorrow 15:10:49 another thing that should be ready is allowed address pairs: 15:10:50 #link https://review.openstack.org/287756 15:10:57 (and patches below the dependency stack) 15:11:05 ok, thx, I guess we are and will be busy for summit/design 15:11:26 one thing I wanted to run with you 15:11:47 ihrachys, rossella_s: thanks for picking up allow addr pairs! :-) 15:11:47 it turned out that just using netaddr.* is not enough to fulfill our API guarantees 15:11:53 mhickey: np 15:12:15 ihrachys, more details please 15:12:16 specifically, netaddr.* has a bad habit of changing string representation passed into some 'standard' form 15:12:36 so when you do str(netaddr.EUI() 15:12:44 the result is not the same as what you originally passed 15:12:54 now, we have API tests that rely on that being the same value 15:12:55 ihrachys: what is the format? 15:12:58 but you can specify the format 15:12:59 depends on the version? 15:13:30 mhickey: there are multiple ways to represent it, like ff:00:... or ff00ff, or ff:0:... 15:13:40 rossella_s: you can specify the format, yes 15:13:54 rossella_s: the problem is that you still hardcode it to a specific format then 15:13:59 ihrachys, right 15:14:11 rossella_s: and you should return whatever is valid for netaddr.* that is passed by user 15:14:36 rossella_s: so if they pass fffff, you return that; otherwise if they pass ff:ff:, you return ff:ff:. etc. 15:14:52 ihrachys: ok 15:14:55 so, long story short, to make API tests happy, I introduced some smart subclasses for netaddr* 15:14:57 #link https://review.openstack.org/#/c/287756/13/neutron/common/utils.py 15:15:10 ihrachys, if they pass fffff we convert it and then pass back the standard format? how does it work now? 15:15:16 they override __str__ to output whatever was passed into __init__ in the first place 15:15:38 rossella_s: currently we don't pass those values thru netaddr.* so it does not affect the format. 15:16:12 ihrachys, so currently there's no enforcement on the format 15:16:30 rossella_s: currently we allow anything that passes thru netaddr.valid_mac 15:16:42 which is any random stuff that netaddr can interpret 15:17:04 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/v2/attributes.py#n188 15:17:10 ihrachys, then bear with me...maybe we should change the MACField to do just that 15:17:12 ^ that's where validation on API level occurs 15:17:15 ihrachys, let me look at your patch 15:18:09 rossella_s: well, our field requires netaddr.EUI, so database code already need to initialize it before passing into Field 15:18:42 so it's a bit twisted. the point is, I need your eyes on that, it's a bit tricky. 15:18:50 ihrachys, I am just wondering if it should be of type string in the end + validation 15:19:14 ihrachys, to mirror what's currently done in the codebase 15:19:46 ihrachys: re https://review.openstack.org/#/c/287756/, good work in patch! 15:20:39 rossella_s: for IP addresses too? 15:20:51 ihrachys: will take another look as well.. 15:20:55 rossella_s: I mean, we will end up with all fields string :) 15:20:55 ihrachys, just talking out loud 15:21:24 rossella_s: sure. I will be glad to see your reviews on the patch. it needs some good eyes. 15:21:44 I was hoping to get more reviews on https://review.openstack.org/#/c/304862, savailability zones ovo, looks like I didn't put it on the ovo branch/topic 15:22:06 pmath: aye. I changed the topic for you. 15:22:11 thanks 15:22:15 pmath: please make sure all your patches are using the topic. 15:22:20 k 15:22:23 ihrachys, anyway I didn't mean to go back to the plain string field. I'd just modify the current MAC field to be less string and to save the string passed after validation 15:22:24 I mean, not all, just ovo :) 15:22:27 jbr+ 15:22:40 ihrachys, let's keep discussing on the patch 15:23:11 I am all for it :) ok, let's move on 15:23:39 one more thing that I stumbled upon for ovo work 15:23:46 does anybody know when are the milestones for newton? 15:24:11 korzen: http://releases.openstack.org/newton/schedule.html 15:25:00 ok, so the thing I stumbled upon is: we need to support advanced pagination/sorting criteria for resources we switch to objects 15:25:11 and current get_objects() API does not allow for that 15:25:16 I have a patch for just that at: 15:25:36 #link https://review.openstack.org/300055 15:25:44 I would be glad to see more eyes on that one 15:25:51 specifically, it blocks adoption for subnetpool 15:26:00 but I believe other resources will need it as well 15:26:24 one thing to note is that test coverage for the features [sorting + pagination] is non-existent 15:26:29 ihrachys, thanks for raising this point and for working on it! 15:26:37 so we will need to introduce api test coverage before touching that 15:26:51 I have a first set of tests for networks at: 15:26:52 #link https://review.openstack.org/306272 15:27:08 I tried to write ^ in a way that would be easily extensible to other resources 15:27:21 so... I just beg for reviews :) 15:28:20 #topic Next meetings 15:28:37 for the next meetings, we will need to skip the next week and the week after it 15:28:55 I will post an email with the info to openstack-dev@ after the meeting 15:28:58 ihrachys, can we add this to the Backlog in wiki page? I guess that giving an example and then point people where to follow the OVO implementation would be helpfull 15:29:09 #action ihrachys to cancel next meetings in openstack-dev@ 15:29:22 korzen: this == ? 15:29:43 this == API tests, OVO API and OVO core Neutron code adoption 15:30:43 not sure I follow the suggestion. 15:30:54 you mean mention those patches on the wiki? 15:30:59 for example I'm working on subnet and network OVO and I guess that there are a lot of steps to be done in order to fully adopt the objects 15:31:13 oh, ok, general check list 15:31:15 I will do it 15:31:40 what does mean to integrate the object in Neutron core 15:31:48 #action ihrachys to update wiki page with the check list for object adoption (object, database access code, API test coverage, ...) 15:32:09 so, speaking of the next meetings... 15:32:22 the first meeting we will have after the summit, I will be on PTO 15:32:41 anyone willing to step in and handle the chair burden? 15:32:56 alternatively, we just cancel. but I suspect that it may be not ideal for the team. 15:32:58 PTO? 15:33:02 PTO? 15:33:07 Paid Time off 15:33:09 sorry. PTO == vacation 15:33:09 leave 15:33:26 Holiday in Ireland! :-) 15:33:36 korzen: rossella_s: anyone of you willing to run that one? 15:33:47 I can run 15:33:50 ihrachys, I can too 15:33:50 I'll be on Paternity leave 8 weeks starting on May 9 15:33:55 it will be May 9th 15:34:09 electrocucaracha: oh. congrats ;) 15:34:16 electrocucaracha: Congrats! :-) 15:34:23 electrocucaracha, congrats!! 15:34:24 thanks ihrachys and mhickey 15:34:26 and rossella_s 15:34:29 I will also be off for two weeks after the summit 15:34:50 hm. do we have enough people to have a meeting then? should we then cancel indeed? 15:35:02 oh sorry 15:35:04 ihrachys, it seems it's jst me and korzen 15:35:28 rossella_s: you can run a short one. :) 15:35:36 you decide, I don't mind. 15:35:38 rossella_s, korzen: will you be in form after long haul flight?! 15:35:52 rossella_s: it's not the first week after summit. 15:35:53 in 9th May? 15:35:57 sorry. 15:36:04 my fingers type wrong letters. 15:36:13 korzen: yes, that's the date. 15:36:17 ok so, let's have a meeting, even a short one 15:36:23 ok, cool 15:36:36 #topic Open discussion 15:36:40 anything else to discuss? 15:36:47 mhickey 9th May I will be a week after flying ;) 15:37:16 korzen: my bad. yu maybe in the drunk tank though! :) 15:37:33 I want to understand how to handle mixin classes for porting to OVO? Any general steps to follow? 15:37:58 saisriki: what specifically? 15:38:06 mhickey I'm planning to clean my house and garage the after I arrive in Poland :D 15:38:12 saisriki: for allowed address pairs, it was quite smooth 15:38:12 I was trying to look at extra_routes for example 15:38:21 saisriki: is it part of some other object? 15:38:57 It is part of RouterRoute #link https://github.com/openstack/neutron/blob/master/neutron/db/extraroute_db.py 15:39:46 saisriki: I think it's similar. 15:39:47 saisriki: see: https://review.openstack.org/#/c/287756/13/neutron/db/allowedaddresspairs_db.py 15:40:06 basically, you just switch every instance of direct model usage to the object interface. 15:40:24 yes. I will try and follow the allowed address pairs 15:40:36 that's assuming you have an object for RouterRoute and don't embed it into the Router itself. 15:40:57 if that's the latter case, I don't think we had it before, so we would need more thought. 15:41:01 ihrachys: ok 15:41:09 ok, cool, I hope that covers your needs for now. 15:41:14 anything else? 15:43:37 ok, let's call it a day. see some of you on the summit, else in several weeks! 15:43:37 #endmeeting