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