15:01:09 #startmeeting neutron_upgrades 15:01:09 Meeting started Mon Feb 15 15:01:09 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:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:13 The meeting name has been set to 'neutron_upgrades' 15:01:25 o/ 15:01:26 hello 15:01:28 o/ all. giving some small time for everyone to fasten their seatbelts 15:03:02 hi 15:03:08 GM 15:03:15 ok let's get working. 15:03:32 Hi; sorry I am late 15:03:37 no announcements my side, so just going straight into topics 15:03:41 #topic Partial Multinode Grenade 15:04:09 not much progress, still the same 3 failures. 15:04:21 we have some patches to add more diagnostics to grenade runs: https://review.openstack.org/#/q/branch:master+topic:neutron-worlddump 15:04:37 and honestly I lean to setting devstack-gate like setup locally and debug it from there 15:04:59 since throwing patches into gate and hope for the best does not seem very effective 15:05:08 that's about it I guess 15:05:21 now juicy stuff 15:05:21 #topic Object implementation 15:05:27 rossella_s: wanna update? 15:05:39 ihrachys, yes! 15:06:00 About the previous topic, I agree, we need a mechanism like that to jump in to CI VMs and eventually debug 15:06:25 hello 15:06:25 ajo: sadly requires infra involvement, so probably not this time. but yes. 15:06:30 slunkad: hi 15:06:39 rossella_s: shoot :) 15:06:41 ihrachys, yes, we just need to raise the concern with infra 15:07:12 ihrachys, so I was lazy and didn't do anything...korzen is still working on the subnet ovo, mhickey is working on the extra dhcp extension 15:07:37 dguitarbite has not started on the port sec extension 15:07:40 rossella_s: some work also done on address pairs 15:08:02 I've seen saisriki patch for the sqlachemy types 15:08:07 yeah, I started going thru all the bits you all folks work on today. will continue reviews. 15:08:39 that types patch is of concern to me, yes. 15:08:39 https://review.openstack.org/#/c/277558/ 15:08:40 slunkad, is working on the sec group extension...still WIP and I didn't have the time to review 15:08:49 I will continue the effort to introduce the composite key case 15:09:14 korzen, great 15:09:16 korzen: I think we have a solid base for the composite keys to merge it this week. 15:09:26 I uploaded some changes of subnetpool but it requires the change of composite keys that korzen has proposed. Subnetpoolprefix requires it 15:09:29 rossella_s: yes I wasn't able to update my patch this week will try to do that this week 15:09:43 *last 15:09:55 electrocucaracha: we could rebase patches on top of korzen's work if that's what you depend on 15:10:37 actually I have another concern...maybe we should talk about it during the discussion slot 15:11:04 rossella_s: as long as it's objects, we can do it now. 15:12:07 ihrachys, it's not so specific to object, let's leave it for later 15:12:08 rossella_s: are you done on objects? 15:12:10 ok 15:12:13 ihrachys, yes 15:12:30 so I was wrapping my head around the types patch: 15:12:31 #link https://review.openstack.org/#/c/277558/ 15:12:58 so my understanding is that without the patch like that (and db models migrated to using new types), we can't use OVO fields for IP address 15:13:46 concern here is that unless netaddr representation is identical to our current string based one, we could need migration (I hope representation is the same though) 15:13:57 and even if the representation is the same, types may need migration. 15:13:59 is that correct? 15:14:03 slunkad: rossella_s ? 15:14:04 ihrachys, yes 15:14:24 that's a bit of sad honestly. :) 15:14:29 ihrachys, I know 15:14:34 ihrachys, I can't see any workaround 15:14:38 first since we may be blocked until we get the types in (and people push them into oslo.db) 15:14:57 and second since migrations mean higher downtime to do the migration. 15:15:12 ihrachys, well we could use string for now...and then migrate but it's going to be more complex probably 15:15:23 rossella_s: why was IPAddress field added to the o.vo? 15:15:30 ihrachys, or we stick with strings :/ 15:15:52 mhickey, what do you mean? 15:15:59 mhickey: apparently because nova already used it 15:16:06 mhickey: the whole library came from nova world 15:16:09 https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fields.py#L402 15:16:47 so how does nova persist the field? 15:17:07 I've heard that IP address in o.vo was added recetly 15:17:21 korzen: ok 15:17:35 mhickey: the netaddr.IPAddress (not string) is passed into SQLAlchemy 15:17:36 sorry thinking out loud; haven't had time to investigate 15:17:48 mhickey: and then the type makes the proper convertion for you. 15:17:48 mhickey, https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/types.py 15:18:36 ihrachys, anyway this discussion should be probably brought to the neutron meeting? 15:18:36 ok, so everything started in nova and is now started to be centralized? 15:18:41 the new sql type is sql alchemy decorator to handle inserts 15:18:45 rossella_s: is there a strict need to map the type to INET for psql? 15:19:02 ihrachys, TBH didn't check 15:19:17 because if we can unconditionally map to String, then at least we don't need to modify schema 15:19:36 ihrachys, I think that works, it's what we are doing now 15:19:53 ihrachys, the down side is that there's no type check ... 15:20:10 right. I actually don't think that the proposal to have it in oslo.db may work. since different projects have different requirements to map alias types to backend types. 15:20:54 rossella_s: I hear you. but at least we can then postpone/avoid alembic migrations and figure out the way out later. 15:20:55 ihrachys, I agree 15:20:57 the workaround for us would be to implement conversion to string in code, without schema and sqlalchemy decorator 15:20:58 ihrachys: but I thought that is a reason to centralize to standardize? 15:21:36 ihrachys, we can postpone the pain :) 15:21:52 mhickey: we standardize on using OVO field type, yes. we diverge on how we handle the result on sqlalchemy level. 15:22:09 ihrachys: ok 15:22:17 ok, I think I have some mind map now. thanks folks for clarification. 15:22:37 the question is should we use string? instead of IP address? 15:22:38 I will try to convince reviewers it may be ok to have it in neutron tree :) 15:22:48 ihrachys, :D 15:22:51 korzen: I think on object level it should still be IPAddress 15:23:13 ihrachys then we need to convert on insert 15:23:23 otherwise the code blows 15:23:32 ihrachys, anyway you raised a good point. This conversion might slow us down quite a bit due to migrations 15:23:36 korzen: yes, we need a SQLA type for that. just not an exact copy of what nova has. 15:23:46 to avoid alembic 15:24:17 ihrachys, maybe we should investigate how painful would be to move to these new types 15:24:43 yeah, definitely something that should be tackled quick to avoid the blocker for other patches. 15:24:45 ihrachys, to get the whole picture 15:24:55 I would suggest to have local type with string(64) not string(39) like nova 15:25:02 ihrachys, right, like high priority task 15:25:19 korzen: yeah, that's another thing. it should be of size we already use in models for ip-address fields 15:26:16 so my proposal would be to have a kind of POC with the introduction of a new type and migration needed 15:26:38 rossella_s and until then? 15:26:40 we can move forward from there...we need to get knowledge regarding what's exactly needed 15:27:08 for stringfield sizes I found this bp https://blueprints.launchpad.net/nova/+spec/string-field-max-length 15:27:11 korzen, until then we have to use strings... 15:27:17 rossella_s: ++; better work out issue head on 15:27:46 I guess we need someone seasoned to spin on it real quick 15:27:46 korzen, mhickey the type investigation should be higher priority since we are kind of blocked 15:27:50 I may take it. 15:27:59 unless someone wants to 15:28:07 I am open 15:28:09 ihrachys, that would be great!!! 15:28:35 this week I am bug deputy so I won't have time 15:28:45 rossella_s: ack! :) 15:28:51 mhickey: ok let's discuss it off the meeting, I bet we can share :) 15:29:04 rossella_s: np, we'll tackle it. :) 15:29:06 ihrachys: beers I hope! :) 15:29:33 we can share beer in March 15:29:46 BTW, travel already booked from my site 15:29:46 korzen: if I can make it... 15:29:47 definitely. it's Czech Republic, ya know 15:29:52 mhickey: you MUST! 15:29:57 ihrachys: I would like to help if I can in anyway 15:30:01 ihrachys: trying my best 15:30:14 I do like the Czech Beer 15:30:24 korzen: nice. we'll do the personal round call later on who's in 15:30:34 ok, one more thing related to objects 15:30:47 ajo landed 1st piece of rpc callbacks rolling upgrade: https://review.openstack.org/265347 15:31:00 noticed that 15:31:10 and another piece was due to be avail for review today: https://review.openstack.org/268040 (probably not there yet?) 15:31:14 ajo: ++ 15:31:16 so keep an eye :) 15:31:24 ihrachys, got it! 15:31:51 ok let's switch to other non-object-y stuff 15:31:54 #topic Other patches 15:32:14 korzen shared a link with me for a nice patch lately 15:32:16 #link https://review.openstack.org/#/c/124946/ 15:32:46 that one adds a framework that allows to add test resources to new alembic scripts and run migrations with them as part of test suite 15:33:06 sweet 15:33:21 so you could merge a script that e.g. adds a field to an object, and make sure the script is working with some objects of that type pre-inserted 15:33:22 :) 15:33:25 nice 15:33:39 still in deep review, but seems to be in right hands 15:33:52 ihrachys, we can use that to test the type stuff ;) 15:34:16 rossella_s: right you are, I guess 15:34:19 also mhickey has some doc patch for db upgrade procedures for ops 15:34:21 #link https://review.openstack.org/#/c/276335/ 15:34:30 have a look, complain, review ;) 15:34:35 oh yes 15:34:46 note it's ops visible, not dev docs 15:34:52 we are such a productive team :) 15:35:08 I would like to start the 'create an hook to modify the object field before writing in the DB' if anyone else is not interested 15:35:12 rossella_s: not bug deputy week! :) 15:35:35 as it is in the backlock 15:35:40 log* 15:36:19 korzen: not sure what's that. but I guess I just need to get my hands dirty with subnet patch to understand the context. 15:36:39 ihrachys, it's commented on the review 15:36:52 right, I won't bother you explaining that to me now 15:37:01 fyi the review mentioned is https://review.openstack.org/#/c/264273 15:37:16 any other patches we should care about? 15:37:31 ihrachys, yes, the case is that we do not have place to modify the params before pushing in to DB 15:38:01 ihrachys, I had to refresh my memory about it..anyway korzen explained that 15:38:04 it is needed when we have different OVO and DB params naming 15:38:26 the thing is to get common method in base class 15:38:34 oh ok I think I follow now 15:38:51 and overdie it in child classes 15:39:10 this would reduce the need to override the create,update,delete methods 15:39:58 electrocucaracha: btw is the patch for sphinx integration for db models in review? 15:40:16 ok I see it now 15:40:17 #link https://review.openstack.org/#/c/274874/ 15:40:28 need to add to the wiki 15:40:33 * ihrachys will do it later 15:40:54 ok I guess no more patches 15:40:56 let's move on 15:40:59 #topic Open discussion 15:41:03 yes, but I have concerns about the pydot dependency that doesn't support py34 15:41:26 electrocucaracha: but docs job is py27 only, right? 15:41:35 yes 15:41:47 electrocucaracha: then what's the concern, for now? 15:42:19 oh I think I know what it is... is it because the dep is part of test-requirements? 15:42:24 it's just that it's displayed in gerrit 15:43:18 what do you mean? 15:44:38 I was thinking that maybe that could be a roadblock for merging that change... but if it's ok for me it's better 15:45:01 in the other hand I'm looking for alternatives like pydot3 15:45:14 but I saw that they have some issues 15:45:29 https://github.com/log0/pydot3/issues/1 15:45:34 electrocucaracha: I think yes, since we have it in test-requirements.txt, it may be an issue 15:45:46 but you can try to add a python27 marker to your dep 15:46:40 can't find an example just now, but will give you one later. 15:47:08 perfect, I didn't know that exists something to difference them 15:47:10 I wanted to raise another point...maybe we should create a topic branch to speed things up 15:47:18 let's get it solved off the meeting. 15:47:31 rossella_s: all for it. suggestions? 15:47:46 "ovo"? :) nice and short and cryptic! 15:47:54 ihrachys yeah! 15:48:17 ihrachys, actually I wanted to ask you if you see downsides...you did that for qos right? 15:48:23 thoughts folks? 15:48:31 rossella_s: yeah we had a topic for qos. worked smooth. 15:48:38 ihrachys, cool 15:48:43 so we can get things moving 15:48:44 especially since we needed to track stuff in other repos too 15:49:01 and then we can deprecate the list of patches on wiki 15:49:18 yeah 15:49:22 I guess everyone is for it? :) 15:49:28 agree 15:50:01 agree 15:50:03 ok, then let's use 'ovo' everywhere. 15:50:52 the topic is not currently used by anyone in the whole openstack world, so should be fine 15:51:07 haha we are original 15:51:16 ok, one more thing I wanted to cover is... the code sprint. 15:51:40 ihrachys, a lazy question regarding the sprint...any idea regarding the daily rate of the hotels more or less? otherwise I will check myself 15:51:54 it's due in a month, so would be cool if we start thinking of it, booking hotels and stuff. please notify me when you are 100% going, or if you have questions. 15:52:22 rossella_s: I suspect it to be quite low, like 50-60 USD, but I will check for you later. 15:52:39 ihrachys, no worries, I can check myself 15:52:57 like I said, flight and hotel booked ;) 15:53:07 korzen: that's cool. 15:53:16 tentative 15:53:27 I will write today to get the authorization 15:53:32 it should be fine 15:53:49 korzen: what's the price for you? 15:54:06 90 Euros per day in Continental? 15:54:21 oh ok. haven't actually booked anything here myself :) 15:54:27 hahah 15:54:38 probably was more optimistic than it's the case :) 15:54:42 ihrachys, one thing you could check it's the special rate for RH 15:54:45 the Barcelo was 130Euro 15:54:47 ihrachys: are you not near the officve; I thought we would have house party! :) 15:55:16 right. I may check on the price. let me talk to a local girl later in the week and get back to you if there are better offers. 15:55:57 ihrachys, thanks 15:56:18 I hope the public transport is ok in Brno 15:56:21 ok I guess that's about it. keep up the good job. we still bootstrap things for objects, but definitely progress is here, and we'll be in good shape in a month. 15:56:29 korzen: it is, absolutely 15:56:49 kudos! 15:56:50 yay 15:56:54 #endmeeting