20:00:10 <xgerman> #startmeeting Octavia
20:00:11 <openstack> Meeting started Wed Feb 18 20:00:10 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:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:14 <openstack> The meeting name has been set to 'octavia'
20:00:19 <xgerman> #topic Roll Call
20:00:21 <xgerman> o/
20:00:27 <johnsom> o/
20:00:27 <ajmiller> o/\
20:00:59 <mwang2> o/
20:01:17 <TrevorV> o/
20:01:31 <dougwig> Sort of
20:02:12 <xgerman> Agenda: #link https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda
20:02:54 <xgerman> #topic  Brief progress reports
20:02:56 <rm_work> o/
20:03:24 <fnaval> o/
20:03:50 <TrevorV> xgerman I have no progress Octavia side :(
20:04:24 <xgerman> I updated the api spec:
20:04:26 <xgerman> https://review.openstack.org/#/c/126801/
20:04:30 <xgerman> I need +2s
20:04:44 <xgerman> mwang2, johnsom?
20:04:48 <mwang2> yes
20:04:55 <johnsom> I have rolled a few WIPs on controller worker.  Should be able to do *something* useful this week.
20:05:16 <TrevorV> Awesome johnsom glad to hear it
20:05:19 <mwang2> so i have submitted the health manager part, please feel free to review https://review.openstack.org/#/c/149802/6
20:05:48 <xgerman> awesome
20:05:55 <mwang2> https://review.openstack.org/#/c/149802
20:06:27 <xgerman> ok, I think we can move on
20:06:30 <mwang2> also i am working on the API doc task, will submit the new update shortly
20:06:31 <rm_work> I'll take a look at your review xgerman
20:06:41 <xgerman> #topic python setup.py install fails
20:06:42 <mwang2> https://review.openstack.org/#/c/148687/
20:06:46 <xgerman> johnsom you have got the floor
20:07:02 <xgerman> thanks rm_work
20:07:36 <johnsom> In setting up a test box for the controller worker I found that someone merged some "cache.py" code that breaks 'python setup.py install'
20:07:50 <johnsom> byte-compiling /usr/local/lib/python2.7/dist-packages/octavia/openstack/common/cache/cache.py to cache.pyc
20:07:51 <johnsom> File "/usr/local/lib/python2.7/dist-packages/octavia/openstack/common/cache/cache.py", line 41
20:07:51 <johnsom> def _get_oslo.configs():
20:07:51 <johnsom> ^
20:07:51 <johnsom> SyntaxError: invalid syntax
20:08:27 <johnsom> Does anyone know anything about this code?
20:09:01 <dougwig> Sort of
20:09:10 <clarkb> remove the '.'?
20:10:10 <rm_work> yeah you can't have a dot in a function def...
20:10:40 <dougwig> That code should've been copied from incubator
20:11:17 <johnsom> I am just not sure why this code is here, etc.  I was looking for someone that has more background and could fix it, remove it, pull from upstream, whatever needs to happen
20:11:20 <crc32> how did that even get merged?
20:11:36 <xgerman> good question crc32 :-)
20:11:41 <dougwig> I can look today
20:11:49 <xgerman> thanks dougwig
20:11:54 <johnsom> Thanks dougwig
20:12:00 <dougwig> On phone now
20:12:06 <xgerman> #action dougwig looks at broken setup.py
20:12:07 <johnsom> I would like to keep going on controller worker
20:12:22 <xgerman> I guess we can move on
20:12:38 <xgerman> #topic amphora-haproxy driver
20:13:14 <xgerman> So last time we decided that RAX would do a stop-gap ssh based driver whereas HP will try to get the REST based one done
20:13:46 <TrevorV> sounds about right xgerman, with me on that SSH task.
20:13:47 <xgerman> we did some chatting in the channel prior to this meeting and the Q is should w emake two different drivers, one which can do both, or...
20:14:21 <rm_work> i would have assumed two different amp drivers? though it they share 90% of their code that seems a bit repetitive
20:14:22 <TrevorV> xgerman I don't think a dual-driver is the right answer personally.  I think individual drivers is the right way to go.
20:14:36 <xgerman> +1
20:15:02 <rm_work> ok yeah TrevorV points out code-share is virtually zero
20:15:06 <rm_work> sooo I'd assume two drivers
20:15:10 <rm_work> ssh-amp and rest-amp
20:15:13 <rm_work> or whatever
20:15:24 <dougwig> It defeats the purpose of two if we couple them
20:15:31 <xgerman> ok, so I need to create another blueprint...
20:15:37 <TrevorV> I actually sort of considered the SSH "driver" in this case similar to the amphora API client I wrote a while back.
20:15:59 <TrevorV> Basically what ptoohill is writing/ has written will load either that client, or the ssh-driver I will make, and utilize that to configure HAProxy
20:16:03 <TrevorV> Does that sound right ptoohill ?
20:16:09 <ptoohill> no
20:16:16 <ptoohill> i wrote towards the amp api
20:16:28 <TrevorV> You wrote towards method definitions, right?
20:16:36 <TrevorV> The SSH driver can still implement those methods.
20:16:46 <ptoohill> sure
20:16:56 <ptoohill> i also call your client...
20:17:03 <TrevorV> That's what I'm talking about, the client.
20:17:11 <rm_work> there's an Amphora Interface, right? that all Amp drivers implement?
20:17:17 <ptoohill> then im unsure what youre getting at
20:17:27 <ptoohill> yes
20:18:16 <ptoohill> i was suggesting a possible shim/wrapper that could call either one of the 'backends' inorder to save on code dupe since they are essentially the same driver doing the same thing. But the ssh driver is just a temp solution so i suppose it doesnt matter how we do that one
20:18:46 <TrevorV> Alright, here is the disconnect I just had.
20:19:02 <ptoohill> i was just curious if the code i have out there was going to be reused by hp guys or not and if i should abandon that one and move forward with 'our' version
20:19:05 <TrevorV> I wasn't thinking the SSH code would live at a higher level than the REST client I wrote a while ago
20:19:21 <ptoohill> it wont
20:19:25 <xgerman> we are happyn to reuse
20:19:43 <ptoohill> granted it may just get overhauled anyhow, but was curious xgerman
20:20:10 <TrevorV> Right.  Okay, so I guess I confused myself about what you were doing at the REST Driver layer you wrote ptoohill
20:20:23 <TrevorV> You import my client and use the methods right?
20:20:32 <ptoohill> yes
20:20:39 <TrevorV> So we're talking about adding an SSH implementation to THOSE methods?  In the client?
20:20:54 <ptoohill> so call a rest client to do ssh?
20:21:16 <TrevorV> That's exactly my problem, what are we talking about merging at this point?
20:21:31 <rm_work> the methods are what's specified in the interface for the amp driver
20:21:32 <rm_work> right?
20:21:44 <xgerman> yep, we have the interface
20:21:51 <rm_work> right
20:21:58 <ptoohill> well either need to call a rest client OR and ssh 'client' to do things
20:22:00 <rm_work> so whatever driver is under the Amphora Interface
20:22:21 <xgerman> yep
20:22:48 <xgerman> and my impression was we needed two drivers but ther eis the question of reuse
20:22:58 <xgerman> sicne we need to generate a haproxy config file in both
20:23:11 <ptoohill> yea, which could be done with shim/wrapper and config option
20:23:27 <rm_work> I assumed there'd be another interface layer
20:23:46 <ptoohill> but, since the ssh one is temp(i assume) we can do it seperately and remove when done. unelss we plan on keeping this one also
20:24:00 <ptoohill> theres not currently, but could be the other solution
20:24:02 <xgerman> I think we will stick to removing it
20:24:05 <rm_work> Controler -> Amp (HAProxy) Driver -> Communication (SSH || REST) Driver -> Amphora
20:24:14 <rm_work> *Controller
20:24:38 <xgerman> yeah, that would be another way to skin the cat
20:26:01 <TrevorV> So that's what I was personally invisioning as well.
20:26:07 <TrevorV> We'd just have SSH instead of REST.
20:27:18 <xgerman> that looks like a better way to me since we are just changing transport
20:27:31 <xgerman> (and some ssh magic)
20:27:57 <ptoohill> im ok with anything honestly, i was just asking what should be done since i was the owner of the bp
20:28:04 <TrevorV> So what should happen, in my opinion, is we should make an interface for the communication step, and have the REST client I wrote before just be an implementation of that, and then make an SSH implementation of that as well, and then we're all gucci
20:28:18 <xgerman> +1
20:28:30 <ptoohill> so then we plan on keeping the ssh stuff in tree?
20:28:31 <dougwig> the ssh driver is really meant to be quick and dirty.  need an LB?  ssh, apt-get install a bunch, cat > file, go.  i'm not seeing where the amps share anything.  one is far more sophisticated.
20:28:37 <ptoohill> +1
20:28:53 <xgerman> dougwig +1
20:28:54 <ptoohill> the only thing would be config
20:29:05 <ptoohill> building it*
20:29:27 <ptoohill> which isnt tied directly into driver so it can be reused
20:29:39 <ptoohill> yea, this is a non issue, i was just curious
20:29:41 <TrevorV> That's understandable dougwig, and while its still quick and dirty does it hurt keeping the communicative step abstract just in case someone wants to make something else be the communication piece?
20:29:41 <xgerman> yeah, and also part of LBaaS V2
20:29:47 <rm_work> yeah right now that driver layer is the "WHAT" and the "HOW"
20:30:01 <rm_work> we need it to JUST be the WHAT (HAProxy, in our case), and the HOW would be either SSH or REST
20:30:16 <dougwig> TrevorV: only if you defeat the purpose of a quicker pass to demo-ware by tying schedules together.
20:30:17 <rm_work> it's "yet another layer" >_>
20:30:18 <rm_work> but
20:30:18 <ptoohill> i guess i dont see that as a thing though
20:30:26 <ptoohill> this is a temp solution
20:30:27 <rm_work> eh
20:30:30 <ptoohill> that will be removed
20:30:31 <rm_work> I have to bbl
20:30:34 * rm_work disappears
20:30:53 <TrevorV> Sorry dougwig I don't actually know what you mean there.
20:30:54 * rm_work was summoned by the great and powerful Uma
20:31:02 <ptoohill> lets just do two separate ones so we can do what we intially planned on with the ssh driver
20:31:15 <xgerman> ok, and that makes it easier for people working on it
20:31:18 <TrevorV> two separate ones what?
20:31:21 <ptoohill> indeed
20:31:23 <ptoohill> drivers
20:31:27 <xgerman> drivers
20:31:38 <TrevorV> So essentially write your layer again as SSH-HAProxy-Driver
20:32:01 <xgerman> yep, the REST driver should not be mauch code anyway
20:32:40 <dougwig> TrevorV: the point of a quick and dirty ssh driver is schedule risk mitigation.  that's it.  by tying it to *any* part of another schedule, you're diluting the point.  it's not meant to be long-lived with tendrils into other things.. IMO.
20:33:42 <ptoohill> i just wanted to argue with xgerman today, thats all ;)
20:33:58 <xgerman> #agreed write two drivers
20:34:00 <TrevorV> I still can't say I follow you dougwig but we can offline that.
20:34:12 <ptoohill> I am in agreement
20:34:27 <TrevorV> I don't, but there seem to be more in favor of it than against, so I'll deal :)
20:35:17 <xgerman> I like the reuse aspect as well as the scheudling one - so I am torn...
20:35:34 <xgerman> anyhow, let's move on
20:35:45 <xgerman> #topic Future of this meeting
20:36:15 <xgerman> Yesterday in the lbaas meeting we decided to merge LBaaS and Octavia (merger of equals)
20:36:23 <xgerman> when it comes to meetingds
20:36:47 <dougwig> i think we decided to decide at vancouver.
20:37:01 <dougwig> btw, since folks didn't seem to know how the neutron on-demand stuff works, here: http://lists.openstack.org/pipermail/openstack-dev/2014-October/048328.html
20:37:23 <TrevorV> (I still think on-demand makes more sense for neutron lbaas, but eh)
20:38:17 <xgerman> yeah, I need to attend a few neutron meetings to form an opinion ;-)
20:38:40 <dougwig> half of them are nicely timed.  the other half are good for our international folks.  :)
20:39:54 <xgerman> ok, so we will defer that to after Vancouver.
20:39:56 <TrevorV> So xgerman do we push this conversation off until after vancouver then?
20:39:59 <TrevorV> ha
20:39:59 <TrevorV> got it
20:40:12 <xgerman> yeah, I just wanted to make sure we got it mentioned ;-)
20:40:23 <xgerman> #topic Open Discussion
20:40:57 <dougwig> flavors!  if anyone of you are interested in flavors in kilos, I need eyeballs: https://review.openstack.org/#/c/139758/
20:41:27 <TrevorV> I can take a look later dougwig
20:41:31 <xgerman> +1
20:41:48 <johnsom> Yes, cool, however in merge conflict.  Review now or after that is cleaned up?
20:41:51 <TrevorV> If anyone has other spare review cycles, the LBaaS v2 Tempest API tests are well on their way to being finished
20:42:03 <johnsom> I.e. is a patchset just about to land?
20:42:07 <dougwig> feedback is good now.  +1 to just show support/desire, later.
20:42:17 <dougwig> i'm not doing one today, no.
20:42:37 <johnsom> Ok, thanks
20:42:45 <dougwig> TrevorV: i'll be on those today
20:42:46 <xgerman> TrevorV we will have a look
20:43:10 <TrevorV> Alright, I think crc32 has the members one in progress still, but the other 4 could use some eyes
20:43:22 <TrevorV> Thanks guys
20:44:45 <xgerman> anyhting else?
20:45:22 <xgerman> #endmeeting