22:02:38 <armax> #startmeeting neutron_drivers
22:02:39 <openstack> Meeting started Thu Mar  3 22:02:38 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:02:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:02:42 <openstack> The meeting name has been set to 'neutron_drivers'
22:02:48 <armax> ok
22:03:56 <armax> hello folks, so today
22:04:03 <armax> being in the middle of feature freeze week
22:04:23 <armax> I’d rather focus on what we have pending inflight rather than talk about proposed RFE's
22:04:57 <armax> for those of you who thinks there’s an urgency to the matter, consider filing them as release blockers and target RC1 for the wider team’s attention
22:05:36 <armax> but do not abuse :)
22:06:22 <armax> we should switch gear now and ensure that we release something rock-solid
22:06:48 <HenryG> Are we going to set milestone tags on the alembic branches this release? Or are we going to stop doing that?
22:06:53 <armax> Please have a look at a couple of reminders I sent out
22:06:53 <armax> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/088265.html
22:07:13 <armax> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/087953.html
22:07:22 <armax> HenryG: I think so, but I’d defer the answer to ihrachys
22:07:41 <ihrachys_> sorry my net is flacky. what's the question
22:07:54 <HenryG> ihrachys_: Are we going to set milestone tags on the alembic branches this release? Or are we going to stop doing that?
22:07:56 <kevinbenton> ugh, reading assignmenets!?!?
22:08:14 <armax> kevinbenton: ?
22:08:30 <kevinbenton> armax: the email links :)
22:08:47 <armax> oh yes
22:08:52 <armax> kevinbenton: reading assignments!
22:08:57 <ihrachys_> HenryG: yeah, I guess we want it indeed so that you can refer release by name
22:09:11 * ihrachys_ somehow lost it out of sight
22:09:39 <armax> ihrachys: I suppose we have to do the marking as soon as Newton opens up
22:09:45 <armax> HenryG, ihrachys: right?
22:10:17 <HenryG> armax: actually, it must go in with the mitaka final release
22:10:24 <ihrachys_> armax: I think before final. honestly, I need to wrap up my head again to reason about it. I lost context there somewhat.
22:10:31 <amotoki> we did it just before the release.
22:11:06 <HenryG> The problem is external projects. Several don't do it, so their branches aren't tagged.
22:11:19 <ihrachys_> ok right. we need to define neutron_milestone tags before final.
22:11:31 <armax> so, this is something for rc1?
22:11:35 <ihrachys_> yes
22:11:38 <armax> ok
22:11:43 <armax> let’s file a bug and target it for rc1
22:11:53 <HenryG> I'll do that
22:12:06 <armax> go HenryG
22:12:16 <ihrachys_> HenryG: can we maybe enforce failure when milestone used but not every project has it?
22:13:30 <HenryG> ihrachys_: TBH, I don't know when or how these tags are used in reality, which makes it hard for me to decide such a thing
22:13:30 <armax> ihrachys_: let’s take this offline
22:14:09 <ihrachys_> ok let's have it discussed in the bug HenryG will report
22:14:17 <HenryG> ihrachys_: ack
22:14:27 <armax> good point though
22:14:38 <armax> every cycle we risk to forget to do this
22:15:16 <ihrachys_> if we have some release docs, we may need to update them
22:15:43 <armax> ihrachys_: to document this trick you mean?
22:15:43 <ihrachys_> I will take a look at it tomorrow. we may [want to] have some step by step pre-release guide for PTL/drivers
22:15:52 <armax> ihrachys_: that’ll be great
22:16:35 <armax> I am going to document the postmortem proposal I put together in the last day or two
22:16:43 <armax> you reminded me about that
22:17:29 <armax> in fact, let me jump right into that, as we are in feature freeze and folks may wonder what to do for the stuff that’s in flight but not landed completed yet
22:17:58 <armax> I put a patch up for review in the specs repo: https://review.openstack.org/#/c/286413
22:18:13 <armax> that captures blueprints/RFE’s for the Mitaka release cycle
22:18:21 <armax> consider it a collective sign-off
22:18:46 <armax> if you see your name in there, please comment and provide input/status updates
22:18:59 <armax> if you don’t see something that should be there, comment nonetheless
22:19:22 <armax> based on the exent of what’s left to do, you may be granted or denied a FFE
22:20:10 <armax> if you’re denied a FFE, but still think there’s a need to get something merged, file a bug that covers only the part you’re willing to merge for Mitaka and target it for RC1
22:20:33 <armax> if a bug is already filed, target it for RC1 and we’ll look at it
22:21:38 <armax> remember that docs are key to a successful adoption of the work you so hard sweat for
22:22:17 <armax> so write docs, from devref to user content for the networking guide
22:22:40 <armax> any questions?
22:23:14 <ihrachys_> all clear
22:23:19 <kevinbenton> so all FFE discussion is happenon on the post mortem review?
22:23:45 <armax> I’d like so, this way there’s total transparancy and traceability of the discussion
22:24:45 <armax> any other question?
22:25:30 <HenryG> no questions, I like it
22:25:37 <armax> if not, let’s take the next few minutes to talk about somethign I wanted to mention for a while
22:25:52 <armax> I may or may not be the next PTL
22:26:23 <armax> if I am, I’d like to have a better balance between features and stability/usability improvements in Netwon
22:26:30 <armax> if I am not, then I don’t care :)
22:27:18 <armax> what I mean, is that we’d need to emphasize effort on stuff that didn’t succeed in Mitaka
22:27:37 <armax> and we’ll probably only take a handful of new features
22:28:17 <HenryG> You risk being viewed as a tyrant :)
22:28:20 <ihrachys_> I will support you depending on whether my features are in :P
22:28:37 <armax> well, use your vote with judgement is all I can tell you :)
22:28:45 <armax> on the other end, I’d like to draw a line in the sand and stop allowing orchestration-like requests
22:28:49 <ihrachys_> jokes apart, I am fine with stricter approach for a cycle.
22:29:03 <kevinbenton> no campaign speeches during office!
22:29:05 <kevinbenton> :)
22:29:06 <armax> get-me-a-network, cascade-delete were probably the last ones to be allowed
22:29:40 <armax> kevinbenton: I am not campaigning!
22:29:50 <armax> kevinbenton: I am writing my will!
22:29:53 <kevinbenton> we're going to make Neutron great again
22:29:58 <ihrachys_> :D
22:30:01 <HenryG> lol
22:30:19 <kevinbenton> armax: how do you draw the line for orchestration?
22:30:28 <armax> kevinbenton: when was it great, just idle curiosity?
22:30:35 <armax> kevinbenton: no more!
22:30:42 <armax> kevinbenton: eg. this one: https://bugs.launchpad.net/neutron/+bug/1552631
22:30:43 <openstack> Launchpad bug 1552631 in neutron "[RFE] Bulk Floating IP allocation" [Undecided,New]
22:31:05 <armax> kevinbenton: I know we have a weird bulk support in the api
22:31:15 <kevinbenton> armax: right
22:31:28 <armax> but honestly, I don’t trust it at all
22:31:31 <kevinbenton> armax: does L3 HA count as orchestration?
22:31:43 <armax> kevinbenton: I said, let’s draw a line
22:31:44 <kevinbenton> armax: i ask because we have some resources that depend on creating subresources
22:31:46 <armax> kevinbenton: the past is the past :)
22:32:04 <kevinbenton> armax: no, i just mean would l3 ha count as orchestration if it was proposed now
22:32:20 <armax> kevinbenton: probably not
22:32:45 <kevinbenton> armax: so some stuff is obviously 'orchestratish'
22:32:55 <armax> kevinbenton: it’s built on top of existing building blocks, but in itself is something that you can’t easily build with those building blocks alone
22:33:37 <kevinbenton> armax: so maybe the litmus test is that if creating one thing requires the creation of many things, that's okay?
22:34:51 <armax> I’d say we should ask ourselves the question as to whether we can build richer abstraction on top of the existing API without crossing the boundary
22:36:01 <armax> some stuff may be in a grey area and we’ll use judgement on a case by case basis
22:36:11 <kevinbenton> sounds good
22:36:20 <armax> but some are easily assessed
22:36:21 <kevinbenton> just checking to see if you had something specific in mind
22:38:29 <amotoki> for example does bulk support like the above violate the line?
22:38:44 <armax> amotoki: I would like to say yet
22:38:46 <armax> yes
22:39:18 <amotoki> yeah it depends how many api calls we need to somethign
22:39:31 <armax> this can be debated for many hours
22:39:41 <armax> but the roundtrip is hardly where the bottleneck lies
22:40:12 <amotoki> if it requires tens of API calls it might be worth considered but agree in this case
22:40:33 <haleyb> armax: we have customers that want to allocate contiguous FIPs, so you seem to have found a topic of interest :)
22:40:43 <armax> as I said, we can use judgement, but we should be stricter to what we are going to allow from here on out
22:40:46 <kevinbenton> haleyb: are they admin?
22:41:08 <kevinbenton> haleyb: if so, they can specify the floating address they want
22:41:22 <kevinbenton> if not, too bad, so sad :)
22:41:25 <haleyb> kevinbenton: no, they just want them contiguous for SG reasons
22:41:33 <armax> haleyb: I think that’s a bad idea
22:41:46 * haleyb doesn't want to derail, just inform what he's heard
22:41:47 <armax> haleyb: what’s the reason for needing the IP’s to be contiguous?
22:42:01 <kevinbenton> i imagine so they can do allow rules based on prefix or something?
22:42:15 <haleyb> armax: one SG call, for say a /29 or /28
22:42:44 <kevinbenton> haleyb: can't they use the feature of security groups to just allow from that security group?
22:42:50 <kevinbenton> haleyb: instead of based on IPs?
22:43:05 <haleyb> customers are weird is my only answer
22:43:25 <armax> haleyb: I don’t want to say yes to weird requests
22:43:40 <kevinbenton> hmm, maybe there is a usability thing we can improve here
22:43:47 <armax> but we can discuss in more details when we see this show up on our radar
22:43:56 <kevinbenton> if we can make floating IPs part of a security group, then they could do this with security groups
22:43:59 <haleyb> people want to think they own something, and a /2X is something
22:45:33 <armax> ok
22:45:35 <kevinbenton> even a bulk floating IP allocate couldn't guaruntee a contiguous block
22:45:41 <kevinbenton> because it might race with another request
22:45:45 <armax> kevinbenton: nop indeed
22:45:52 <armax> kevinbenton: besides the point here is
22:46:09 <armax> in order to gain something you may have to give up something else
22:46:13 <salv-orlando> haleyb: if customers like that - then tell them they can't use the broadcast and network address of that slice ;)
22:46:17 <armax> you can’t have it all
22:46:41 <armax> so some discussions become educational
22:47:06 <armax> as to why certain things shouldn’t be done for the side effect they cause
22:47:08 <armax> anyhoo
22:47:12 <haleyb> and maybe things like this are extensions that people enable in their own private clouds...
22:47:17 <armax> we’re getting closer to the top of the hour
22:48:21 <armax> if there’s nothing else to cover, I give you all ~10 mins back, we’ll resume the usual drivers schedule from next week
22:48:58 <kevinbenton> ack
22:49:10 <kevinbenton> armax for president 2012!
22:49:52 <armax> 2012?
22:50:01 <armax> #endmeeting