20:00:04 <xgerman> #startmeeting Octavia
20:00:06 <openstack> Meeting started Wed May 27 20:00:04 2015 UTC and is due to finish in 60 minutes.  The chair is xgerman. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:10 <openstack> The meeting name has been set to 'octavia'
20:00:15 <dougwig> o/
20:00:15 <johnsom> o/
20:00:18 <xgerman> #chair blogan
20:00:18 <openstack> Current chairs: blogan xgerman
20:00:21 <Aish> o/
20:00:31 <jwarendt> o/
20:00:49 <blogan> hi!
20:00:50 <xgerman> #link https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Meeting_2015-05-27
20:01:10 <xgerman> #topic Announcements
20:01:16 <ajmiller_> o/
20:01:29 <rm_work> o/
20:01:29 <ajmiller> 0/
20:01:37 <xgerman> Midcycle:  https://etherpad.openstack.org/p/LBaaS-FWaaS-VPNaaS_Summer_Midcycle_meetup
20:01:53 <xgerman> please sign up
20:02:03 <blogan> is fwaas and vpnaas joining? or is it only lbaas now?
20:02:05 <trevhole> o/
20:02:20 <xgerman> good question - Paul said he can’t make it
20:02:43 <xgerman> so it might be very LBaaS centric
20:02:46 <blogan> haven't heard from fwaas guys?
20:02:48 <dougwig> it is just lbaas.
20:02:55 <dougwig> i spoke to both earlier.
20:03:08 <xgerman> well, where are they meeting?
20:03:23 <dougwig> you are assuming they are doing a mid cycle.
20:03:43 <dougwig> and i don't see one: https://wiki.openstack.org/wiki/Sprints
20:03:54 <ajmiller> There wasn't any specific discussion of a VPNaaS midcydle at the F2F in Vancouver on Friday.
20:04:13 <xgerman> yeah, I talked with cpm earlier and he said he won’t come
20:04:18 <xgerman> pcm
20:04:31 <blogan> pc_m hates us
20:04:44 <xgerman> he said he wants to be like us
20:04:46 <dougwig> he usually goes to the neutron meetup.  :)
20:04:55 <xgerman> yes, he said he would be there
20:04:57 <blogan> oh he hates us cuz he aint us
20:05:50 <xgerman> FW needs a mid cycle so I need to promote the one in Seattle harder
20:06:12 <dougwig> umm, why?
20:06:56 <xgerman> HP has big plans with FW
20:07:16 <dougwig> so write up a spec and post it. i'm not sure forcing a mid cycle is the path forward?
20:07:54 <xgerman> k - moving on
20:08:27 <xgerman> Links to our talks:
20:08:38 <xgerman> #link http://bit.ly/Octavia_OS_2015_video
20:08:46 <xgerman> #link https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/load-balancing-as-a-service-kilo-and-beyond
20:08:56 <xgerman> #link https://etherpad.openstack.org/p/YVR-neutron-octavia
20:09:01 <blogan> skip over my pieces
20:09:05 <xgerman> #link https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases
20:09:14 <xgerman> yeah, fast forward :-)
20:09:29 <xgerman> any other announcements?
20:09:54 <xgerman> #topic Brief progress reports
20:10:07 <xgerman> not sure if we made progress with the summit and such
20:10:19 <blogan> i got that one patch up on the plane
20:10:32 <dougwig> phil added tis support to the neutron driver.
20:10:37 <dougwig> tls
20:10:41 <blogan> oh yeah
20:11:02 <xgerman> +1
20:11:21 <blogan> i'm curious whether johnsom could reproduce the delete errors i was getting
20:11:21 <xgerman> I like eyes on https://review.openstack.org/#/c/160034/ and https://review.openstack.org/#/c/171172/
20:11:23 <johnsom> My progress report from our last IRC is I got a demo working....  grin
20:11:39 <rm_work> also added tls hookups in Octavia, right?
20:11:43 <rm_work> (ptoohill)
20:11:50 <xgerman> yep, I saw some patch
20:11:56 <blogan> ptoohill is still recovering from wasabi meltdown
20:11:57 <TrevorV> Could use more eyes here:  https://review.openstack.org/#/c/170989/
20:12:14 <TrevorV> It has a -1 from brandon from earlier, but still...
20:12:14 <johnsom> blogan no, I spent yesterday rebuilding a devstack instance to give it a go and made it close to the point where I can try it.
20:12:32 <blogan> johnsom: oh devstack problems, they're such a time sink
20:12:39 <xgerman> +100
20:12:50 <johnsom> A lot of email, expense reports, etc. to catch up on.
20:13:10 <johnsom> Yeah, tempest venv was blowing up on me, but got it going
20:13:34 <blogan> oh god expense reports, ihavet o do them too
20:13:35 <xgerman> don’t forget that we drafted you to give the Vancouver demo internally
20:13:53 <johnsom> Yeah, twice...
20:14:01 <xgerman> :-)
20:14:09 <xgerman> ok, moving on
20:14:11 <blogan> johnsom: you shouldn't have to do the vip bridge now
20:14:22 <xgerman> #topic Static Code Analysis
20:14:29 <rm_work> ah, yes
20:14:46 <rm_work> Sonar is NOT free/public, right? HP has licensed it?
20:14:59 <xgerman> nope, it’s actually open source
20:15:05 <rm_work> AH, ok
20:15:13 <johnsom> #link http://www.sonarqube.org/
20:15:17 <rm_work> so we COULD add it as part of the current pep8/pylint suite?
20:15:25 <dougwig> i'm missing context, could someone fill in?
20:15:28 <rm_work> so tox would auto-run
20:15:30 <sballe> o/ Sorry for being late
20:15:30 <blogan> before the meeting we discussed having it as a non voting job to gauge it
20:15:38 <sballe> got caught up in a meeting
20:15:43 <rm_work> blogan: ah, ok
20:15:54 <rm_work> that would work too
20:15:55 <blogan> rm_work: not easy to run in tox, its java and requires maven or something
20:16:02 <rm_work> augh :/
20:16:09 <xgerman> yeah, Designate has it as 3rd party CI so I thought we can follow their lead
20:16:12 <blogan> yeah so even if we could get tox to run it, i wouldn't want to put that on my system
20:16:16 <rm_work> thought it'd be python, since it does python code analysis
20:16:20 <xgerman> #link http://sonar.designate-ci.com/
20:16:48 <xgerman> there are python specific open source code analysis tools
20:16:48 <dougwig> do we have a 3rd-party CI for it?
20:16:50 <blogan> my concern with having it is that its an extra overhead and more hoops to jump through to get code in, which is bad for getting new contributors
20:17:05 <rm_work> yeah I am not hugely convinced it's necessary
20:17:06 <blogan> but willing to try it as a non-voting job
20:17:10 <rm_work> but yes, same
20:17:15 <rm_work> as long as I don't have to do the work to set it up
20:17:15 <johnsom> We have better coverage than they do...
20:17:42 <xgerman> dougwig: I can get us a machine on HPCloud to run 3rd party CI
20:17:44 <blogan> johnsom: so are you saying its not worth doing it?
20:18:01 <sballe> I agree we should start as non voting and then we can make it voting once we trust that it doesn't mess things up
20:18:06 <johnsom> Sorry, just an observation looking at their sonar page
20:18:10 <blogan> oh lol
20:18:24 <xgerman> Octavia code coverage > Designate Code Coverage
20:18:28 <blogan> if it starts forcing me to add @staticmethods to methods i will -2!
20:18:32 <rm_work> I don't particularly like the idea of making a voting gate job that runs tests that aren't easy to run out of the box locally
20:18:43 <xgerman> it runs in pycharm
20:18:45 <rm_work> that'd be like if the pep8 checks were a remote CI that voted, but wasn't in tox
20:18:51 <rm_work> hmm
20:18:52 <blogan> we can't force people to run pycharm
20:19:04 <xgerman> sadly, yes
20:19:08 <rm_work> I also hope it has a way to configure ignoring rules
20:19:15 <rm_work> the way pep8/hacking does
20:19:19 <blogan> i assume it does
20:19:24 <xgerman> it does
20:19:32 <rm_work> I saw a lot of #nosonar
20:19:35 <rm_work> in the patches
20:19:36 <xgerman> we have tweaked our internal one to be more foregiving
20:19:39 <rm_work> ok
20:19:49 <dougwig> let's back up a sec.  are we, as a group, committing to following the rules laid down by sonar?  this means either CI or someone regularly submitting changes to fix things up for sonar.
20:19:53 <rm_work> so you can ignore a whole rule, not just #nosonar all over
20:20:00 <blogan> this is going to casue a lot of those # nosnar thigns are they?
20:20:06 <johnsom> So, my question is does this seem of value to the team?
20:20:33 <rm_work> I don't think it's that important, but if i don't have to do anything, and it runs as part of checks locally, then i am ok with it
20:20:39 <rm_work> if it's voting but not run locally with tox, i am less OK
20:20:46 <dougwig> johnsom: i have no idea until i see the output, which is why i'm cool with a non-voting job as an experiment.
20:20:53 <blogan> johnsom: i, personally, right now think it will just be an annoyance because a lot of what it enforces is subjective and if it catches anything egregious that should be caught by code reveiws
20:20:57 <sballe> dougwig: +1
20:21:05 <rm_work> blogan +1
20:21:16 <dougwig> johnsom: but, it'll fairly quickly need to be either voting or abandoned, because non-voting it'll rot.
20:21:18 <blogan> but yes willing to try it as an experimental job
20:21:22 <rm_work> (even though we disagree about the things that are subjective)
20:21:24 <blogan> yep
20:21:32 <blogan> which makes it subjective
20:21:41 <rm_work> true :)
20:21:42 * blogan goes down the rat hole
20:21:54 <xgerman> well, we won’t quick it into a virtual blogan
20:21:59 <TrevorV> that rat hole though
20:22:00 <xgerman> tweak
20:22:14 <blogan> don't quick anything into a virtual me!
20:22:33 <dougwig> do we have that tow truck 404 page yet?
20:22:48 <xgerman> ok, I am with dougwig — let’s try it out non-voting and if it delivers values we make it voting
20:23:05 <blogan> so should we just get the job going and bring it up in each meeting as to whether we want to keep it or not?
20:23:22 <xgerman> maybe not each meeting but something like that
20:23:36 <rm_work> whelp, not-it for setting that up
20:23:45 <blogan> well i mean once we decide to get rid of it or to keep it, that'll be the last meeting for it
20:23:45 <TrevorV> Nose-goes
20:23:52 * blogan nominates xgerman
20:23:56 <TrevorV> +1
20:24:13 <xgerman> well, I already volun-told johnsom and mwang
20:24:17 <blogan> lol
20:24:20 <dougwig> if you've got a node running sonar that i can use as a slave, i can make it non-voting on every change via the a10 ci in a matter of minutes.  i really don't want to contemplate setting up another CI for gerrit ever again.
20:24:26 <johnsom> Yeah....
20:24:45 <dougwig> johnsom and mwang2_: you poor souls.  :)
20:24:49 <blogan> brings back bad memories
20:25:06 * TrevorV let blogan do it initially anyway :D
20:25:13 <blogan> one day ill set up a CI in gerrit, but that day is not today (or any day in th enear future)
20:25:28 <johnsom> I look at it as a CI learning experience....
20:25:42 <TrevorV> johnsom == glass is half full kind-of-guy
20:25:53 <mwang2_> and i learned a lot actually
20:26:01 <blogan> okay i think we got this covered
20:26:18 <rm_work> NEXT
20:26:19 <xgerman> #topic How to solve tightly coupled drivers (compute, network, amphora)
20:26:26 <blogan> this is mine
20:26:31 <xgerman> yep
20:26:32 <blogan> anyone get a chacne to read the agenda?
20:26:37 <dougwig> no
20:26:38 <johnsom> Yes
20:26:39 <blogan> lol
20:26:42 <rm_work> no
20:27:08 <xgerman> blogan recap or should we have everybody read right now
20:27:16 <blogan> tldr: amphora driver has gotten to the point where it needs to call neutron to get some information, which is bad as it shouldn't know about neutron
20:27:24 <johnsom> Personally, I like the driver model we have today, so I lean towards the data model updates.
20:27:37 <dougwig> well, option 3 kinda sucks.
20:27:38 <sballe> johnsom: +1
20:27:38 <xgerman> +1
20:27:43 <blogan> Option 1 and 2 will require the same work really, just dpeends on when the driver is called
20:27:49 <rm_work> yeah amp driver should call up to the controller or something for that info
20:27:54 <blogan> dougwig: it was just an option
20:27:56 <rm_work> and then the controller calls back down to the net drvier
20:27:59 <rm_work> *driver
20:28:21 <xgerman> I like inversion of control and have the controller just provide the info —
20:28:36 <xgerman> if we need to let’s make tasks/methods more granular
20:28:50 <blogan> so the original intent of the network driver was so we could have a neutron and nova-networks driver, but its kind of morphed into being able to satisfy every deployer's different way to hook into their networking infrastructure
20:29:04 <dougwig> which is also fine.
20:29:15 <rm_work> yeah, how ridiculous WILL option 2 be to implement?
20:29:34 <xgerman> also I hate circular references
20:29:35 <TrevorV> Does Option 2 actually remove the tight coupling though?
20:29:41 <blogan> option 1 and option 2 are the least ridiculous in my mind
20:29:42 <rm_work> yes
20:29:53 <xgerman> +q1
20:30:13 <blogan> i do prefer option 1, but option 2 is almost the same so i dont care
20:30:13 <xgerman> so after we disqualified 3
20:30:14 <dougwig> i think i like option 2 the best?
20:30:26 <rm_work> prefer 2
20:30:31 <blogan> i can go with that
20:30:41 <xgerman> dougwig what about compute call network, which call compute, which calls network
20:30:44 <blogan> we still need the data models and the extra driver methods
20:30:50 <rm_work> lol
20:30:56 <dougwig> xgerman: umm, don't do that?
20:31:00 <blogan> lol
20:31:09 <xgerman> well, we are opening the door
20:31:23 <dougwig> the door is open to add a fork bomb to every api call, too.
20:31:56 <blogan> so Option 3 and Option 4 no one likes right?
20:32:08 <blogan> you could say that they are not an option?
20:32:29 <TrevorV> I prefer Option 4
20:32:31 <TrevorV> Just cuz
20:32:32 <dougwig> option 3, we might as well not have "drivers".
20:32:34 <TrevorV> Less work
20:32:39 <blogan> dougwig: agreed
20:32:39 <rm_work> dougwig: yep
20:32:46 <xgerman> +1
20:32:53 <blogan> dougwig: well we woudl still have drivers, but that would cause us to have all these unnecessary abstraction layers
20:32:57 <xgerman> 4 tightly couples us on as neutron
20:33:19 <TrevorV> It IS an openstack project now.  Can't say I really hate that, but that's just me I guess
20:33:54 <xgerman> well, the idea of drivers was you didn’t need to call neutron directly
20:34:24 <xgerman> so it’s basically between 1 and 2
20:34:25 <xgerman> ?
20:34:44 <TrevorV> If its between 1 and 2, I like 2.
20:34:51 <johnsom> Really we just need some subnet info to configure the amp, so I don't see why we can't just make an upstream task for it that calls the network driver and passes it to the post plug task
20:35:05 <blogan> yeah and the upfront cost of both of those is the same, it just becomes whether the controller calls the driver methods or the drivers do
20:35:07 <xgerman> +1
20:35:22 <xgerman> controller calls drivers feels more sane to me
20:35:27 <TrevorV> johnsom can you guarantee we won't have to do this for anything else?
20:35:41 <blogan> TrevorV: if we do, we do teh same thing
20:35:56 <johnsom> To quote above, this is OpenStack, we can't guarantee anything
20:36:06 <xgerman> lol
20:36:19 <dougwig> which method prevents mucking with driver signatures less?
20:36:20 <TrevorV> Then why not just go with inter-driver communication?  Is that so problematic?
20:36:27 <blogan> anyway, the data models will follow the neutron model most likely, and if someone wants to do nova-networks they'll have to translate the nova-networks models into the neutron ones
20:36:35 <blogan> dougwig: they both require teh same
20:36:53 <dougwig> i think one is new kwargs options that will be required, the other is adding methods, which also will be needed.
20:37:24 <dougwig> the new methods are in both, nvm.
20:38:04 <blogan> my detailed bullet point of both doesn't actually say that they require the same, but this is something i realized after that i failed to update this on
20:38:33 <xgerman> yeah, it should be a similar effort
20:38:58 <blogan> yeah, ill volunteer myself ro this obviously so I'll let yall know if i find anything that sways it one way or the other
20:39:53 <xgerman> ok, so we have you explore and discuss next week again?
20:40:03 <sballe> ISn't nova-network getting depricated soon?
20:40:13 <xgerman> well, it’s an example
20:40:18 <dougwig> sballe: no
20:41:47 <blogan> TrevorV brought up a good piont that Option 2 would not cause a method signature to change, while Option 1 would
20:42:03 <blogan> but anyway, ill get all of this figured out and bring it up next week
20:42:12 <xgerman> cool --
20:42:27 <johnsom> Thanks blogan
20:42:45 <xgerman> #action blogan will evaluate option 1 and 2 in more detail for revisiting next week
20:42:51 <xgerman> Thnaks
20:42:53 <sballe> blogan +1
20:43:04 <xgerman> #topic Align Octavia user API with neutron-lbaas's API
20:43:53 <xgerman> blogan you have the floor
20:44:19 <blogan> yeah so the octavia API and neutron lbaas API differ and I think it would be beneficial if Octavia was a superset API of neutron-lbaas, meaning it was exactly teh same as neutron-lbaas but with more functionality
20:44:34 <rm_work> hmm
20:44:36 <sballe> blogan: +1
20:44:36 <blogan> Octavia's API was created prior to neutron-lbaas v2 API being finalized
20:44:45 <blogan> so thats why its a bit different
20:44:50 <xgerman> blogan +1
20:44:54 <rm_work> that would actually be useful -- does that make anything we were trying to do any harder? I assume not
20:45:04 <rm_work> since neutron-lbaas would have to support anything we wanted to do
20:45:09 <blogan> well it will require more work to get teh API calls the same
20:45:22 <rm_work> sure, but no real PROBLEMS with doing that
20:45:33 <xgerman> yeah, besides more work I don’t see any downside
20:45:35 <dougwig> also makes the driver capable of being even dumber.
20:45:37 <blogan> nah its pretty much all the same info, just strucutred ifferently
20:45:51 <johnsom> Sounds good to me
20:46:01 <blogan> ill add a launchpad bug for that
20:46:05 <sballe> +1
20:46:15 <dougwig> stretch goal here is when neutron-lbaas needs its own rest agent, there's a pleasant little home waiting for it in octavia.
20:46:20 <xgerman> not sure if it’s broken — so lp task might be better
20:46:23 <dougwig> that's a few cycles off, i'd wager.
20:46:35 <blogan> yeah and it doesn't break backwards compatibility
20:46:44 <blogan> lp task?
20:46:48 <blogan> you mean BP?
20:46:52 <xgerman> yep
20:47:07 <xgerman> the non-bug thing
20:47:45 <blogan> aren't RFEs bug reports in neutron now?
20:47:56 <xgerman> dougwig?
20:47:58 <dougwig> correct.
20:48:02 <johnsom> Yep
20:48:09 <blogan> so it fits with that
20:48:18 <dougwig> but, octavia doesn't need to follow neutron's process for that.  unless it wants to.
20:48:35 <xgerman> filing a bug report for something which isn’t broken...
20:48:49 <xgerman> but I better get with the program
20:49:03 <sballe> xgerman: We did this for the advsvc role in neutron and it worked well
20:49:08 <blogan> lol, RFEs are bug reports for a reason, but i don't think in this instance those matter
20:49:45 <xgerman> #action blogan file RFE in launchpad for aligning Octavia API with Neutron LBaaS V2
20:49:54 <dougwig> as long as kyle isn't organizing our milestones in LP, we can do whatever mechanism we want.
20:50:14 <blogan> mestery agreed to organize all launchpads under the neutron stadium
20:50:32 <xgerman> #topic Open Discussion
20:50:36 * blogan waits for the lightning bolt of rage from mestery
20:51:01 <blogan> how do people think the working session went?
20:51:02 <dougwig> haha, he did not.
20:51:03 <blogan> was it useful?
20:51:17 <johnsom> We have some documentation type things in gerrit that are getting old.  Any thoughts on what we should do with those?
20:51:18 <xgerman> we fixed the routing problem :-)
20:51:36 <dougwig> johnsom: are they clean (no -1's) ?
20:51:41 <blogan> well that wasn't in the working session, we discussed octavia becoming the ref impl in the working sessions
20:51:45 <blogan> honestly it just wasn't enough time
20:51:46 <johnsom> No, they all have -1s I thinkg
20:51:46 <xgerman> isn’t sbalukoff coming back to finish them
20:52:02 <rm_work> yeah we needed like... another 2 h
20:52:18 <dougwig> johnsom: i expect that's why they're languishing.  are the original commiters still around to update?
20:52:22 <blogan> johnsom: i think we should update them, we should actually start thinking about having some kind of final documentation point
20:52:23 <xgerman> well, I think compared to other working sessions I went to ours were pretty productive
20:52:53 <xgerman> blogan +1
20:53:08 <sballe> blogan: +1
20:53:30 <johnsom> Ok, so let's take a new pass over these this week and we can pick docs we will take ownership of
20:53:46 <xgerman> johnsom +1
20:53:50 <blogan> okay
20:53:52 <sballe> johnsom: +1
20:54:08 <rm_work> plug for https://review.openstack.org/#/c/184868/
20:54:13 <blogan> plug denied
20:54:15 <rm_work> we should really be py3 compat
20:54:17 <rm_work> >_>
20:54:18 <sballe> lol
20:54:22 <rm_work> no reason to not be
20:54:32 <blogan> except py3 is the spawn of the devil
20:54:35 <rm_work> <_<
20:54:45 <johnsom> Haha
20:54:45 <rm_work> py3 fixes a lot of stuff, and py2 is essentially dead now <_<
20:54:59 <blogan> its the most human of all zombies
20:55:00 <madhu_ak> would like to have code reviews for the pending patches in neutron-lbaas --> especially testscenarios
20:55:43 <rm_work> it is good to get stuff like compatibility checks in early, to prevent further divergence
20:55:51 <rm_work> right now it isn't too bad
20:55:54 <sballe> rm_work: +1
20:56:03 <dougwig> madhu_ak: those tests are waiting on the job being fixed, which is my fault at present.
20:56:05 <johnsom> rm_work +1
20:56:09 <rm_work> the only wonky bit really is the mock changes
20:56:13 <xgerman> yep, and once we rewrite everything in Ruby that might help
20:56:15 <blogan> madhu_ak: we definitely need to start getting those reviewed
20:56:19 <rm_work> lol xgerman
20:56:23 <madhu_ak> oh, okay. sure
20:56:36 <xgerman> or was it Go people were plugging?
20:56:40 <blogan> Go
20:56:48 <sballe> +1 for Go
20:56:48 <dougwig> madhu_ak: the tenant tests are broken, if you wanted something to tweak in the meantime.  they create a bunch of objects owned by admin, then create the final object owned by another tenant.  they should really be creating all the objects as the other tenant.
20:56:49 <blogan> dougwig is always plugging Ruby
20:56:49 <rm_work> Golang! :P
20:57:09 <xgerman> bloagn +1
20:57:13 <xgerman> blogan +1
20:57:28 <dougwig> inline assembly, ya whimps.
20:57:32 <madhu_ak> dougwig: sure
20:57:53 <TrevorV> dougwig I actually had a nack for assembly in school.  Nothing on this level of coding thoguh
20:57:54 <johnsom> +1 assembly
20:57:55 <TrevorV> though***
20:58:09 <TrevorV> I was real good at ML as well
20:58:19 <dougwig> ooh, i love ML.
20:58:28 <dougwig> strongly typed and functional, yes.
20:58:43 <rm_work> yes
20:58:48 <rm_work> strongly typed plox
20:58:53 <xgerman> Haskell?
20:58:57 <rm_work> ML was great
20:58:59 <TrevorV> Believe it or not, rm_work and I are bonding a little on this topic
20:59:00 <rm_work> I would do ML
20:59:23 <xgerman> ok, we are out of time
20:59:28 <xgerman> #endmeeting