15:01:01 #startmeeting neutron_upgrades 15:01:02 Meeting started Mon Sep 12 15:01:01 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:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:05 hi all 15:01:06 o/ 15:01:06 The meeting name has been set to 'neutron_upgrades' 15:01:10 Hi 15:01:16 #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda 15:01:17 Hi 15:01:27 o/ 15:01:37 hello 15:01:52 welcome back korzen 15:02:00 rossella_: are you with us? 15:02:01 :) 15:02:18 #topic Announcements 15:02:40 not much to announce; we'll have newton-rc1 released this week, after which master will be open for Ocata 15:03:10 #topic Partial Multinode Grenade 15:03:17 ihrachys, yep 15:03:56 grenade linuxbridge job is still in experimental, we are basically waiting for stable/newton branch creation, so that we don't need to follow a huge number of devstack backports to fix it 15:04:18 since master will then gate grenade against stable/newton, we should have all the needed linuxbridge/devstack fixes to proceed 15:04:27 abregman and jschwarz will take a look 15:05:20 other than that, I believe jobs are behaving fine. there is more work to do in terms of gate setup definitions (moving services to secondary nodes, checking dvr tests), so if people have cycles, there is work to join. 15:05:27 #topic Object implementation 15:05:30 first Newton 15:05:36 we basically track two things 15:05:52 1. expose db_obj on objects: https://review.openstack.org/#/c/348279/ 15:06:36 (plus its dependency https://review.openstack.org/#/c/367268/ ) 15:06:58 2. not failing on unknown API filters: https://review.openstack.org/#/c/365659/ by electrocucaracha 15:07:13 for the 1st one, it passes the gate, no negative comments so far. 15:07:42 for the 2nd one, it's good, though small nits to consider + we now need a bug reported and targeted for RC1 for everything we land 15:07:57 electrocucaracha: I hope you will get to report the bug and update the patch? 15:07:58 yes, I was planning to create the bug today 15:08:41 electrocucaracha: I believe next iteration should be ready to go in :) 15:08:47 ihrachys, for everything you mean every patch ? 15:09:00 manjeets-: just those that are tracked for Newton 15:09:09 manjeets-: which are afaik just two those pieces 15:09:17 ok 15:09:19 manjeets-: for ocata, we are sticking to blueprint still 15:09:39 ok, now for Ocata. as I said, next week master will be open 15:09:56 I've seen that ocata is going to be very short 15:10:00 ending in Feb 15:10:02 I am hopeful we will be able to land most model relocation patches then. 15:10:09 korzen: yeah, it's 4.5 months 15:10:28 which may impact some of our plans. 15:10:36 I included the progress in the spreadsheet 15:10:38 hopefully we'll make all ovo implementation by then 15:10:39 https://docs.google.com/spreadsheets/d/1FeeQlQITsZSj_wpOXiLbS36dirb_arX0XEWBdFVPMB8/edit#gid=1434170112 15:10:40 I'm seeing that rc1 is Jan 30 15:11:11 manjeets-: electrocucaracha: anyone from your team already looking at reusing existing objects for database code? 15:11:25 I mean, things like subnet or port or network or sec group 15:12:06 you mean implementing those ? 15:12:07 subnet is partially covered 15:12:26 korzen: good, though I believe the patch is still not in shape to pass CI? 15:12:40 manjeets-: more like using in plugin code what's already merged. 15:12:49 well, I think that it's not reusing, they are creating new ones that depends on those objects or working on the integration 15:12:59 ihrachys, it is passing but with hacks 15:13:13 manjeets-: we have quite some OVO objects that are not hooked into plugin code, and I believe it's of no one benefit to keep it long that way. objects rot. 15:13:30 #link https://review.openstack.org/#/c/321001/ get, update and delete converted to Subnet OVO usage 15:13:57 #link https://review.openstack.org/#/c/351740/ create subnet converted to OVO 15:13:58 electrocucaracha: I talk about integration 15:14:27 yea and currently some have api are not passing context and are passing session directly 15:14:57 manjeets-: right, those will land as needs arise. 15:15:11 I thought we can build context on fly before calling object api without modifying the create update api 15:16:09 manjeets-: ? context contains a lot of valuable info that you cannot just drop, like auth info. 15:16:27 yes thats the reason we have to modify the api 15:17:02 not sure it's API though. it's just internal functions. If that's indeed api somewhere, we may need to do something smarter, that would be more compatible. 15:19:05 ihrachys, https://review.openstack.org/#/c/363206/ 15:19:21 example change 15:19:51 manjeets-: but is the code used outside the neutron tree? 15:20:00 ihrachys while integration, got CORE plugin not found error , https://review.openstack.org/#/c/359379/8/neutron/tests/unit/scheduler/test_dhcp_agent_scheduler.py does it look acceptable? 15:20:34 ihrachys, I don't know about that at the moment will check if it is used outside tree or not 15:20:48 manjeets-: looking at codesearch.openstack.org, I don't see any usage outside the tree, it seems more like internal classes. 15:20:57 so then we are good 15:21:06 we can change that to context 15:21:38 asingh: yeah, we need it because objects rely on plugin instance. we may think about moving that into base test case class though because we already have it in quite some places. 15:21:53 ok. next week we should be ready to restart active implementation. I hope folks will prepare patches in queue for that so that we can land them quicker. 15:22:48 #topic Other patches on review 15:22:55 * ihrachys looks thru his review queue 15:23:03 ihrachys, in newton they were delayed because of priority but assuming in ocata they will be higher priority ?? 15:23:30 manjeets-: yeah, we actually had some discussions with PTL about raising priority, and there are some ideas on how to make it happen. 15:23:45 manjeets-: it's of no one's benefit to linger foundational features for cycles 15:24:36 ok, I checked my queue, I don't see any patches of interest for the team. 15:24:57 let's switch to the last section and discuss anything you may have there 15:25:00 #topic Open discussion 15:25:24 sindhu: had a question 15:25:37 ihrachys, i'll rebase networkdns and portdns patch for implementation on top of your ovo port patch this week 15:25:53 manjeets-: ok, thanks. 15:25:57 ihrachys while integration of segment host host mapping, current implementation combines 4 queries , https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L667-#L679 . 15:25:57 Final query looks like http://paste.openstack.org/show/572359/ 15:26:36 ihrachys It includes Subnet, SubnetServiceType and SegmentHostMapping OVO. 15:26:36 How should i got about it? 15:27:04 ihrachys: just a small confusion regarding whether to have the ovo creation and integration in same patch or different patch? (considering its use for push notification) 15:27:41 * electrocucaracha was thinking in the same question as sindhu 15:27:47 ihrachys, for joins should be issue a get_object on each model and and make a list then filter out based on join conditions ? 15:28:16 should we** //should be 15:28:42 asingh: the way I see it, you pick an object that is of more relevance here (subnet?) and add a classmethod there that will do the job. we won't be able to get rid of model interrelationships completely, so the goal is at least to isolate model mess under neutron/objects/. 15:29:20 sindhu: I would say, case by case. if the object is huge and integration is not obvious, consider split. but otherwise better not to. 15:29:30 ihrachys: i have a query with_lockmode update https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/type_vlan.py#L105. Do you have any suggestion how to go about it? 15:29:48 manjeets-: the problem with using object API to mimic queries is that then you have multiple queries instead of a single one 15:30:00 and multiple is bad for scaling 15:30:15 so it's better to stick to query builder. 15:30:33 yea that is less efficient 15:30:52 electrocucaracha had some ideas about making synthetic fields work as advanced filters, though it's not obvious how to expose that kind of behaviour in a generic way. 15:32:24 I like the idea of per class classmethods 15:32:46 dasanind_: I admit I don't know much about the lock, but I would imagine we may need to keep it. now, the question is whether we need to expose that kind of behaviour through common objects API, or just keep it the way it is now, just in another place. 15:33:01 maybe after few implementation we will have good idea how to implement it in generic way 15:33:46 ihrachys, if that's the only place it is used there we may not need to expose it through object api 15:33:52 ihrachys: yeah in this query I am not sure how to introduce the object. It's acquiring lock on the table and updating the table 15:33:55 + to what korzen said. it's probably easier to start from actual use cases, then seek for commonality, then implement everything we may stumble on in a generic way right away 15:34:04 korzen: I like that strategy for looking patters or things in common 15:34:31 ihrachys: if i try to separate this I will run into integrity error 15:35:00 dasanind_: it can be a huge class method on the object that does the same as now, for the time being. 15:35:48 ihrachys: you mean keep the query same as now?? 15:36:27 I think that ihrachys is suggesting to extract those complex queries into class methods 15:36:51 dasanind_: I would need to look into details. but yeah, that would be my first attempt. do you think we can remodel the query without losing db optimizations? 15:37:18 ihrachys: will look into that and let you know 15:37:28 electrocucaracha: right, and place all those dirty things under neutron/objects/ under respective object definitions. 15:37:33 for now it'll be good electrocucaracha 15:37:59 electrocucaracha: ok 15:38:19 we will make sure we tag everything we hate about the code with TODOs :) 15:38:26 when moving 15:38:27 we can handle the db schema changes from the ovo later which is the main purpose 15:38:41 ihrachys: sure 15:38:57 then it's a matter of resources to get it into better shape. I don't want us to spend too much time now solving problems that honestly are not induced by our effort. :) 15:39:24 ihrachys: regarding TODOs, we should consider some time during ocata for complete them 15:39:36 electrocucaracha: yeah, I have quite some on my plate :) 15:40:16 electrocucaracha: if it's tech debt, we should not add more; if it's just 'things to implement later', I am fine to land it that way. 15:41:16 ihrachys: In this patch https://review.openstack.org/#/c/348279 we are exposing the database model for NeutronDbObject instances. Will it not impact the rolling upgrades? 15:42:00 dasanind_: assuming plugins don't rely on any new nasty things, I don't see it affecting us much. 15:42:10 dasanind: and btw we detach the model from session just in case 15:42:27 dasanind: so plugins can't really do much with it except read from its attributes 15:42:40 dasanind: we will need to switch our plugin API to objects though. 15:42:51 dasanind: it's just that we are not ready to do it across the board. 15:43:21 dasanind: and we have no plan implemented yet on how to evolve the current plugins API that relies on models. 15:44:09 dasanind: so it's a matter of switching all the code to objects, then working on some evolving solution, then taking some more time to deprecate models for plugins API. it's not a single cycle job. 15:44:57 ihrachys: makes sense. 15:45:24 ihrachys: these plugin API's have the capability to update the db as well correct? 15:45:55 dasanind: most current plugin code does pass an attached model, so yeah, in theory they can do it 15:46:31 dasanind: though it's my belief, and some other people agree, that's unsafe and hence we should be able to break people that try to rely on it 15:47:55 ihrachys: so with the introduction of OVO they will be able to use the plugin API to read the attributes but update will break 15:47:56 so eventually, we have to create more class methods for plugins 15:48:38 dasanind: yeah, kinda. I hope we won't need to attach the model. :) 15:48:50 electrocucaracha: not sure I follow 15:48:58 electrocucaracha: you mean for very specific queries? yes 15:49:07 ihrachys: exactly 15:49:27 ihrachys: thank you for the clarification 15:50:45 ok, I guess it's time to end the meeting :) we'll meet again in a week when we will have the master branch open and unicorns everywhere. 15:50:48 see ya 15:50:51 #endmeeting