Friday, 2014-09-05

*** sballe has quit IRC00:06
*** mlavalle_ has quit IRC00:07
*** dkehnx1 has joined #openstack-lbaas00:08
*** sbfox has joined #openstack-lbaas00:22
rm_youdougwig: heh00:54
*** mwang2 has joined #openstack-lbaas01:31
*** mwang2_ has quit IRC01:34
*** mwang2 has quit IRC01:38
*** mestery has quit IRC01:41
*** mestery has joined #openstack-lbaas01:42
*** jamiem has quit IRC02:01
*** woodster_ has quit IRC02:05
*** xgerman has joined #openstack-lbaas03:19
*** sbfox has quit IRC03:55
*** sbfox has joined #openstack-lbaas04:05
*** xgerman has quit IRC05:09
*** amotoki has joined #openstack-lbaas05:52
*** sbalukoff has joined #openstack-lbaas05:55
*** jschwarz has joined #openstack-lbaas06:52
*** jschwarz_ has joined #openstack-lbaas07:22
*** jschwarz has quit IRC07:24
*** jschwarz__ has joined #openstack-lbaas07:51
*** jschwarz_ has quit IRC07:54
*** jschwarz__ has quit IRC07:58
*** enikanorov has quit IRC07:58
*** jschwarz has joined #openstack-lbaas08:10
*** jschwarz has quit IRC08:10
*** jschwarz has joined #openstack-lbaas08:11
*** dkehnx1 has quit IRC08:16
*** jschwarz has quit IRC08:23
*** dkehnx1 has joined #openstack-lbaas08:28
*** openstackgerrit has quit IRC12:01
*** openstackgerrit has joined #openstack-lbaas12:03
*** amotoki has quit IRC12:45
*** ptoohill has quit IRC14:36
*** woodster_ has joined #openstack-lbaas14:45
*** sbfox has quit IRC14:58
*** ptoohill has joined #openstack-lbaas15:20
*** mlavalle has joined #openstack-lbaas15:40
*** markmcclain has joined #openstack-lbaas15:41
*** markmcclain1 has joined #openstack-lbaas15:45
*** markmcclain has quit IRC15:46
*** ptoohill has quit IRC15:54
*** sbfox has joined #openstack-lbaas16:22
*** mwang2 has joined #openstack-lbaas16:42
*** openstackgerrit has quit IRC17:04
*** ptoohill has joined #openstack-lbaas17:08
*** sbfox has quit IRC17:10
*** markmcclain1 has quit IRC17:10
*** HenryG is now known as HenryThe8th17:12
*** carl_baldwin has joined #openstack-lbaas17:17
*** nealph_ has joined #openstack-lbaas17:18
*** crc32 has joined #openstack-lbaas17:18
nealph_dougwig: have added you as reviewer on
nealph_all your previous feedback from the bp approval cycle has been included, I believe.17:21
*** jorgem has joined #openstack-lbaas17:24
*** sbfox has joined #openstack-lbaas17:29
dougwignealph_: thanks, i will look at that shortly.17:36
*** carl_baldwin has left #openstack-lbaas17:36
nealph_cool...feel free to ping me with questions in the #openstack-ceilometer room.17:36
*** sbfox has quit IRC17:39
*** sbfox has joined #openstack-lbaas17:43
*** mestery is now known as man_of_mystery17:43
*** sbfox has quit IRC18:11
*** openstackgerrit has joined #openstack-lbaas18:11
*** man_of_mystery is now known as mestery18:25
*** sbfox has joined #openstack-lbaas18:26
*** mwang2 has quit IRC19:00
*** openstackgerrit has quit IRC19:01
*** openstackgerrit has joined #openstack-lbaas19:02
bloganim +2'ing dougwig's skeleton review19:14
blogan+A as well.  Any objections?19:14
crc32you mean the review about using the name "amphora"? I think rackspace is burned out objected to it. Just get it over with.19:16
bloganactually we have 2 who like it19:16
bloganor 4 who do not19:17
bloganand 1 abstain19:17
crc32but thers totally no objection. Since the definition of an objection means people willing to complain on the ML.19:17
rm_workI would wait on +A19:17
bloganmeh im pretty sure it has won19:18
crc32And I keep misspelling it. I keep getting prehistoric plant looking things.19:18
a2hillbattlestar-loadtallica should have won, js19:22
a2hillthe votes were rigged and i demand a recount!19:22
dougwigblogan: wait on +A.19:26
dougwigwe need some way for votes to carry a weight based on emphatic-ness.  because i'm not really that strongly in favor of anything19:26
dougwigjorgem: how strong is your hate?  turn to the dark side with the emperor, or just m'eh?19:26
crc32jorge et all is playing foosball right now. He hates the term but is willing to accept it but objects to the voting process more then anything and wants it fixed before something else slips in later on.19:27
dougwigthe voting was crap all around, and that's totally my fault.19:28
crc32Thats fine but we need a properly documented voting process from here out. I think we should just learn from this and move on. Every one is so sensative now that no one wants to publicly object to anything and a properly documented flash voting document would prevent any mistrust of the system moving forward.19:32
*** sbfox has quit IRC19:33
a2hilli was totally just kidding above btw, I like all the things19:34
dougwigcrc32: +1 to standardized voting.19:34
dougwigi think irc meetbot even has a voting mechanism built-in.19:34
crc32a2hill: I know you don't like making waves you you abstain. I feel some what the same, I typically only object internally here at rackspace but eventually submit to the will of the one guy who is overly opinionated. Its the draw back of living in a Jury culture.19:38
a2hillwell yea, this is true.19:39
a2hillI think will continue to reference it as battlestar-loadtallica :P Just because it was the feasible but most awesome :D19:41
crc32Any thhink it will be snowing in Paris in November. 4 of our guys(Rackspace Lbaas team) Are going after all.19:42
a2hillJen looked up weather and its in the 'freezing' category, so i would assume that if percipitation there may be snow.19:42
*** mwang2 has joined #openstack-lbaas19:42
a2hillDef cant dress like a Texan in other words ;)19:43
a2hillMeans blogan will have to actually wear clothing there19:43
jorgemhey dougwig. No hate. Just want to make sure voting process is fair.19:52
dougwigit certainly wasn't, which is why i'm trying to gauge whether we need a recount.19:52
jorgemI honestly want to move forward with naming this thing so anything is better than nothing19:52
rm_workand I am *emphatically* for Amphora :)19:53
jorgemIf others feel strongly then I'll join in. Otherwise my point wasn't on the term just the process19:53
bloganmy point has been on the term!19:53
bloganbut i will go with the will of the people as well19:54
dougwigjorgem: agree.  lesson learned was to not try to rush it.19:54
crc32I think its a horrible name but don't care any more. Its better to maintain relationships then pick a proper name.19:54
jorgemno worries :)19:54
dougwigheh, we've almost reach the point where "generic-blob-of-attrition" sounds good.19:55
crc32just keep it fair next time dougwig.19:55
sbalukoffSo, the meetbot does have a voting system, but it's only got binary options (ie. Yes / No)19:56
sbalukoffThat doesn't work as well for open-ended multiple choice things like this.19:57
*** sbfox has joined #openstack-lbaas19:57
blogani was thinking we could do it in gerrit, except upload a file that has the list of options and then everyone puts a comment +119:57
sbalukoffdougwig: Do you want to draft a voting system for non-binary votes?19:57
crc32we should right a voting bot.19:57
crc32one that accepts write in ballots properly.19:57
sbalukoffcrc32: Or submit a pull request to improve the one that's there.19:57
blogani think the gerrit option is the best19:57
crc32but we need a vote bot ASAP.19:58
bloganeveryone will be notified when a new version is up19:58
bloganand no one has to write a vote bot19:58
sbalukoffblogan: You just want to make sure our meetings keeping happning in IRC. ;)19:58
sbalukoffI see what you're doing there! XD19:58
crc32yea cause why write code. We'd never want to do that.19:58
blogandoing it in gerrit keeps the meeting in IRC?19:58
sbalukoffblogan: Oh, sorry, I thought you were advocating an IRC votebot.19:58
sbalukoffAnyway, I'm just ribbing you right now. :)19:59
blogansbalukoff: no I'm advocating putting a file in gerrit with a list of items to vote on and then everyone adds a comment to vote19:59
blogansbalukoff: i know you were, i just knew you thought I meant do it in IRC19:59
dougwiggerrit or some outside thing that can be left open for awhile sound best to me.20:00
sbalukoffblogan: Hmmm...  how do you gather the options that people can vote amongst?20:00
sbalukoffAnd how many +1's do they get?20:00
sbalukoffAnd do we allow -1s?20:00
blogandepends on how to do the voting20:00
dougwigi think more important is to standardize how long votes will be open/how quickly we can get closure.  my biggest sin wasn't in trying to affect the result, but in trying to get to it too quickly.20:00
dougwig(because i didn't care much about the result in this case.)20:01
bloganwell it was my sin that I didn't put anything on the ML about it when I thought it should have20:01
bloganhave I ever mentioned I hate naming things?20:01
sbalukoffAs for the amphora name:  While I like the name, I'm not uber-excited about it. Mostly, I think it's mostly arbitrary, so am happy just to see a name chosen so we can move on.20:01
dougwigi think we both want to just get back to coding.  this is standing in the way.  and it's important.  yet small.  yet important.20:02
sbalukoffblogan: One of the two hardest problems in computer science.20:02
sbalukoffdougwig: Exactly!20:02
bloganis it possible to just accept the review for now and refactor later if it is decided to change the name?20:02
bloganbc I'm 90% sure amphora will win20:02
sbalukoffblogan: Except a refactor is unlikely to happen. And also, this affects terminology we're going to be using from here on out.20:02
sbalukoffSo small, mostly arbitrary, but important.20:02
bloganand there will be a history and if we switch terminologies20:03
blogannot the best20:03
bloganwell honestly its not slowing anyone down, its just a dependency chain we can all live with20:03
sbalukoffI'm all in favor of just accepting this for now, perhaps drafting rules around voting that we'll follow in the future, and move on (ie. get some code done.)20:03
dougwigblogan: i was thinking that maybe we accept it, sit with it for 2 weeks, then see it how feels.20:04
dougwiganything is better than just stalling on a name.20:05
sbalukoffdougwig: Sure.20:05
bloganalright lets vote on whether we should accept it now or not20:05
openstackblogan: Error: "votebot" is not a valid command.20:06
dougwig#startvote should we accept amphora for now?20:06
blogandamn you votebot!20:06
sbalukoffCan't do it outside of a meeting?20:06
openstackblogan: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.20:06
dougwig#startmeeting throwaway-vote20:06
openstackMeeting started Fri Sep  5 20:06:46 2014 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:06
openstackThe meeting name has been set to 'throwaway_vote'20:06
dougwig#startvote should we accept amphora for now?20:06
openstackBegin voting on: should we accept amphora for now? Valid vote options are Yes, No.20:06
openstackVote using '#vote OPTION'. Only your last vote counts.20:06
sbalukoff#vote Yes20:07
blogan#vote Yes20:07
blogani was joking about voting on it btw20:07
dougwigi was experimenting.20:07
sbalukoffdougwig: I imagine some people are going to be really confused about the purpose of the 'throwaway-vote' project.20:07
bloganif we had our talks in webex, you would have recognized my sarcasm20:07
dougwiglet's vote on if i'd recognize it.20:08
sbalukoffAah! It's friday, right?20:08
sbalukoffI think the loopiness is setting in somewhat early today.20:08
bloganfuck it fridays20:08
dougwigi filled my amphora with bourbon this morning.20:08
sbalukoffHoly crap, that's a lot of bourbon!20:08
openstackVoted on "should we accept amphora for now?" Results are20:08
blogani filled my amphora with tears20:09
sbalukoffYeah, I don't think votebot works.20:09
dougwigit takes awhile.20:09
crc32mine broke.20:09
blogan!help list20:09
openstackblogan: (list [--private] [<plugin>]) -- Lists the commands available in the given plugin. If no plugin is given, lists the public plugins available. If --private is given, lists the private plugins.20:09
dougwigit's thinking.20:09
sbalukoffIt doesn't seem to know how to compile the results.20:09
openstackMeeting ended Fri Sep  5 20:09:33 2014 UTC.  Information about MeetBot at . (v 0.1.4)20:09
openstackMinutes (text):
openstackblogan: Admin, Channel, ChannelLogger, Config, MeetBot, Misc, Owner, Services, and User20:09
sbalukoffHaha! Our shenanigans are being captured for posterity.20:09
blogan!Channel list20:09
openstackblogan: Error: 'supybot.list' is not a valid configuration variable.20:09
blogan!help Channel list20:10
openstackblogan: Error: There is no command "channel list".20:10
dougwig!help meetbot20:10
openstackdougwig: Error: There is no command "meetbot".20:10
openstackblogan: (channel [<channel>] <name> [<value>]) -- If <value> is given, sets the channel configuration variable for <name> to <value> for <channel>. Otherwise, returns the current channel configuration value of <name>. <channel> is only necessary if the message isn't sent in the channel itself.20:10
openstackblogan: Error: "Services" is not a valid command.20:12
openstackblogan: Admin, Channel, ChannelLogger, Config, MeetBot, Misc, Owner, Services, and User20:12
bloganbut services is a command!20:13
openstackblogan: Error: "Admin" is not a valid command.20:13
bloganor i am an idiot and dont know how to use an irc bot20:13
bloganthat is more likely20:13
blogan#startmeeting throwaway-vote20:15
openstackMeeting started Fri Sep  5 20:15:12 2014 UTC and is due to finish in 60 minutes.  The chair is blogan. Information about MeetBot at
sbalukoffI once drafted voting rules for multiple-option voting in the past...  I could see if I could relocate those again.20:15
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:15
openstackThe meeting name has been set to 'throwaway_vote'20:15
sbalukoff(This was like 10 years ago.)20:15
blogan#startvote What name is best? Amphora, Appliance, Mechanism, Device20:15
openstackBegin voting on: What name is best? Valid vote options are Amphora, Appliance, Mechanism, Device.20:15
openstackVote using '#vote OPTION'. Only your last vote counts.20:15
bloganthere youg o20:15
bloganyou can do multiple items20:15
sbalukoffIn a nutshell, you collect ideas for a certain period, and depending on the number of ideas collected, each person gets a certain number of votes that they can distribute as they see fit.20:15
sbalukoff(all on one option if you're feeling really strongly about it, or distributed among a few options you wouldn't mind having.)20:16
blogan#vote NotAmphora20:16
openstackblogan: NotAmphora is not a valid option. Valid options are Amphora, Appliance, Mechanism, Device.20:16
blogan#vote Appliance20:16
sbalukoffblogan: You still get one vote, though.20:16
sbalukoffSo the "emphatic" person has as much say on the items as the "meh" person. :/20:17
sbalukoffThat is to say, you can't express your degree of enthusiasm for a given idea. ;)20:17
sbalukoff#vote Toaster20:18
openstacksbalukoff: Toaster is not a valid option. Valid options are Amphora, Appliance, Mechanism, Device.20:18
sbalukoff#vote Amphora20:18
sbalukoff#vote Toaster20:18
openstacksbalukoff: Toaster is not a valid option. Valid options are Amphora, Appliance, Mechanism, Device.20:18
blogan#vote Appliance20:21
openstackVoted on "What name is best?" Results are20:21
openstackAmphora (1): sbalukoff20:21
openstackAppliance (1): blogan20:21
bloganthere we go!20:21
openstackMeeting ended Fri Sep  5 20:21:49 2014 UTC.  Information about MeetBot at . (v 0.1.4)20:21
openstackMinutes (text):
blogansbalukoff: i know but this will at least work well with the runoff we had, that and people who are meh would not vote20:22
sbalukoffblogan: It's not a bad start.20:23
sbalukoffBut why go with a simple solution if we can make it way more complicated? >.>20:23
*** sbfox has quit IRC20:36
*** sbfox has joined #openstack-lbaas20:36
*** sbfox has quit IRC20:38
*** sbfox has joined #openstack-lbaas20:39
*** mwang2_ has joined #openstack-lbaas20:54
*** mwang2 has quit IRC20:57
crc32#vote Appliance21:25
*** openstackgerrit has quit IRC21:31
*** openstackgerrit has joined #openstack-lbaas21:33
rm_worksbalukoff: also, remember, it's "amphorae" :P21:35
rm_workah, you did use that later, just not for the first few paragraphs :P21:35
rm_workbut, reading your email, I am 100% glad we ended up on that name... i feel like that email would be much less clear if you did s/amphora/appliance/g21:36
rm_workalthough I agree with German, I feel like json would be fine to send to the amphorae and have it translated there, if there's going to be something listening there anyway21:37
openstackgerritA change was merged to stackforge/octavia: Initial directory skeleton
sbalukoffrm_work: What are your thoughts on my argument with regard to minor changes?21:57
rm_workI think I agree with ... german? in that it is WAAAAAY simpler to just always shoot bad amps21:59
rm_workas opposed to trying to do any kind of tracking/bookkeeping22:00
rm_workyou can do it gradually if necessary -- but with the right failover system in place, it's completely transparent and less prone to missing stuff22:00
rm_workif that makes sense22:00
rm_workI get that it's a lot more expensive22:01
sbalukoffHow do you know an amp is bad?22:01
rm_workbut I think I would rather do that than try to maintain any kind of state tracking22:01
rm_workwell, bad == out of date, i think22:01
sbalukoffhow do you know if it's out of date?22:01
rm_worki see where you're leading me :P22:01
rm_workso yes22:01
rm_workwe need to have at least a *flag*22:02
sbalukoffWhy not a version number?22:02
sbalukoffA version number is at least more specific.22:02
rm_workso when we release an update, we literally just "UPDATE amphora SET old_flag = 1;"22:02
rm_workand then we can do like22:02
sbalukoffI agree that if you have a config that won't work on a given amp version, shoot the amp and get a new one.22:02
sbalukoffThat's fine.22:02
sbalukoffrm_work: That seems really, really scary to me.22:03
rm_work"SELECT amp_id FROM amphora WHERE old_flag = 1 LIMIT 100;" or something every <X> time22:03
rm_workto updates22:03
rm_work*to do updates22:03
rm_workwell, we'd need to do that anyway for major updates22:03
sbalukoffrm_work: And that's a kind of SQL update that doesn't replicate well.22:03
sbalukoff(Well, if you're using mysql, anyway)22:03
rm_workwell, i'm just doing it with direct SQL here for clarity :P22:03
rm_worknot saying we'd every type that in code22:04
sbalukoffStill, what you're describing I think has more potential to explode in your face.22:04
sbalukoff(As in, bring everything down.)22:04
rm_workthe alternative is for minor updates, we leave them out of date until a major update?22:04
rm_workis that the thought?22:04
sbalukoffWhy would you want to recycle amps (a risky operation) if you don't have to?22:04
rm_workI need to re-read the emails again, but22:04
rm_workI am not actually sure thinking about it now why we CARE about minor updates?22:05
sbalukoffrm_work: No: The thought is that with minor updates the "old" amp isn't actually out of date.22:05
rm_workif we're not taking action based on them22:05
rm_workso, no action is taken?22:05
sbalukoffNo action is necessary22:05
rm_workso then why even care unless we're doing something considered major?22:05
rm_workat which point we're back to the method i was mentioning, out of necessity22:05
sbalukoffBecause you want to offer the new minor feature now.22:05
*** xgerman has joined #openstack-lbaas22:05
rm_worki meant, if we're not going to DO anything based on minor updates22:06
rm_workwhy are we even tracking whether the amp is out of date or not?22:06
sbalukoffNo, you start a new controller version.22:06
rm_workalso as I said, I think I need to re-read :P22:06
rm_workI skimmed a little bit of that part of the conversation22:06
sbalukoffSo...  again, assuming that replacing an amp is relatively risky, if a tenant is only using basic load balancer features that haven't changed for a long time, there's no pressing need to upgrade the amp.22:07
sbalukoffNow, as an operator, you can choose to anyway, if you want.22:07
rm_workwell, for one, I hope our system is stable enough that it ISN'T risky to replace an amp ;P22:08
sbalukoffNo matter how stable your system is, it's always going to be riskier to replace an amp than not to. :P22:08
sbalukoffEven so...22:08
rm_workshhh, trying to re-read this thread22:09
sbalukoffThe point that's getting missed here is that for minor updates there's literally no difference between amp versions.22:09
sbalukoffAnd restarting / replacing controllers is actually a lot easier than replacing amps.22:09
rm_workerr, didn't i say that?22:09
rm_workif there's literally no difference in the amps themselves22:09
sbalukoffI don't think so.22:09
rm_workthen don't even mark them as old22:09
bloganminor updates will be much more frequent than major correct?22:10
rm_workthat's what I meant when i said [17:05:02]  <rm_work> I am not actually sure thinking about it now why we CARE about minor updates?22:10
sbalukoffBut if you're rendering the configs on the amps, you can't even make a minor typo fix without touching all your amps.22:10
xgermanthat's an assumption which isn't based on my limited reality :-)22:10
sbalukoffblogan: If we're offering L7 functionality, yes.22:10
sbalukoffTrust me.22:10
rm_worknot that we "don't care about making updates that aren't major" but... so we make a minor update, why do we care, as far as the amps are concerned? :)22:10
xgermanyou need to push out the new config to each amp22:10
xgermanotherwise you are not updating22:11
xgermanso you need a way to do that22:11
sbalukoffxgerman: Wrong. You push out the new config if the user uses that feature.22:11
bloganif the config rendering is on the amp, you need to update all amps, if it is rendered on the controller, that controller will just push the new config, operator doesn't need to touch the amp22:11
sbalukoffxgerman: And you still have a way to do that because the "old" version of the amp can run the new config.22:11
sbalukoffblogan: +122:12
xgermanblogan +122:12
rm_worksbalukoff: so if we could write the amp-side part to throw the right kind of exception "FeatureNotImplemented" or something, if the config parses correctly but doesn't recognize one of the options, then we could shoot/respawn the amps that return that when we try to update them?22:12
xgermanyep, and sbalukoff and I disagree on the frequency of minor updates but I migth be wrong22:12
rm_workactually i think i will just switch to blogan +1 on this probably22:13
bloganyeah I honestly have no idea which will be more often except in our case, new features being exposed have been much more frequent than newer versions of the software load balancer22:13
bloganwhich isn't an apples to appels comparison22:14
sbalukoffrm_work: Why do that if you don't have to? If literally the only thing changing with the minor feature improvement is how the config gets rendered?22:14
sbalukoffFWIW, I think having the driver layer there is going to be necessary if we're going to be open for 3rd party vendors to add their own amps, or if we want to support multiple different kinds of open-source amps.22:15
sbalukoffIt's a good idea to have the driver.22:15
xgermanwell, you can move that functionality on the amp22:16
sbalukoffxgerman: The 3rd party vendors can't.22:16
sbalukoffOr at least, you're forcing them to go through much more work to play nice with Octavia if you do that.22:16
sbalukoffAnd for no good reason, from what I can tell.22:16
xgermanyep, agreed. But they could also write custom controllers22:16
xgermanI am not sure how much of our controller would be applicable to 3rd party22:17
sbalukoffSo, most of the intelligence of Octavia is in the controller.  So if you're going to re-write the controller, why are you even in Octavia at all?22:17
sbalukoffThat seems insane to me.22:17
xgermanmy worry is that somebody might "rewrite" the controller ny makign an insane driver22:18
sbalukoffSo we -2 their code.22:18
sbalukoffEasy peasy.22:18
dougwigMuch of the controller is quite relevant.  unless you don't interface the touch points.  then it's spaghetti22:18
xgermanthanks, dougwig. I just don't know where we put the line22:19
sbalukoffI do!22:19
sbalukoffIt's obvious. It's where everything puts the line: At the driver!22:19
rm_workwell, having now mapped it out on paper, I think I agree with sbalukoff / blogan22:19
blogansbalukoff: i'm not sure it will be necessary to have a driver layer in the controller if all it is doing is passing a logical representation to the amphoras (i hate amphorae) and then the amphora decides what to do with it22:19
xgermanblogan +!22:20
rm_workbut.... the ae in amphorae is the best part :P22:20
sbalukoffblogan: Right, so there's no driver in that model.22:20
sbalukoffWhich again, is not a good idea.22:20
bloganwell we could have a driver in the amp code, or just have totally different amps22:20
xgermanmeeting - brb22:21
bloganxgerman: hopefully the controller code is abstracted enough taht any driver creators won't need to do any additional controller logic22:22
sbalukoffblogan: If we're trying to meet a standard "Octavia protocol" REST API or something for the amphorae--  but I don't think we need or want that.22:22
bloganthey will only need to do what is necessary for their drivers to render their config and pass it to the amphoras22:22
dougwigif you're passing json to the amps, then the controller should hand the json to the driver interface, which should hand it to the amps.  health udp's should be received by the driver, and called into the controller.  it can be a 100% one-liner pass-through in the first release, but if you don't do it, separating the interface will be much harder later.  it's22:23
dougwigjust human nature.22:23
sbalukoffdougwig: +122:23
blogansbalukoff: sorry I'm jumping between controller rendering perspective and amphora rendering perspective, which comment are you referencing?22:24
sbalukoffI was responding to "[15:20:50]  <blogan> well we could have a driver in the amp code, or just have totally different amps22:24
blogandougwig: that is probably best beacsue that would enable the ability to do it both ways, as long as the amphora they use are set up22:25
bloganbut we do need to decide on a way we want to do it22:26
bloganat first at least22:26
dougwig+1, that's what i'm saying.  not much added complexity, lots of add flexibility, more modular code.22:26
sbalukoffblogan: I still think if we're going to do that, why push the rendering code to the amp? Why force yourself to do the "worst case scenario" upgrade path with every minor change to anything that gets pushed to an amp?22:26
blogani hope we do a similar abstraction on the amphora as well then22:26
sbalukoffKeep in mind my model and German's model can have the exact same upgrade path-- if you want to go with the worst case scenario in my model every time.22:27
blogansbalukoff: i'm still trying to understand and think of all the caveats of both, especially if having all these different versions will matter, I don't think they will matter all that much but still stewing on it22:28
dougwigi'm just trying to make sure that we make it possible to take *any* random VM and write a driver/image pair.  stock ubuntu, and the driver does the apt-get's?  sure.  puppet shop, and they want to use their existing puppet infrastructure to do the config?  sure.  vendor soft appliance?  sure.  it's just another driver/provider, and the complexity of the22:29
dougwigdriver will vary based on much you can and/or want to put directly inside the VM before saving the image.  it's not enough extra code for me to want to lose that.22:29
*** sbfox has quit IRC22:29
bloganif we're taking the approach of haproxy then if we need to update the config, and if done through the controller, then the controller just pushes that out to the amphoras and the amphoras doesn't care what version the controller is22:29
*** sbfox has joined #openstack-lbaas22:29
sbalukoffblogan: Correct.22:30
blogansbalukoff: so I'm still trying to understand all the versions that xgerman was talking about in his email22:30
dougwigand personally, i think 0.5 should be stock ubuntu images and the driver sets it up from there, and we stuff our head in the sand on HM of the VMs.  and then 0.6 or 1.0 comes out with a smarter pre-setup image.  working code, then iterate.22:30
sbalukoffblogan: I am as well.22:30
blogandougwig: i very much would like that too22:31
dougwigi'll wager that was for the statements at 4:29, not 4:30.22:31
sbalukoffI'm not sure I understands what he means by that. I think maybe he means we wouldn't be upgrading old apms when it's appropriate to do so... which is not the case.22:31
bloganand 4:30 statement i think would be fine for a 0.49 version (but thats splitting hairs)22:31
dougwigyeah, or 0.25.  or whatever the first functional prototype is called.22:32
blogani like how xgerman said amphora devices22:32
bloganit makes me cry a little inside22:32
sbalukoffMaybe this isn't clear: I expect that for the haproxy driver at least, amphorae will have their own version number which will increment at a different rate than the version number of the controller.22:33
dougwigblogan: lol22:33
bloganan amphora's version will be based on code and haproxy version?22:35
sbalukoffblogan: So the version number is the version of the glue code. I see no reason we can't also report back the haproxy (and openssl) version numbers when queried.22:35
sbalukoffglue code in this case includes the agent that lives on the amp, and anything else we write that we stick on the image.22:36
bloganwon't the glue code live in the image as well?22:42
sbalukoffYes. But the glue code won't necessarily need to be updated with every minor configuration template / logic change.  Unless the renderer is also on the image.22:44
bloganalso will the amphora's need to store anything other than the config?22:44
sbalukoffThey will need to store TLS certificates, and potentially custom error pages.22:44
blogani mean it won't need access to a database at all22:44
sbalukoffThey shouldn't.22:44
sbalukoffAs long as you're pushing a complete config each time (be that in JSON or haproxy.cfg form.)22:45
sbalukoffPut another way: the amps should definitely not have direct access to the database.22:46
bloganpending german's further explaination of the versioning, I in favor of the controller doing the rendering, but like dougwig said, if it is a clean interface in the controller then it would be possible to do both ways22:48
bloganthe amphora code can also have abstraction and clean interfaces as well22:48
sbalukoff"clean interface" being a synonym for a driver22:49
bloganpretty much22:49
sbalukoffblogan: Sure.22:49
sbalukoffI'm not asking for a "dirty" interface. It's just pushing a config in a format readily parseable by haproxy directly, rather than your favorite JSON interpreter (which would then have to render it into haproxy format).22:50
*** jorgem has quit IRC22:54
blogansbalukoff: i think we just need to make sure everyone understands the workflow 100%.  i'm assuming xgerman isn't right now but it is possible he is thinking about things we haven't considered yet23:07
sbalukoffI'm hoping if he has thought of something we haven't, he'll be able to articulate that in a way we can understand.23:11
*** xgerman has quit IRC23:18
rm_workgoing back to 4:30, I don't really want to see Octavia having to install haproxy on base Ubuntu images ever >_>23:18
rm_workwe should have images with haproxy pre-setup from the beginning (it is NOT difficult to do this...)23:19
dougwigrm_work: i'm just highlighting the flexibility of a driver interface, and something that could be done as an interim step if the images are late.23:23
sbalukoffrw_work: Agreed, IMO, images should be as "feature complete" as they're going to be once they're built, and any updates are just configuration data that gets pushed to them.23:25
sbalukoffHeck, we're going to have to have an API on there somehow from the start. How much harder is it to get haproxy there as well?23:26
sbalukoffNot the driver's problem to solve that, IMO.23:26
sbalukoffBut, as dougwig points out: If someone wants to write a driver to do that... I suppose they could. :P23:26
blogansee sbalukoff, its an implementation detail!23:35
rm_workheh true23:38
rm_workwell, bbl23:39
*** mwang2_ has quit IRC23:39
bloganhmm so it looks like there are going to be many ways to actually configure the vip, which means we will have a few vip options23:48
*** sbfox has quit IRC23:49
sbalukoffblogan: Curse you!23:50
blogansbalukoff: well i mean for what we want we're just going to need either a floating_ip_id or a floating_ip_network_id23:50
sbalukoffOh, I was talking about the 'implementation details' comment.23:51
blogansbalukoff: but I am sure there will be differences between all of us23:51
bloganoh lol23:51
sbalukoffblogan: Yeah, sussing out the details that are actually important for our various networking environments seems to me to be one of the more difficult aspects of deciding what we need to care about, eh.23:52
sbalukoff(Also-- sorry for being somewhat distracted, I'm working on a response to German's e-mail.)23:52
bloganyeah and for us, as long as we create the floating ip through neutron (or update an existing floating ip to be used by lbaas) then we will have a custom floating ip plugin in our neturon code that will set what we need up23:53
blogannp, i have been too23:53
blogani should be leaving to go home soon actually but wanted to get these reviews up23:53
bloganbut while you're here, ill get your opinion the matter23:53
blogansince we will most likely have vip_floating_ip, vip_floating_ip_network_id, vip_subnet_id, vip_port_id, and vip_address (one or some combination of them will be required)23:54
bloganit seems like it'd make sense to have a vip table to track those23:55
bloganinstead of just being in the load balancer23:55
bloganall of them would be nullable of course23:55
sbalukoffWhy is that? Wouldn't there be a 1:1 relationship between the vip table and the loadbalancer table?23:55
bloganyes, its just a context thing23:56
bloganby that same logic, would't health monitor's attributes live on the pool?23:56
sbalukoffThen what attributes does the loadbalancer have?23:56
sbalukoffblogan: Heh! My initial object revisions actually did that, but that was shot down early because that's not the way lbaas v1 works.23:57
sbalukoff(curse you, lbaas v1!)23:57
sbalukoffIn lbaas v1, there's not a 1:1 relationship beween pool and healthmonitor. :P23:57
bloganname description tenant prov_status op_status enabled23:57
bloganwell there is now23:57
bloganand i still prefer them to be in separate tables23:57
sbalukoffOk, that's mostly cosmetic from my perspective, but I don't really have a strong opinion against that.23:58
bloganand i suppose load balancer woudl have colocation and apolocation23:58
bloganbut yes you're right all of these make sense on the same object as well23:58
sbalukoffAnd if I'm sneaky, it actually opens the door for having more than one IP (ie. ipv4 + ipv6) associated with a loadbalancer.23:58
bloganyes indeed23:59
sbalukoffSo, it's a step in the right direction for my super-secret shadow agenda.23:59
blogani too thought about that as well23:59
sbalukoffNote to self: Do not mention super-secret shadow agenda.23:59
bloganwell you already did, quick take taht cyanide pill23:59
sbalukoffBrian to fingers filter isn't working so well today.23:59

Generated by 2.14.0 by Marius Gedminas - find it at!