15:02:05 #startmeeting neutron_upgrades 15:02:06 Meeting started Mon Feb 29 15:02:05 2016 UTC and is due to finish in 60 minutes. The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:10 The meeting name has been set to 'neutron_upgrades' 15:02:17 hello \o 15:02:17 hi neutrinos ;) 15:02:21 hi!! 15:02:24 Hello 15:02:24 hello 15:02:46 #topic Code Sprint (Mar 14-16, Brno) 15:03:06 #link https://etherpad.openstack.org/p/code-sprint-neutron-objects-brno 15:03:27 I see some folks signed up there already 15:03:31 some are tentative 15:03:34 hey 15:03:40 is there public transport from the airport to the venue? 15:03:42 mhickey: are you up to get to Brno? :) 15:03:55 ihrachys: iS bRNO RELATIVELY SMALL. sO WOULD ANY HOTEL IN THE CITY DO? 15:03:57 sayalilunkad: the etherpad, starting at line 7 15:04:21 ihrachys: Travel approved. Need to book it now! :) 15:04:23 mhickey: it's quite small, but I suggest you get Continental, that is in line 18 of the etherpad 15:04:29 the price is more reasonable, and location is ok. 15:04:32 mhickey: great! 15:04:47 sayalilunkad: I see you on the list. have you booked it already? 15:04:51 ihrachys: I will try but it would have to be approved internally. 15:04:52 ihrachys: yes 15:05:09 sayalilunkad: great :) see you here in two weeks. 15:05:17 yup :) 15:05:35 I have room booked in Continental, good price and we can commute together, taxi or bus 15:05:52 I am also staying at the continental 15:06:01 that would be nice 15:06:05 note to everyone: we have some better price option for one of the hotels, details in the etherpad starting at line 21. I would like to ask everyone who wants to use the option to book it this week. next week I will need to close the offer. 15:07:05 ihrachys, thanks for taking care of this! the price is very good indeed 15:07:05 overall, if you have some questions on the sprint that are not covered in the etherpad, please don't hesitate to ask me in private, I will try to accommodate 15:07:16 ihrachys: sorry for caps mess ^^^^ 15:07:23 my pleasure 15:07:24 ok great, now to more juicy matters ;) 15:07:46 #topic Partial Multinode Grenade 15:08:03 the job is now in neutron check queue woohoo! :) 15:08:06 still not voting 15:08:18 we will need to wait a bit to make sure it's stable to enable votes 15:08:24 but seems good so far 15:08:32 #link http://grafana.openstack.org/dashboard/db/neutron-failure-rate 15:08:44 the link should show the rate of failures comparing to other jobs 15:09:04 I'm still not having the +2 for multinode DVR job, need to advertise a little bit more 15:09:16 #link https://review.openstack.org/#/c/250215 15:09:28 korzen: yeah, infra stuff takes a while sometimes 15:09:41 I guess you pulled over folks that could help us, like Anita or Sean? 15:10:03 yes, I've ping them a short while ago 15:10:20 hello all 15:10:22 I guess they have other more important issues 15:10:23 ok, let's wait on it a bit more and then try to ping again 15:10:24 saisriki: hi 15:10:53 korzen: yeah, people are dragged by release stuff right now 15:11:23 ok, apart from that, I guess we just wait for that dvr flavour job in experimental queue to proceed on it 15:11:24 #topic Object implementation 15:11:42 I'd like to remind to everyone we use 'ovo' tag 15:11:45 #link https://review.openstack.org/#/q/topic:ovo 15:12:02 if you'd like your patches to get more attention from folks, please make sure the topic is correct 15:12:38 also note that we are approaching Mitaka release, so we try to refrain from touching any code that is not objects specific 15:13:06 so we split patches that introduce new objects into two pieces: one that implements the object and tests it with unit tests; and another one that integrates the object into the existing code 15:13:24 we will try to merge the former pieces but hold on a bit on the latter 15:13:28 ok, that's the general stuff 15:13:31 rossella_s: any specifics? 15:14:21 ihrachys, not really, apart from korzen's patch https://review.openstack.org/#/c/275790/ that should get merged soonish because it's blocking for the others 15:14:32 rossella_s thanks for catching the UT failure! 15:14:56 korzen, :) 15:14:57 and thanks electrocucaracha for double checking! :) 15:15:08 :) 15:15:23 I have rebased the patch today 15:15:32 over the RBAC object implementation too 15:15:45 right. we need to prioritize merging pieces that block others - testing, framework enhancements, custom sqla types, ... 15:15:55 korzen, I saw that you include more changes that were not included in patch 8 15:15:56 ihrachys, right 15:16:04 oh right, there was RBAC patch that landed recently: https://review.openstack.org/#/c/250081/ 15:16:31 thanks to hdaniel, it's very generic and will hopefully help us once we get to adopting objects for networks 15:16:41 electrocucaracha, yes, it was due to the rebase to recent master branch 15:16:56 korzen, gotcha 15:17:36 there is also a patch from ajo that handles rolling upgrades for qos objects 15:17:38 #link https://review.openstack.org/#/c/268040/ 15:17:51 I presume it's near getting in, but we'll see 15:18:11 there I am :) 15:18:17 running unit tests before pushing new patch 15:18:37 not only qos objects, any ovo that we will push/pull via that api 15:18:53 the approach for rpc callbacks is different than what we have in nova and maybe than what we will perceive as a general solution for agent-server interactions, but it's needed for now nevertheless 15:19:27 some pieces of it will be needed any way 15:19:42 specifically, automatic RPC version calculation 15:20:42 sure, that could be reused for knowing what object versions to use when calling to other pieces in the distributed system 15:20:55 right 15:20:56 if that's what you mean 15:21:03 ok let's move to the next topic 15:21:05 #topic Other patches on review 15:21:23 anything that is worth being mentioned here? 15:21:51 ok, I have one then :) 15:22:04 I am working on MACAddress type. I have put in the changes in the same file as IPAddress 15:22:12 saisriki: great 15:22:15 I've added the hook to modify the fields before DB operations 15:22:20 custom sqlalchemy type 15:22:24 https://review.openstack.org/#/c/281850 15:22:41 saisriki: any ETA for the code to get into gerrit? 15:23:09 saisriki: whats the url for sqlalchemy type? 15:23:34 I was wondering if it's ok to merge it in https://review.openstack.org/#/c/277558/8 15:24:27 saisriki: I have added PS to this. have you checked them? 15:24:38 I am working locally. I have not uploaded it yet. My question is do I need to create new file or should I put the changes in 15:24:39 sqlalchemytypes.py 15:25:05 saisriki, I've created the dependent patch on CIDR: https://review.openstack.org/#/c/285349 15:25:08 saisriki: please base your change on the first patch 15:25:14 saisriki: but make it a separate patch 15:25:25 ihrachys: ok. 15:25:30 saisriki: as for the file itself, you should reuse the existing one 15:25:37 mhickey: what is PS? 15:25:43 saisriki: patch set 15:25:47 patch set 15:25:53 ok 15:26:08 so if you refresh the patch you will see it is a ps 10 15:26:16 saisriki: so do you have an estimation when we will be able to start reviewing it? 15:26:43 ihrachys: do you want me to continue with https://review.openstack.org/#/c/277558/? 15:26:47 I will be done in two days, I will push the changes by today EOD 15:27:14 mhickey: yeah, you were the last one to touch it, right? ;) 15:27:25 ihrachys: yes 15:27:27 mhickey: got it, checked that it is ps 10, Thanks. 15:27:30 saisriki: ok, let's upload what you have and proceed from there 15:27:39 saisriki: np 15:27:50 ihrachys: ok 15:27:53 great. 15:28:09 I wanted to note one bug in ovs agent and how it manages flows. 15:28:11 #link https://bugs.launchpad.net/neutron/+bug/1514056 15:28:11 Launchpad bug 1514056 in neutron "Restarting OVS agent drops VMs traffic when using VLAN provider bridges" [High,In progress] - Assigned to Hynek Mlnarik (hmlnarik-s) 15:28:30 they say that in some cases we still experience data plane disruption when restarting ovs agent 15:28:38 so may be interesting to some of team members :) 15:28:53 there are already some patches on review 15:28:55 #link https://review.openstack.org/#/c/284639/ 15:29:18 ihrachys, thanks for the pointer 15:29:35 ihrachys: ditto 15:29:54 ok I guess no more patches to be aware 15:30:03 #topic Open discussion 15:30:16 if you had something to raise here, that's the best time 15:31:02 fyi: if you need me just ping me in irc. i had laptop problemsd and was away last week. just getting organised again. 15:31:10 does anyone know, if tempest smoke test is doing any integration with DVR? 15:31:41 not that I know. we probably may want to do some analysis of tests invoked as part of smoke suite. 15:31:42 integration, i mean if smoke tests test DVR 15:32:03 I suspect nothing dvr specific, just general routers. (which will scratch some testing surface for DVR nevertheless) 15:32:50 the only road-block for auto generate the ERD schema is to get an approval of the new dependency in global requests 15:32:51 https://review.openstack.org/#/c/281880/ 15:33:30 I guess it would be good to test the dataplane disruption in Grenade test... 15:33:33 electrocucaracha: I see. let me check the list of cores there. We may be constrained by some requirements freeze that may have already occurred for Mitaka. 15:34:23 korzen: yes. though there are lots of configuration scenarios to test there. vlans may be different from tunnels, provider networks from tenant ones, etc. 15:34:45 it does not mean we should not take a common one and start tackling in from there :) 15:35:12 and before that, we can do the manual check 15:35:27 but I would wait on RC 15:35:42 I guess it would be possible to validate upgrade on Rc-1? 15:35:46 or Mitaka-3? 15:35:55 I suggest we do it after M3 15:36:12 since RC in theory should be the final :) 15:36:23 not that it will, but it's better to have some more time 15:36:53 maybe a week after M3, when some exceptional pieces may nad 15:36:54 *may land 15:36:58 I wonder when is the cut off date, when we can be sure that no abusive changed got merged 15:38:08 latest release countdown: 15:38:10 #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/087590.html 15:38:16 "Mitaka 3 milestone: Feb 29 - Mar 4" 15:38:31 so this week 15:39:18 yay 15:39:33 :) 15:39:39 rossella_s, I have a question about synthetic fields handling - are you going to work on it this week>? 15:39:57 this is also kind of important patch 15:39:58 korzen, that patch is blocked by yours actually 15:40:06 rossella_s: can we rebase? 15:40:18 rossella_s: I think korzen's is going to merge once CI votes 15:40:35 ihrachys, yep , I will rebase mine 15:41:06 rossella_s: needs +w 15:41:27 mhickey, it needs to be rebased anyway 15:41:39 rossella_s: ok, np, thanks 15:41:44 btw folks note that zuul is not very happy these days 15:41:58 I see patches from 10 hours ago that are still in check queue 15:42:00 indeed 15:42:02 which is bothersome 15:42:08 but I bet infra is on it 15:42:10 ihrachys: so avoid recheck? 15:42:23 mhickey: if you are not sure it will help 15:42:30 mhickey: ideally, you should read logs first 15:42:38 ihrachys: is it ok to commit ps? 15:42:38 then decide whether recheck has a chance to help 15:42:46 mhickey: commit? 15:42:56 ihrachys, mhickey since the gate is busy I'd avoid rechecks for patches that are not going to be merged soon 15:43:00 ihrachys: git review 15:43:36 mhickey, yep, we want your patches :) 15:43:44 rossella_s: that's a good point. let's focus on the bits we plan to merge now (tests, objects framework patches, new objects) and leave other stuff off until gate recovers. 15:44:00 rossella_s: now that I have recovered from disk problems, it maybe possible! :) 15:44:04 mhickey: yes, we want people not to sit on their patches ;) 15:44:28 mhickey: especially since discs may fail any time! and you loose your work ;) 15:45:08 ihrachys: lol. losing some of my Irish luck of late! :) 15:45:51 ok I bet we now know how to behave as good citizens in the community and save resources for the project ;) 15:46:02 I assume that's all we have for today 15:46:09 :) 15:46:15 :) 15:46:23 if not, let's proceed on the #openstack-neutron channel 15:46:27 thanks bye :) 15:46:27 #endmeeting