15:01:20 <armax> #startmeeting neutron_drivers
15:01:21 <openstack> Meeting started Tue Dec 15 15:01:20 2015 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:25 <openstack> The meeting name has been set to 'neutron_drivers'
15:01:33 <carl_baldwin> pong
15:01:35 <armax> I am sometimes tempted to start with neutron_divers
15:01:43 <dougwig> o/
15:01:47 <armax> anyhow
15:02:01 <ihrachys> o/
15:02:02 <dougwig> i'd laugh if i was more awake
15:02:05 * carl_baldwin goes to get his diving gear
15:02:16 <armax> :)
15:02:18 <armax> ok
15:02:25 <armax> we have 10 triaged, 18 confirmed and 0 new
15:02:34 <armax> let’s squash the triaged list
15:02:48 <armax> we’ll continue to squash the confirmed list offline
15:03:10 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe&orderby=datecreated&start=0
15:03:15 <armax> in the order they have been submitted
15:03:25 <armax> #bug 1335640
15:03:25 <openstack> bug 1335640 in neutron "[RFE] Neutron support for OSprofiler" [Wishlist,Triaged] https://launchpad.net/bugs/1335640 - Assigned to Ryan Moats (rmoats)
15:04:07 <kevinbenton> +1 to this
15:04:10 <armax> I think this is a no brainer and regXboi has volunteered
15:04:21 <ihrachys> no brainer indeed
15:04:22 <armax> however I would like to see how the nova integration pans out
15:04:23 <mestery> ++
15:04:25 * regXboi wanders in
15:04:27 <amotoki> agree
15:04:34 <regXboi> so - I'd rather *not* wait entirely for nova
15:04:50 <regXboi> because if nova derails, I still really want this
15:05:04 <dougwig> +1 on this
15:05:04 <armax> regXboi: if nova derails for good reasons, what’s the point?
15:05:08 * mlavalle I little confused..... is this neutron drivers or weekly neutron meeting?
15:05:16 <armax> mlavalle: drivers
15:05:16 <regXboi> armax: nova can derail for all sorts of things
15:05:32 <armax> regXboi: that’s not the point
15:05:53 <regXboi> armax: it depends on the definition of "good reasons"
15:06:19 <regXboi> armax: and since I'm putting my name down to spend time on this, does it really matter until I ask for reviews?
15:06:52 <armax> regXboi: no, I am only thinking: I don’t want to have a broken osprofiler integration i ntree
15:07:15 <armax> regXboi: I’d rather wait than have yet another broken thing in the tree
15:07:21 <armax> that’s all
15:07:26 <regXboi> armax: ok, that one made me laugh
15:07:43 <armax> let’s approve this one, and gauge when it’s appropriate to start work on it
15:07:49 <armax> regXboi: I am glad I entartained you
15:07:51 <armax> next one
15:08:02 <armax> bug #1405077
15:08:02 <openstack> bug 1405077 in neutron "Provide API to manage segmentation ranges" [Wishlist,Triaged] https://launchpad.net/bugs/1405077
15:08:42 <ihrachys> for that one, I will note that oslo.config and nova folks were discussing general oslo.config mechanism to reread config values and trigger some actions without service restart on the last summit.
15:08:50 <armax> ihrachys: that’s right
15:09:00 <armax> ihrachys: actually I looked at the code
15:09:09 <armax> and apparently we can only reload logging options for the ovs agent
15:09:12 <dougwig> the use case is general, with a very specific api. i'd rather not piecemeal as the bug suggests.
15:09:18 <armax> dougwig: right
15:09:40 <ihrachys> armax: you mean existing code? they planned for something general
15:09:44 <armax> there’s definitely a class of configs that make sense to be driven from the api
15:09:52 <armax> ihrachys: I did see code
15:09:54 <armax> in tree
15:10:07 <ihrachys> that would allow to register reload hooks for options, and allow them to get triggered on a HUP
15:10:10 <armax> ihrachys: it doesn’t seem we process HUP server side to reload configuration
15:10:19 <ihrachys> armax: yeah, so that's limited to logging now, and there is plan to make it general
15:10:38 <ihrachys> armax: have you checked oslo.service code? I think it should be there. but I need to check.
15:10:47 <dougwig> i'm not even sure that i like live config reload, personally. means i can't calmly change all the files i want, and then choose when it takes effect in total.
15:10:50 <armax> ihrachys: nothing being tracked right now, because clearly we have configs that are parsed everytime and configs that are cached at initi
15:10:51 <armax> init
15:11:05 <armax> ihrachys: no, I checked the neutron ovs agent code
15:11:06 <ihrachys> dougwig: you still trigger a signal or smth to reload
15:11:12 <dougwig> ihrachys: gotcha.
15:11:29 <ihrachys> armax: I talk about other, oslo.config, mechanism
15:11:31 <dougwig> hup versus restart, seems really low priority to me?
15:11:44 <ihrachys> dougwig: not for agents I guess? ;)
15:11:53 <armax> dougwig: the reload is something that every service should undetstand in 2015
15:11:55 <armax> but meh
15:11:58 <ihrachys> agent restart can take hours.
15:12:28 <armax> so I think this bug has sparked a more interesting conversation
15:12:36 <ihrachys> so for RFE, I would suggest the assignee to work with oslo.config folks on general mechanism, and then come back with neutron integration for stuff they care about.
15:12:44 <dougwig> armax: 5 seconds of api downtime is worth the bugs that kind of conversion always brings?  maybe, but i'm not seeing it.
15:12:56 <armax> as to what config is deemed worthy of being driven from the api and what can stay statically defined, but reloaded on the fly
15:13:03 <kevinbenton> ihrachys: !!! which agent restart takes hours?
15:13:15 <dougwig> uh oh, you've made him angry.
15:13:17 <ihrachys> kevinbenton: well, I speak mostly about resync process
15:13:36 <armax> ihrachys: that assumed that the config option is worth keeping it in a static file
15:14:12 <kevinbenton> ihrachys: if we have one that takes hours i want to know so i can start work on optimizing (not really related to this discussion though)
15:14:31 <armax> kevinbenton does optmize all the things, yes, but not in this meeting
15:14:48 <armax> kevinbenton: i think ihrachys’ comment is mostly based on anectodal past evidence
15:14:50 <armax> kevinbenton: relax
15:14:52 <amotoki> I agree to explore the way with config reload to satisfy the request in the bug.
15:15:04 <armax> let’s elaborate a bit more on this one
15:15:08 <ihrachys> huh. some folks still run OSP5, let me check my premises.
15:15:23 <amotoki> taking hours(?) when restarting is a differrent topic.. though related.
15:15:30 <kevinbenton> someone else commented on that bug though that even a hitless restart or config reload is upsetting because they have to update each server
15:15:34 <kevinbenton> IIR
15:15:36 <kevinbenton> IIRC*
15:15:45 <armax> bug #1495440
15:15:45 <openstack> bug 1495440 in python-neutronclient "bulk delete improvements" [Wishlist,Triaged] https://launchpad.net/bugs/1495440 - Assigned to Reedip (reedip-banerjee)
15:16:08 <armax> kevinbenton: yes, tehre’s a management pain of touching each replica of the server
15:16:23 <armax> kevinbenton: but that can handled via sys management tools
15:16:24 <armax> anyhow
15:16:31 <armax> new bug to discuss
15:16:36 <armax> bulky deletes
15:16:52 <armax> so this is interesting because apparently we always had bulk support in the API
15:16:58 <armax> but I am not 100% sure what’s the latest status of it
15:17:00 <dougwig> really?
15:17:10 <armax> dougwig: really!
15:17:24 <dougwig> TIL
15:17:38 <armax> dougwig: https://github.com/openstack/neutron/blob/master/neutron/api/v2/base.py#L70
15:17:43 <armax> now the question is:
15:18:18 <ihrachys> armax: it's used in create and update only
15:18:32 <armax> ihrachys: right, that is what I suspected
15:18:58 <kevinbenton> so i vote just update the client to iterate
15:19:02 <kevinbenton> and delete 1 by 1
15:19:12 <dougwig> i like my "no, in use" errors in batches, yo.
15:19:14 <kevinbenton> parity with nova and an isolated change
15:19:51 <amotoki> kevinbenton: nova cli supports bulk create?
15:19:57 <armax> amotoki: yes
15:19:58 <kevinbenton> no, bulk delete
15:20:00 <armax> amotoki: but it’s fake
15:20:05 <armax> amotoki: it iterates over
15:20:45 <armax> dougwig: you mean that the client will collect all error status and give an aggregte one?
15:21:04 <amotoki> when we support bulk operation in CLI (not library) I first suggest to discuss it among all CLIs , especially openstackclient.
15:21:18 <dougwig> armax: i was being snarky, since delete never really deletes the first time.
15:21:21 <dougwig> ignore me, it's early
15:21:26 <armax> dougwig: ok
15:21:28 * armax ignores dougwig
15:21:53 <armax> amotoki: I wonder if this is a marginal improvement that can help the usability while we transition to the OSC
15:22:14 <armax> amotoki: when I looked around the landscape was fragmented as usual
15:22:25 <armax> some clients did (provide bulky ops) some others didn't
15:22:44 <armax> amotoki: I’d say, if the change is small enough and we can iterate quickly
15:22:56 <armax> let’s have it in the client side
15:23:00 <amotoki> armax: we can do it in neutornclient only
15:23:04 <armax> amotoki: ya
15:23:20 <armax> ok
15:23:22 <amotoki> but we have many neutronclient-speicific command line syntax.....
15:23:43 <armax> not sure I grasp the implication of your .....
15:24:21 <armax> bug #1498987
15:24:21 <openstack> bug 1498987 in neutron "DHCP agent should provide ipv6 RAs for isolated networks with ipv6 subnets" [Wishlist,Triaged] https://launchpad.net/bugs/1498987
15:24:34 <armax> ihrachys: this sounds like a no-brainer to me
15:24:34 <amotoki> armax: will comment later
15:24:38 <armax> amotoki: sounds good
15:24:40 <armax> amotoki: thanks
15:25:17 <armax> ihrachys: care to elaborate a little
15:25:18 <armax> ?
15:25:33 <ihrachys> looking..
15:25:44 <armax> this almost feels like no rfe at all
15:26:01 <dougwig> but a bug
15:26:17 <amotoki> I think it is similar to a case of metadata-agent. RA is advertised from a router.
15:26:21 * armax unignores dougwig
15:26:21 <ihrachys> well, it's change in behaviour. some may claim it's fine that you don't get RAs without routers
15:26:24 <armax> dougwig: yes, a bug
15:26:29 <ihrachys> since R in RA is router :)
15:26:47 <ihrachys> I am happy to have it handled as a bug though.
15:27:21 <dougwig> provider nets don't have a router, right?
15:27:23 <armax> ihrachys: I see…did you get sc68cal’s opinion in private?
15:27:38 <armax> or in some other media?
15:27:39 <ihrachys> armax: I think we discussed it with him before I reported it, in irc
15:27:45 <dougwig> but i guess the ra comes from elsewhere in that case.
15:27:45 <ihrachys> and he said it's a legit thing to request
15:27:57 <ihrachys> I am afraid it would take some time to find a link to logs though
15:28:40 <armax> carl_baldwin: what’s your opinion on the matter?
15:28:42 <ihrachys> dougwig: they have an external one, where we probably don't want to advert RAs.
15:29:08 * carl_baldwin catching up, being pulled in too many directions this morning...
15:29:18 <haleyb> ihrachys: can we not use dnsmasq for the RA instead of spinning-up radvd?  It might already be running.  I'll put that in the bug
15:29:19 <armax> ihrachys: but in that case I’d argue the sanity of running the agent too
15:29:27 <armax> the dhcp agent I mean
15:29:53 <ihrachys> haleyb: huh. that would require some specific coding in dhcp agent though.
15:30:13 <ihrachys> haleyb: I would avoid special casing if possible.
15:30:22 <dougwig> timebox
15:30:23 <armax> ihrachys: how pressing of a use case this is?
15:30:37 <armax> ihrachys: I wonder if the benefit is worth the pain
15:30:40 <haleyb> ihrachys: right, but it might just be another command-line option.  Just thinking out loud
15:30:44 <armax> dougwig: thanks dougwig
15:31:02 <ihrachys> armax: it was not pressing much, I was just wondering whether we can help folks that start on ipv6 and always ask the wtf question on 'why my addresses don't work on my network'
15:31:09 <amotoki> can we deploy radvd with active/active mode? IIRC it needs to be active/passive, but dhcp-agent is active/active. we need more investigation.
15:31:25 <amotoki> but I might be wrong.
15:31:41 <haleyb> i would agree this seems like a bug fwiw
15:31:57 <ihrachys> amotoki: I guess sending RAs from each node is fine since they should be identical
15:31:59 <armax> ok, let’s capture the discussion on the bug report
15:32:22 * carl_baldwin will watch bug report
15:32:25 <armax> and we’ll figure out over time what to do depending whether this becomes a pressing need
15:32:30 <ihrachys> aye
15:32:36 <armax> bug #1500365
15:32:36 <openstack> bug 1500365 in neutron "neutron port API does not support atomicity" [Wishlist,Triaged] https://launchpad.net/bugs/1500365
15:33:53 <armax> I wonder if we need an ‘update on unset’ field
15:33:55 <dougwig> naive question: why is this not a straight up api bug, with a transaction around the field updates?
15:34:13 <armax> it can’t be
15:34:41 <armax> dougwig: the transaction needs to be between the GET and the PUT!
15:35:05 <armax> the bug reads more like I want a transactional REST model
15:35:19 <armax> where I do a GET and a PUT in an atomic fashion
15:35:54 <dougwig> usually you do a get/put/get when you want something like that.  if the put was borking the two field updates in parallel, that'd be a bug. the get/put maybe not being consistent?  that's just rest.
15:36:01 <armax> we should simply acknowledge the fact that none of the OpenStack API’s work like this
15:36:22 <armax> dougwig: right
15:36:48 <armax> this was sparked by a bug where someone was booting two distinct vm’s with the same port
15:36:54 <armax> not sure how much of a use case this is
15:37:05 <amotoki> I wonder if  we need some constraints on update of device_id and device_owner.
15:37:09 <dougwig> it is odd that we have port claiming being something so... unprotected.
15:37:20 <armax> so I’d say this is borderline between invalid and won’t fix
15:37:24 <armax> amotoki: that’s what I though
15:37:25 <armax> t
15:37:28 <kevinbenton> dougwig: well the HTTP if-match header is one way to solve this with REST
15:37:36 <dougwig> here's a shotgun. you can only aim it at your foot. have a nice day!
15:37:59 <armax> lol
15:38:01 <kevinbenton> if-match can then make the db update a compare and swap
15:38:16 <armax> kevinbenton: not sure I’d implement that with if-match
15:38:22 <armax> but that was my suggestion
15:38:23 <amotoki> we marked similar bug on device_id/owner update as won't fix several weeks ago, but we have another one now...
15:38:32 <armax> amotoki: link
15:38:33 <armax> ?
15:38:41 <armax> as this may end up meet the same faith
15:38:42 <amotoki> I haven't found it yet...
15:38:52 <dougwig> kevinbenton: race still exists, unless that compare is inside the update transaction.
15:38:56 <armax> amotoki: ok, no worries, when you do, perhaps you can mark it duplicated of this one
15:39:08 <armax> dougwig: yeah
15:39:11 <kevinbenton> dougwig: that's why i said "make the db update a compare and swap"
15:39:14 <armax> that would need to happen in a transaction
15:39:20 <amotoki> armax: yeah.. or it may be a signal we need to investigate more.
15:39:39 <armax> amotoki: I think for the specific need the issue reported
15:39:49 <armax> it’s doable to update on a clear field
15:39:57 <dougwig> i'd be more inclined to introduce a port-claim type api than to try to fix rest.
15:39:58 <armax> and prevent update on a prepolated field
15:40:12 <armax> dougwig: that’s exactly my point
15:40:17 <amotoki> armax: yes exactly.
15:40:23 <kevinbenton> this is what the if-match header is for!
15:40:31 <kevinbenton> conditional updates
15:41:53 * dougwig yells at the new-fangled headers to get off his lawn.
15:42:03 <armax> bug #1511574
15:42:03 <openstack> bug 1511574 in neutron "[RFE] Support cleanup of all resources associated with a given tenant with a single API call" [Wishlist,Triaged] https://launchpad.net/bugs/1511574 - Assigned to John Davidge (john-davidge)
15:42:13 <armax> we approved this a while back
15:42:17 <armax> however...
15:42:30 <kevinbenton> https://www.ietf.org/rfc/rfc2616.txt (june 1999) :)
15:43:12 <dougwig> so it's been hated for 16 years. :)
15:43:15 <armax> the effort was predicated on the fact that we wanted to have a universal api that would allow the purging across the various projects
15:43:33 <armax> kevinbenton, dougwig: please let’s take this religious row elsewhere
15:43:47 * dougwig behaves.
15:43:59 <armax> now, the problem is: nova is not ever going to provide a purge(project-id) api
15:44:09 <armax> so we have an exception right there
15:44:21 <armax> amuller was a huge fan of the cross-project initiative
15:44:22 <dougwig> what was their reasoning?
15:44:29 <armax> dougwig: read the bug :)
15:44:42 <armax> dougwig: in a nutshell they don’t want to do orchestration anymore
15:44:49 <mestery> IMHO, if this isn't cross project, it almost seems half-assed
15:45:05 <mestery> Because if resources in other projects are left dangling then it's less useful
15:45:05 <armax> mestery: that’s one way to put it
15:45:19 <dougwig> i disagree.
15:45:27 <armax> mestery: that’s not what I meant
15:45:57 <armax> os-purge does exactly that across all projects
15:46:04 <mestery> There you go
15:46:06 <armax> but it does so by leveraging the existing API
15:46:09 <dougwig> we have several projects that leave you dangling in certain cases and all you can do is go to SQL to clean up the mess (let's go look at the nova instances and cinder volumes that I can NEVER remove, right now.). even a neutron only purge would have its use.
15:46:32 <mestery> dougwig: I don't disagree
15:46:45 <armax> ospurge should fix that for you
15:46:49 <mestery> But I'm saying that this is a classic case of something which really needs to be solved at a cross-project level
15:47:02 <mestery> So we can alleviate the pain for operators across the projects
15:47:12 <armax> that’s what os-purge is for
15:47:16 <armax> guys
15:47:17 <mestery> There you go
15:47:21 <mestery> Thanks armax :)
15:47:22 <dougwig> armax: not if ospurge is just driving the existing api's. an internal purge can be a little more... brutal.
15:47:34 <armax> the sticking point is not so much that
15:47:40 <amuller> dougwig: that's what we should be discussing
15:47:51 <dougwig> but whatever, i've given up on openstack deletes ever being sane.
15:47:57 <amuller> what would be the diff of using the neutron API to drive tenant deletion vs. doing it internally
15:48:06 <armax> it’s wether the the underlying API that implements the purging is a collection of many REST calls or a simpler call that takes care of it all
15:48:32 <amuller> if there's technical benefit to having a single call and using internals to drive the deletion, that's worth talking about
15:48:35 <kevinbenton> unless the neutron purge API does things that we don't allow with normal deletes, i don't see the point
15:48:39 <mestery> amuller: ++
15:48:47 <amuller> kevinbenton: so that's the question...
15:49:27 <kevinbenton> and if we don't allow something in a normal delete, wouldn't it be for a good reason?
15:49:28 <amotoki> some neutron resources like default sg cannot be deleted in normal operations.
15:49:36 <kevinbenton> amotoki: ah
15:49:38 <kevinbenton> good point
15:50:08 <armax> the question is:
15:50:26 <armax> do we want to proceed to provide a purge operation (whichever it may be implemented) regardless of what other projects do?
15:50:46 <armax> or do we want to stay aligned (which means no action for us?)
15:51:07 <armax> votes?
15:51:11 <HenryG> I say we should do it to get some love from operators
15:51:29 <armax> HenryG: they might still love os-purge
15:51:56 <amotoki> even if there is some order of projects to be cleanup, purging can be done project by project. I like to have it even if other projects does not support it.
15:51:57 <armax> amuller: you were the one pushing harder for consistency
15:51:59 <HenryG> that's fine if we can make os-purge work well for neutron
15:52:01 <armax> what’s your take?
15:52:21 <armax> amotoki: again, that’s what os-purge does
15:52:50 <armax> in other words, do we want to take over os-purge code and maintain it ourselves?
15:52:53 <amuller> I'm against adding an API for it, unless someone shows me a compelling technical reason. We can explore owning the code that ospurge would invoke instead of having it in ospurge repo and if that make sense, pushing other projects doing the same. That still means not exposing a new API for it.
15:53:02 <ihrachys> amotoki: why not working on os-purge side with existing API, then consider optimizations if really requested? not sure folks care about multiple calls vs. single one that much.
15:53:03 <armax> and have os-purge simply calling the neutron client?
15:53:10 <dougwig> os-purge sounds like a maintenance nightmare, if it does every project, out-of-tree.
15:53:21 <dougwig> will it keep up, i wonder?
15:53:22 <armax> dougwig: they use the clients
15:53:44 <amuller> dougwig: it can make sense for each project to maintain code that ospurge would call
15:53:53 <dougwig> armax: i have a purge script for neutron, using the client. it is gross. it is maintenance prone. you have to track api changes, and do things in the right order, and sometimes repeat.
15:53:56 <amuller> so when new API resources are added it's up to the project to update its tenant deletion code
15:54:04 <armax> ok
15:54:30 <armax> so the latest consensus is: let’s take over os-purge code ourselves, let’s do client-side orchestration
15:54:57 <armax> and ask os-purge to replace their code with ‘neutron <project-id>’
15:55:06 <armax> that’s it
15:55:25 <armax> no cross-project consensus effort ever
15:55:28 <armax> not from us anyway
15:55:50 <kevinbenton> what about server-side stuff like default sg that isn't deleted via API?
15:55:59 <dougwig> armax: need some coffee?
15:56:13 <amuller> kevinbenton: I'd argue that's a Neutron bug, same as HA networks weren't being deleted when the last HA for a tenant is deleted
15:56:28 <ihrachys> kevinbenton: can we allow to delete them?
15:56:35 <amuller> kevinbenton: if a resource creation creates another resource implicitly, it should also delete that resource
15:56:41 <kevinbenton> amuller: i agree
15:56:47 <armax> kevinbenton: you can still delete that via the api
15:56:54 <armax> kevinbenton: can you not?
15:57:01 <dougwig> i think we're pointing out that deletion is gross, client or no, and os-purge's goal of doing it all via native api is... ambitious. if that's the route folks want to go, i salute those folks. i would not want that job.
15:57:22 <armax> dougwig: you need a sugar pill instead
15:57:33 <armax> dougwig: here, eat a candy bar
15:57:56 <armax> bug #1516195
15:57:56 <openstack> bug 1516195 in neutron "Push all object information in AMQP notifications" [Wishlist,Triaged] https://launchpad.net/bugs/1516195
15:57:56 <dougwig> i'll go sit in a corner and continue using unstack.sh as my bulk delete, since nothing else is reliable.
15:58:13 <armax> last time we talked we said we were going to review the spec to gather more info on the proposal
15:58:17 <armax> anyone willing to share?
15:58:28 <armax> dougwig: ah, so there’s something reliable then!
15:58:38 <dougwig> i think this discussion is happening via gerrit.  (amqp)
15:59:01 <kevinbenton> ()()()()()()()()()()
15:59:10 <kevinbenton> next topic :)
15:59:18 <armax> we’re at time
15:59:19 <armax> nearly
15:59:22 <dougwig> sigh.
15:59:25 <dougwig> what a morning.
15:59:37 <armax> and it’s just started
15:59:45 <armax> I’ll capture the discussion on the bugs
15:59:49 <armax> move some bugs around etc
15:59:52 <armax> thanks folks
16:00:03 <armax> keep reviewing bugs offline, it’s your duty as driver
16:00:10 <armax> #endmeeting