22:00:13 <mlavalle> #startmeeting neutron_drivers
22:00:14 <openstack> Meeting started Thu Oct  5 22:00:13 2017 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:18 <openstack> The meeting name has been set to 'neutron_drivers'
22:00:22 <armax> hello
22:00:28 <mlavalle> hey
22:00:43 <ihrachys> ssup
22:00:49 <mlavalle> amotoki, yamamoto: ping
22:02:20 <mlavalle> let's wait a copuple of minutes for amotoki and yamamoto
22:02:25 <ihrachys> ok
22:03:31 <amotoki> hi, sorry for late
22:04:10 <mlavalle> np problem amotoki, thanks for attending
22:04:26 <mlavalle> I don't see yamamoto, so let's get going
22:05:01 <mlavalle> The agenda is here: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda
22:05:12 <mlavalle> #topic Alternate time meeting
22:05:41 <mlavalle> yesterday armax and I had a conversation about looking for a time slot alternative
22:06:14 <mlavalle> armax problem is that early morning hist time is when he can work with his Suse counterparts in Europe
22:06:44 <mlavalle> so he proposes to "share the pain", alternating the meeting time
22:07:11 <ihrachys> I am fine
22:07:13 <mlavalle> the same way we do with the Neutron meeting
22:07:22 <ihrachys> so this slot and some early CA, US one?
22:07:29 <mlavalle> yes
22:08:02 <mlavalle> it would have to be sustainable when we fallback to standard time in the US
22:08:03 <armax> so 2pm UTC
22:08:14 <armax> and 10pm UTC
22:08:17 <armax> every other week
22:08:31 <armax> or 1400UTC and 2200 UTC I should say
22:08:41 <mlavalle> the present meeting is at 2200utc
22:09:04 <mlavalle> does 1400UTC work for you, armax, when we fallback to standard time
22:09:06 <mlavalle> ?
22:09:29 <armax> that would be 6am, I don’t typically function at that time
22:09:34 <armax> even if I am awake
22:09:54 <mlavalle> how about 1500UTC
22:09:57 <armax> but the problem for me is that the mornings from 7am to 10am are loocked up
22:10:32 <mlavalle> armax: so on the alternate week you wouldn't attend?
22:10:55 <armax> the reason to alternate is to allow the rest of the team to meet in a time you all are comforable with
22:11:03 <armax> and I would be able to engage half the time
22:11:18 <armax> mlavalle: right, unless I happen to travel and I am in a funny timezone :)
22:11:48 <mlavalle> ihrachys: what are your thoughts?
22:12:24 <mlavalle> amotoki: does 1400UTC work for you?
22:12:27 <ihrachys> well I am fine with the change if it helps to keep armax involved and is better for Asian fellas
22:12:35 <amotoki> I am okay with either. 14or15UTC is easier to attend.
22:12:47 <ihrachys> I enjoy mornings, so it's to the better for me
22:13:12 <mlavalle> and I understand that yamamoto also prefers 1400UTC
22:13:13 <armax> right, I think we should give this a try
22:13:35 <armax> and see if we can engage a few other folks who may be interested in attending but are not in US timezones
22:13:44 <mlavalle> and at the same time, we allow people in the US East cost, Europe and Middle East to attend the meeting every two weeks
22:14:02 <haleyb> i'm in a US timezone and have trouble at this time :)
22:14:05 <mlavalle> I know haleyb is interested in attending
22:14:55 <mlavalle> ok, let's give it a try
22:15:30 <armax> haleyb: right
22:15:33 <mlavalle> next week will be our first alternate session
22:15:44 <armax> so early mornings may gather a larger crowd
22:15:59 <mlavalle> early morning US time, that is
22:16:00 <yamamoto> hi
22:16:07 <mlavalle> hey yamamoto
22:16:12 <ihrachys> mlavalle, make sure you send the patch for irc-meetings repo earlier
22:16:22 <ihrachys> so that we have ical files in advance
22:16:29 <mlavalle> ihrachys: I'll do it tonight or tomorrow morning
22:16:30 <ihrachys> and cancel meetings if there is overlap
22:16:36 <ihrachys> do we need a doodle?
22:16:45 <ihrachys> to pick a day
22:17:17 <mlavalle> before that, maybe Thursday already works
22:17:28 <mlavalle> that was my assumption
22:17:34 <armax> mlavalle: we should look at what’s available in the openstack calendar
22:17:44 <amotoki> as far as I checked, 1400UTC Thursday next week is only used by one meeting, so it would be no problem
22:17:50 <armax> but I assume you already thought of that :)
22:18:07 <mlavalle> ^^^^
22:18:07 <amotoki> sorry.... I see a wrong slsot
22:18:43 <ihrachys> neutron-upgrades meeting is in the same slot
22:18:49 <ihrachys> on Thu
22:18:51 <amotoki> all five meeting channels seems to be used already..
22:19:48 <ihrachys> US mornings are usually packed because of sync with Europe
22:19:58 <mlavalle> ok, so I have to fix the meeting room problem
22:20:24 <mlavalle> I'll work on that as soon as we finish this meeting
22:20:41 <mlavalle> yamamoto: does 1400UTC work better for you?
22:20:42 <armax> we need to increase timezones
22:20:58 <yamamoto> mlavalle: it's fine
22:21:00 <armax> by moving to mars
22:21:03 <ihrachys> armax, or just get another channel
22:21:06 <mlavalle> the idea is to alternante between 2200UTC and 1400UTC
22:21:09 <armax> ihrachys: too simple
22:21:12 <ihrachys> or hold them in #openstack-neutron channel
22:21:16 <armax> ihrachys: you gotta think bolder
22:21:20 <ihrachys> actually, that wouldn't be that bad
22:21:26 <armax> ihrachys: there’s no nice logging that way
22:21:38 <armax> is there?
22:21:47 <amotoki> we can use a project channel for meetings now. meeting bot is there
22:22:16 <armax> amotoki: that makes it hard to index the meeting logs
22:22:19 <armax> though, no?
22:22:25 <amotoki> fwaas team moved their meeting to #neutron-fwaas and it works.
22:22:42 <ihrachys> I think it was even encouraged somewhere, but I struggle to find the email
22:22:56 <amotoki> armax: we can use the same title, but I am not sure how gerrit bot can pollute our logs..
22:22:57 <armax> um
22:22:59 <mlavalle> I'll ask xgerman and sridar thei experience
22:22:59 <armax> that might work
22:23:13 <armax> it’s worth a try at least once
22:23:23 <armax> and see how we do
22:23:24 <ihrachys> the "[openstack-dev] [tc][all] Move away from meeting channels" thread
22:23:36 <ihrachys> http://lists.openstack.org/pipermail/openstack-dev/2017-June/118899.html
22:23:37 <armax> ihrachys: I still think we should move to mars
22:23:46 <ihrachys> armax, well, it's 2024 no?
22:23:52 <armax> it’s not impractical at all
22:23:54 <ihrachys> gotta have some interim solution
22:23:55 <armax> actually
22:23:59 <armax> let me try something
22:24:19 * ihrachys fastened seatbelts
22:24:35 <armax> so
22:24:56 <armax> http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-10-05-22.24.log.txt
22:24:58 <armax> we’re good
22:25:06 <amotoki> I was surprised that two same name meetings can be started
22:25:18 <mlavalle> ok, let's give it a try next week
22:25:19 <armax> the danger is the noise that comes from people interleaved messages
22:25:27 <armax> unless we tell them to BACK OFF!
22:25:34 <armax> a tad rude, but that works
22:25:40 <mlavalle> in the alternate time slot
22:25:50 <mlavalle> I'll still see if I can get a meeting room
22:25:56 <armax> mlavalle: sounds good to me
22:26:15 <armax> mlavalle: shall I get quotes for tickets to mars?
22:26:17 <armax> who’s coming?
22:26:29 <mlavalle> I'll go
22:26:32 <armax> sweet
22:26:59 <mlavalle> #topic Triaged bugs
22:27:19 <mlavalle> Triaged bugs to discuss today are here: https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:27:47 <mlavalle> First up is https://bugs.launchpad.net/neutron/+bug/1653932
22:27:48 <openstack> Launchpad bug 1653932 in neutron "[rfe] network router:external field not exported" [Wishlist,Triaged]
22:28:29 <mlavalle> The way I see this one is that we have an agreement on how to move it forward
22:29:30 <armax> yup
22:29:38 <armax> we lack hands that can crack code up
22:29:54 <mlavalle> he is not to do it?
22:30:10 <mlavalle> at least we could ask
22:30:25 <armax> we could try
22:30:48 <mlavalle> unless someone in the meeting wants to go for it
22:31:09 <armax> it’s straighforward work
22:31:16 <armax> it only takes time
22:31:22 <ihrachys> does the description reflect the final idea?
22:31:26 <armax> actually I’d say this is almost low-hanging fruit
22:31:38 <armax> and it’s a great starter bug
22:31:46 <armax> because it touches many parts of the system
22:31:50 <ihrachys> it tells what's bad but doesn't say what's expected
22:31:50 <armax> but the ‘easy’ ones
22:32:35 <armax> ihrachys: what do you mean?
22:32:57 <ihrachys> armax, well from looking at the description, it's not clear what you actually agreed on in comments
22:33:15 <armax> oh
22:33:21 <ihrachys> there are multiple ideas there, and I think we need capture the final one in description so that whoever is going to implement it knows the path
22:33:30 <armax> we said we’ll expose a new API that shows the subnets for the floating IP ranges avaialble
22:33:39 <armax> ihrachys: I can do that
22:33:45 <ihrachys> go for it
22:34:41 <armax> I suggest we mark it approved and also introduce a new tag
22:34:43 <armax> rfe-ready
22:35:04 <ihrachys> define difference to rfe-approved?
22:35:09 <mlavalle> what do we want to signal with that?
22:35:15 <armax> and start advertising that with rfe-ready are approved ready that are in need of volunteers
22:36:02 <armax> the original workflow assumed that rfe-approved was for bugs that had owners on both sides of reviews and contributions
22:36:26 <mlavalle> so we transition from rfe-ready to rfe-approved once we get volunteers?
22:36:32 <armax> if we mark this one approved but no-one picks it up it’s just gonna linger
22:36:58 <armax> or we simply mark it approved without assignee
22:37:02 <amotoki> what is the difference from rfe-postponed?
22:37:16 <armax> and start advertising on the ML and team meetings for volunteers
22:37:38 <mlavalle> we can also use it in the on-boarding sessions during summits
22:37:46 <armax> rfe-postoned was for bugs that were considered worthy but had dependencies that prevented them from being worked on straightaway
22:38:19 <mlavalle> armax: are definitions (except rfe-ready) documented somewhere?
22:38:40 <amotoki> okay, rfe-postponed means it is not ready.
22:39:03 <amotoki> rfe-ready is a new proposal, so we need to document it if we use it
22:39:09 <armax> https://docs.openstack.org/neutron/latest/contributor/policies/blueprints.html,
22:39:15 <armax> but I don’t see the rfe-postponed
22:39:30 <mlavalle> I can update that document
22:39:38 <armax> mlavalle: there’s a link on the wiki page
22:39:45 <armax> and it looks like there are a few
22:39:46 <armax> https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe-postponed
22:39:54 <armax> we should go back and see which ones are still relevant
22:40:04 <mlavalle> ihrachys, yamamoto, haleyb: thoughts?
22:40:23 <ihrachys> re new tag, just post a patch and we can then discuss
22:40:24 <armax> mlavalle: anyhow, leave this with me and I’ll put some notes together and see if this can get traction
22:40:28 <mlavalle> I like the idea of a category that we can advertise for work ready to b done
22:40:38 <ihrachys> I think rfe-approved without assignee would work same, but let's take a look
22:40:49 <armax> ihrachys: agreed
22:40:53 <armax> I actually prefer that
22:41:10 <armax> so long as we’re proactive in seeking for help
22:41:14 <armax> it’s worth a try
22:41:20 <mlavalle> I am not so hung up on the tag itself
22:41:41 <ihrachys> + for advertising broadly
22:41:45 <mlavalle> I like the concept of have something ready to be picked up, though, and advertiseing it
22:42:30 <mlavalle> any other comments?
22:42:36 <armax> I suppose it’s important that the RFE being advertised is somewhat well scoped
22:42:43 <mlavalle> yeap
22:43:04 <mlavalle> the same applies to low hanging fruit bugs
22:43:20 <ihrachys> yes, that's why I asked to update description in that bug. if you think it's low hanging, you should expect people that are not in context of the project enough to understand what is expected.
22:43:24 <armax> OK, 40 mins in, we’re just 1 in
22:43:29 <mlavalle> armax: will you document this?
22:43:38 <armax> mlavalle: this being the bug?
22:43:46 <armax> mlavalle: yes
22:43:55 <ihrachys> and the process?
22:44:04 <mlavalle> the process
22:44:04 <armax> ihrachys: the process too? Oh boy, ok
22:44:06 <ihrachys> I mean, the unassigned + focus on scope
22:44:19 <armax> you guys take the whole arm with the finger
22:44:20 <ihrachys> that's how bureaucracies work
22:44:33 <ihrachys> they expand and waste ink
22:44:33 <armax> if you know what I mean
22:44:52 <mlavalle> ok, so this RFE is approved
22:45:21 <armax> mlavalle: I’d say so
22:45:42 <mlavalle> Next up is https://bugs.launchpad.net/neutron/+bug/1689830
22:45:43 <openstack> Launchpad bug 1689830 in neutron "[RFE] advanced policy for allowed addres pairs" [Wishlist,Triaged]
22:46:15 <armax> this is also another one where we said that another API might solve the use case
22:46:42 <armax> I am not particularly fond of the approach, but I suppose I get by
22:46:42 <mlavalle> yeap
22:47:01 <mlavalle> and the submitter agreed with kevinbenton's comment
22:47:26 <armax> this is also another starter bug
22:47:33 <mlavalle> I'd say so
22:49:29 <amotoki> i almost agree, but have one thing to clarify
22:49:43 <amotoki> do we suggest to add a new attribute to allowed_address_pair dictionary or add a new attr to the port dict?
22:50:13 <mlavalle> the comment says to the port
22:50:22 <armax> mlavalle:  +1
22:50:25 <mlavalle> comment #16
22:50:58 <amotoki> yeah, the comment says so.
22:51:25 <amotoki> on the other hand, it is a variation of allowed-address-paris, so I wonder which is easier to understand for end-users.
22:54:29 <amotoki> thought?
22:55:05 <amotoki> either would work and achieves the goal requested in this bug
22:55:15 <mlavalle> but I think the intent is that we are saying in the new attributes the ports from which we can take addresses for allowed-address-pairs
22:55:56 <mlavalle> in other words, the new attribute would express the range of possiblities for allowed address pairs
22:56:02 <mlavalle> does that make sense?
22:56:45 <armax> yes
22:56:54 <ihrachys> ok please update the description
22:57:00 <ihrachys> it does suggest something very different
22:57:06 <ihrachys> a new policy rule or smth
22:57:17 <mlavalle> yeah, agree with ihrachys
22:57:25 <armax> that’s why people who files RFE should refrain from making proposals
22:57:28 <armax> :(
22:57:41 <ihrachys> yeah, stick to use case
22:57:42 <armax> they should stick to describing the problem
22:57:44 <amotoki> it works for me
22:57:57 <armax> but it doesn’t matter how LOUD we said it
22:57:57 <ihrachys> who's to update
22:58:01 <armax> it doesn’t sink in
22:58:10 <mlavalle> I'll update it
22:58:13 <amotoki> so end-users will see addresses from ports specified in the new attribute?
22:58:18 <armax> mlavalle: +1
22:58:26 <armax> 2 mins to the top of the hours
22:58:30 <armax> hour*
22:58:48 <mlavalle> amotoki: no, they will see port UUID's that they can impersonate
22:59:13 <amotoki> okay
22:59:25 <mlavalle> we ran out of time
22:59:41 <mlavalle> please remember next week will try the alternate time slot
22:59:56 <mlavalle> I will send message to the ML
23:00:12 <mlavalle> Thanks for attending
23:00:19 <mlavalle> #endmeeting