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