| *** sballe has quit IRC | 00:06 | |
| *** mlavalle_ has quit IRC | 00:07 | |
| *** dkehnx1 has joined #openstack-lbaas | 00:08 | |
| *** sbfox has joined #openstack-lbaas | 00:22 | |
| rm_you | dougwig: heh | 00:54 |
|---|---|---|
| *** mwang2 has joined #openstack-lbaas | 01:31 | |
| *** mwang2_ has quit IRC | 01:34 | |
| *** mwang2 has quit IRC | 01:38 | |
| *** mestery has quit IRC | 01:41 | |
| *** mestery has joined #openstack-lbaas | 01:42 | |
| *** jamiem has quit IRC | 02:01 | |
| *** woodster_ has quit IRC | 02:05 | |
| *** xgerman has joined #openstack-lbaas | 03:19 | |
| *** sbfox has quit IRC | 03:55 | |
| *** sbfox has joined #openstack-lbaas | 04:05 | |
| *** xgerman has quit IRC | 05:09 | |
| *** amotoki has joined #openstack-lbaas | 05:52 | |
| *** sbalukoff has joined #openstack-lbaas | 05:55 | |
| *** jschwarz has joined #openstack-lbaas | 06:52 | |
| *** jschwarz_ has joined #openstack-lbaas | 07:22 | |
| *** jschwarz has quit IRC | 07:24 | |
| *** jschwarz__ has joined #openstack-lbaas | 07:51 | |
| *** jschwarz_ has quit IRC | 07:54 | |
| *** jschwarz__ has quit IRC | 07:58 | |
| *** enikanorov has quit IRC | 07:58 | |
| *** jschwarz has joined #openstack-lbaas | 08:10 | |
| *** jschwarz has quit IRC | 08:10 | |
| *** jschwarz has joined #openstack-lbaas | 08:11 | |
| *** dkehnx1 has quit IRC | 08:16 | |
| *** jschwarz has quit IRC | 08:23 | |
| *** dkehnx1 has joined #openstack-lbaas | 08:28 | |
| *** openstackgerrit has quit IRC | 12:01 | |
| *** openstackgerrit has joined #openstack-lbaas | 12:03 | |
| *** amotoki has quit IRC | 12:45 | |
| *** ptoohill has quit IRC | 14:36 | |
| *** woodster_ has joined #openstack-lbaas | 14:45 | |
| *** sbfox has quit IRC | 14:58 | |
| *** ptoohill has joined #openstack-lbaas | 15:20 | |
| *** mlavalle has joined #openstack-lbaas | 15:40 | |
| *** markmcclain has joined #openstack-lbaas | 15:41 | |
| *** markmcclain1 has joined #openstack-lbaas | 15:45 | |
| *** markmcclain has quit IRC | 15:46 | |
| *** ptoohill has quit IRC | 15:54 | |
| *** sbfox has joined #openstack-lbaas | 16:22 | |
| *** mwang2 has joined #openstack-lbaas | 16:42 | |
| *** openstackgerrit has quit IRC | 17:04 | |
| *** ptoohill has joined #openstack-lbaas | 17:08 | |
| *** sbfox has quit IRC | 17:10 | |
| *** markmcclain1 has quit IRC | 17:10 | |
| *** HenryG is now known as HenryThe8th | 17:12 | |
| *** carl_baldwin has joined #openstack-lbaas | 17:17 | |
| *** nealph_ has joined #openstack-lbaas | 17:18 | |
| *** crc32 has joined #openstack-lbaas | 17:18 | |
| nealph_ | dougwig: have added you as reviewer on https://review.openstack.org/#/c/113396/. | 17:21 |
| nealph_ | all your previous feedback from the bp approval cycle has been included, I believe. | 17:21 |
| *** jorgem has joined #openstack-lbaas | 17:24 | |
| *** sbfox has joined #openstack-lbaas | 17:29 | |
| dougwig | nealph_: thanks, i will look at that shortly. | 17:36 |
| *** carl_baldwin has left #openstack-lbaas | 17:36 | |
| nealph_ | cool...feel free to ping me with questions in the #openstack-ceilometer room. | 17:36 |
| *** sbfox has quit IRC | 17:39 | |
| *** sbfox has joined #openstack-lbaas | 17:43 | |
| *** mestery is now known as man_of_mystery | 17:43 | |
| *** sbfox has quit IRC | 18:11 | |
| *** openstackgerrit has joined #openstack-lbaas | 18:11 | |
| *** man_of_mystery is now known as mestery | 18:25 | |
| *** sbfox has joined #openstack-lbaas | 18:26 | |
| *** mwang2 has quit IRC | 19:00 | |
| *** openstackgerrit has quit IRC | 19:01 | |
| *** openstackgerrit has joined #openstack-lbaas | 19:02 | |
| blogan | im +2'ing dougwig's skeleton review | 19:14 |
| blogan | +A as well. Any objections? | 19:14 |
| crc32 | you mean the review about using the name "amphora"? I think rackspace is burned out objected to it. Just get it over with. | 19:16 |
| blogan | actually we have 2 who like it | 19:16 |
| blogan | or 4 who do not | 19:17 |
| blogan | and 1 abstain | 19:17 |
| crc32 | but thers totally no objection. Since the definition of an objection means people willing to complain on the ML. | 19:17 |
| rm_work | I would wait on +A | 19:17 |
| blogan | meh im pretty sure it has won | 19:18 |
| crc32 | And I keep misspelling it. I keep getting prehistoric plant looking things. | 19:18 |
| crc32 | http://en.wikipedia.org/wiki/Amorpha | 19:19 |
| a2hill | battlestar-loadtallica should have won, js | 19:22 |
| a2hill | :P | 19:22 |
| a2hill | the votes were rigged and i demand a recount! | 19:22 |
| dougwig | blogan: wait on +A. | 19:26 |
| dougwig | we need some way for votes to carry a weight based on emphatic-ness. because i'm not really that strongly in favor of anything | 19:26 |
| dougwig | jorgem: how strong is your hate? turn to the dark side with the emperor, or just m'eh? | 19:26 |
| crc32 | jorge 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 |
| dougwig | the voting was crap all around, and that's totally my fault. | 19:28 |
| crc32 | Thats 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 IRC | 19:33 | |
| a2hill | i was totally just kidding above btw, I like all the things | 19:34 |
| dougwig | crc32: +1 to standardized voting. | 19:34 |
| dougwig | i think irc meetbot even has a voting mechanism built-in. | 19:34 |
| crc32 | a2hill: 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 |
| a2hill | well yea, this is true. | 19:39 |
| a2hill | I think will continue to reference it as battlestar-loadtallica :P Just because it was the feasible but most awesome :D | 19:41 |
| a2hill | least* | 19:41 |
| crc32 | Any thhink it will be snowing in Paris in November. 4 of our guys(Rackspace Lbaas team) Are going after all. | 19:42 |
| a2hill | Jen 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-lbaas | 19:42 | |
| a2hill | Def cant dress like a Texan in other words ;) | 19:43 |
| a2hill | Means blogan will have to actually wear clothing there | 19:43 |
| jorgem | hey dougwig. No hate. Just want to make sure voting process is fair. | 19:52 |
| dougwig | it certainly wasn't, which is why i'm trying to gauge whether we need a recount. | 19:52 |
| jorgem | I honestly want to move forward with naming this thing so anything is better than nothing | 19:52 |
| rm_work | and I am *emphatically* for Amphora :) | 19:53 |
| dougwig | +1 | 19:53 |
| jorgem | If others feel strongly then I'll join in. Otherwise my point wasn't on the term just the process | 19:53 |
| blogan | my point has been on the term! | 19:53 |
| blogan | but i will go with the will of the people as well | 19:54 |
| dougwig | jorgem: agree. lesson learned was to not try to rush it. | 19:54 |
| crc32 | I think its a horrible name but don't care any more. Its better to maintain relationships then pick a proper name. | 19:54 |
| jorgem | no worries :) | 19:54 |
| dougwig | heh, we've almost reach the point where "generic-blob-of-attrition" sounds good. | 19:55 |
| crc32 | just keep it fair next time dougwig. | 19:55 |
| sbalukoff | Heh! | 19:56 |
| crc32 | :) | 19:56 |
| sbalukoff | So, the meetbot does have a voting system, but it's only got binary options (ie. Yes / No) | 19:56 |
| blogan | yeah | 19:56 |
| sbalukoff | That doesn't work as well for open-ended multiple choice things like this. | 19:57 |
| *** sbfox has joined #openstack-lbaas | 19:57 | |
| blogan | i was thinking we could do it in gerrit, except upload a file that has the list of options and then everyone puts a comment +1 | 19:57 |
| sbalukoff | dougwig: Do you want to draft a voting system for non-binary votes? | 19:57 |
| crc32 | we should right a voting bot. | 19:57 |
| crc32 | one that accepts write in ballots properly. | 19:57 |
| sbalukoff | crc32: Or submit a pull request to improve the one that's there. | 19:57 |
| blogan | i think the gerrit option is the best | 19:57 |
| crc32 | but we need a vote bot ASAP. | 19:58 |
| blogan | everyone will be notified when a new version is up | 19:58 |
| blogan | and no one has to write a vote bot | 19:58 |
| sbalukoff | blogan: You just want to make sure our meetings keeping happning in IRC. ;) | 19:58 |
| sbalukoff | I see what you're doing there! XD | 19:58 |
| crc32 | yea cause why write code. We'd never want to do that. | 19:58 |
| blogan | doing it in gerrit keeps the meeting in IRC? | 19:58 |
| sbalukoff | blogan: Oh, sorry, I thought you were advocating an IRC votebot. | 19:58 |
| sbalukoff | Anyway, I'm just ribbing you right now. :) | 19:59 |
| blogan | sbalukoff: no I'm advocating putting a file in gerrit with a list of items to vote on and then everyone adds a comment to vote | 19:59 |
| blogan | sbalukoff: i know you were, i just knew you thought I meant do it in IRC | 19:59 |
| dougwig | gerrit or some outside thing that can be left open for awhile sound best to me. | 20:00 |
| sbalukoff | blogan: Hmmm... how do you gather the options that people can vote amongst? | 20:00 |
| sbalukoff | And how many +1's do they get? | 20:00 |
| sbalukoff | And do we allow -1s? | 20:00 |
| blogan | depends on how to do the voting | 20:00 |
| dougwig | i 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 |
| blogan | well it was my sin that I didn't put anything on the ML about it when I thought it should have | 20:01 |
| blogan | have I ever mentioned I hate naming things? | 20:01 |
| sbalukoff | As 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 |
| dougwig | i 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 |
| sbalukoff | blogan: One of the two hardest problems in computer science. | 20:02 |
| sbalukoff | dougwig: Exactly! | 20:02 |
| blogan | is it possible to just accept the review for now and refactor later if it is decided to change the name? | 20:02 |
| blogan | bc I'm 90% sure amphora will win | 20:02 |
| sbalukoff | blogan: Except a refactor is unlikely to happen. And also, this affects terminology we're going to be using from here on out. | 20:02 |
| sbalukoff | So small, mostly arbitrary, but important. | 20:02 |
| blogan | true | 20:03 |
| blogan | and there will be a history and if we switch terminologies | 20:03 |
| blogan | not the best | 20:03 |
| blogan | well honestly its not slowing anyone down, its just a dependency chain we can all live with | 20:03 |
| sbalukoff | I'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 |
| dougwig | blogan: i was thinking that maybe we accept it, sit with it for 2 weeks, then see it how feels. | 20:04 |
| dougwig | anything is better than just stalling on a name. | 20:05 |
| sbalukoff | dougwig: Sure. | 20:05 |
| blogan | alright lets vote on whether we should accept it now or not | 20:05 |
| blogan | !votebot | 20:06 |
| sbalukoff | ... | 20:06 |
| openstack | blogan: Error: "votebot" is not a valid command. | 20:06 |
| dougwig | #startvote should we accept amphora for now? | 20:06 |
| blogan | damn you votebot! | 20:06 |
| dougwig | dangit | 20:06 |
| sbalukoff | Can't do it outside of a meeting? | 20:06 |
| blogan | !help | 20:06 |
| openstack | blogan: (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-vote | 20:06 |
| openstack | Meeting 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 http://wiki.debian.org/MeetBot. | 20:06 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:06 |
| openstack | The meeting name has been set to 'throwaway_vote' | 20:06 |
| dougwig | #startvote should we accept amphora for now? | 20:06 |
| openstack | Begin voting on: should we accept amphora for now? Valid vote options are Yes, No. | 20:06 |
| openstack | Vote using '#vote OPTION'. Only your last vote counts. | 20:06 |
| sbalukoff | #vote Yes | 20:07 |
| blogan | #vote Yes | 20:07 |
| blogan | i was joking about voting on it btw | 20:07 |
| dougwig | i was experimenting. | 20:07 |
| sbalukoff | dougwig: I imagine some people are going to be really confused about the purpose of the 'throwaway-vote' project. | 20:07 |
| blogan | if we had our talks in webex, you would have recognized my sarcasm | 20:07 |
| sbalukoff | HAHAHA! | 20:07 |
| dougwig | let's vote on if i'd recognize it. | 20:08 |
| sbalukoff | Aah! It's friday, right? | 20:08 |
| sbalukoff | I think the loopiness is setting in somewhat early today. | 20:08 |
| blogan | fuck it fridays | 20:08 |
| dougwig | i filled my amphora with bourbon this morning. | 20:08 |
| sbalukoff | Holy crap, that's a lot of bourbon! | 20:08 |
| a2hill | ^,^ | 20:08 |
| dougwig | #endvote | 20:08 |
| openstack | Voted on "should we accept amphora for now?" Results are | 20:08 |
| blogan | i filled my amphora with tears | 20:09 |
| sbalukoff | .. | 20:09 |
| sbalukoff | Yeah, I don't think votebot works. | 20:09 |
| dougwig | it takes awhile. | 20:09 |
| crc32 | mine broke. | 20:09 |
| blogan | !help list | 20:09 |
| openstack | blogan: (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 |
| dougwig | it's thinking. | 20:09 |
| sbalukoff | It doesn't seem to know how to compile the results. | 20:09 |
| rm_work | <_< | 20:09 |
| dougwig | #endmeeting | 20:09 |
| openstack | Meeting ended Fri Sep 5 20:09:33 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 20:09 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/throwaway_vote/2014/throwaway_vote.2014-09-05-20.06.html | 20:09 |
| blogan | !list | 20:09 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/throwaway_vote/2014/throwaway_vote.2014-09-05-20.06.txt | 20:09 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/throwaway_vote/2014/throwaway_vote.2014-09-05-20.06.log.html | 20:09 |
| openstack | blogan: Admin, Channel, ChannelLogger, Config, MeetBot, Misc, Owner, Services, and User | 20:09 |
| sbalukoff | Haha! Our shenanigans are being captured for posterity. | 20:09 |
| blogan | !Channel list | 20:09 |
| openstack | blogan: Error: 'supybot.list' is not a valid configuration variable. | 20:09 |
| blogan | !help Channel list | 20:10 |
| openstack | blogan: Error: There is no command "channel list". | 20:10 |
| rm_work | lol | 20:10 |
| dougwig | !help meetbot | 20:10 |
| openstack | dougwig: Error: There is no command "meetbot". | 20:10 |
| blogan | !Channel | 20:10 |
| openstack | blogan: (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 |
| blogan | !Services | 20:12 |
| openstack | blogan: Error: "Services" is not a valid command. | 20:12 |
| blogan | !list | 20:12 |
| openstack | blogan: Admin, Channel, ChannelLogger, Config, MeetBot, Misc, Owner, Services, and User | 20:12 |
| blogan | but services is a command! | 20:13 |
| blogan | !Admin | 20:13 |
| openstack | blogan: Error: "Admin" is not a valid command. | 20:13 |
| blogan | or i am an idiot and dont know how to use an irc bot | 20:13 |
| blogan | that is more likely | 20:13 |
| blogan | #startmeeting throwaway-vote | 20:15 |
| openstack | Meeting 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 http://wiki.debian.org/MeetBot. | 20:15 |
| sbalukoff | I once drafted voting rules for multiple-option voting in the past... I could see if I could relocate those again. | 20:15 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:15 |
| openstack | The 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, Device | 20:15 |
| openstack | Begin voting on: What name is best? Valid vote options are Amphora, Appliance, Mechanism, Device. | 20:15 |
| openstack | Vote using '#vote OPTION'. Only your last vote counts. | 20:15 |
| blogan | there youg o | 20:15 |
| blogan | you can do multiple items | 20:15 |
| sbalukoff | In 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 NotAmphora | 20:16 |
| openstack | blogan: NotAmphora is not a valid option. Valid options are Amphora, Appliance, Mechanism, Device. | 20:16 |
| blogan | #vote Appliance | 20:16 |
| sbalukoff | blogan: You still get one vote, though. | 20:16 |
| sbalukoff | So the "emphatic" person has as much say on the items as the "meh" person. :/ | 20:17 |
| sbalukoff | That is to say, you can't express your degree of enthusiasm for a given idea. ;) | 20:17 |
| sbalukoff | #vote Toaster | 20:18 |
| openstack | sbalukoff: Toaster is not a valid option. Valid options are Amphora, Appliance, Mechanism, Device. | 20:18 |
| sbalukoff | #vote Amphora | 20:18 |
| sbalukoff | #vote Toaster | 20:18 |
| openstack | sbalukoff: Toaster is not a valid option. Valid options are Amphora, Appliance, Mechanism, Device. | 20:18 |
| blogan | #vote Appliance | 20:21 |
| blogan | #endvote | 20:21 |
| openstack | Voted on "What name is best?" Results are | 20:21 |
| openstack | Amphora (1): sbalukoff | 20:21 |
| openstack | Appliance (1): blogan | 20:21 |
| blogan | there we go! | 20:21 |
| blogan | results! | 20:21 |
| blogan | #endmeeting | 20:21 |
| openstack | Meeting ended Fri Sep 5 20:21:49 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 20:21 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/throwaway_vote/2014/throwaway_vote.2014-09-05-20.15.html | 20:21 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/throwaway_vote/2014/throwaway_vote.2014-09-05-20.15.txt | 20:21 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/throwaway_vote/2014/throwaway_vote.2014-09-05-20.15.log.html | 20:21 |
| blogan | sbalukoff: i know but this will at least work well with the runoff we had, that and people who are meh would not vote | 20:22 |
| sbalukoff | blogan: It's not a bad start. | 20:23 |
| sbalukoff | But why go with a simple solution if we can make it way more complicated? >.> | 20:23 |
| blogan | lol | 20:26 |
| *** sbfox has quit IRC | 20:36 | |
| *** sbfox has joined #openstack-lbaas | 20:36 | |
| *** sbfox has quit IRC | 20:38 | |
| *** sbfox has joined #openstack-lbaas | 20:39 | |
| *** mwang2_ has joined #openstack-lbaas | 20:54 | |
| *** mwang2 has quit IRC | 20:57 | |
| rm_work | http://en.wikipedia.org/wiki/Instant-runoff_voting | 21:18 |
| crc32 | #vote Appliance | 21:25 |
| *** openstackgerrit has quit IRC | 21:31 | |
| *** openstackgerrit has joined #openstack-lbaas | 21:33 | |
| rm_work | sbalukoff: also, remember, it's "amphorae" :P | 21:35 |
| rm_work | ah, you did use that later, just not for the first few paragraphs :P | 21:35 |
| rm_work | but, 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/g | 21:36 |
| rm_work | although 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 anyway | 21:37 |
| openstackgerrit | A change was merged to stackforge/octavia: Initial directory skeleton https://review.openstack.org/117701 | 21:44 |
| sbalukoff | rm_work: What are your thoughts on my argument with regard to minor changes? | 21:57 |
| rm_work | I think I agree with ... german? in that it is WAAAAAY simpler to just always shoot bad amps | 21:59 |
| rm_work | as opposed to trying to do any kind of tracking/bookkeeping | 22:00 |
| rm_work | you can do it gradually if necessary -- but with the right failover system in place, it's completely transparent and less prone to missing stuff | 22:00 |
| rm_work | if that makes sense | 22:00 |
| rm_work | I get that it's a lot more expensive | 22:01 |
| sbalukoff | How do you know an amp is bad? | 22:01 |
| rm_work | but I think I would rather do that than try to maintain any kind of state tracking | 22:01 |
| rm_work | well, bad == out of date, i think | 22:01 |
| rm_work | right? | 22:01 |
| sbalukoff | how do you know if it's out of date? | 22:01 |
| rm_work | i see where you're leading me :P | 22:01 |
| sbalukoff | :) | 22:01 |
| rm_work | so yes | 22:01 |
| rm_work | we need to have at least a *flag* | 22:02 |
| sbalukoff | Why not a version number? | 22:02 |
| sbalukoff | A version number is at least more specific. | 22:02 |
| rm_work | so when we release an update, we literally just "UPDATE amphora SET old_flag = 1;" | 22:02 |
| rm_work | and then we can do like | 22:02 |
| sbalukoff | I 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 |
| sbalukoff | That's fine. | 22:02 |
| sbalukoff | rm_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> time | 22:03 |
| rm_work | to updates | 22:03 |
| rm_work | *to do updates | 22:03 |
| rm_work | well, we'd need to do that anyway for major updates | 22:03 |
| sbalukoff | rm_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_work | well, i'm just doing it with direct SQL here for clarity :P | 22:03 |
| rm_work | not saying we'd every type that in code | 22:04 |
| rm_work | *ever | 22:04 |
| sbalukoff | Still, 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_work | the alternative is for minor updates, we leave them out of date until a major update? | 22:04 |
| rm_work | is that the thought? | 22:04 |
| sbalukoff | Why would you want to recycle amps (a risky operation) if you don't have to? | 22:04 |
| rm_work | I need to re-read the emails again, but | 22:04 |
| rm_work | I am not actually sure thinking about it now why we CARE about minor updates? | 22:05 |
| sbalukoff | rm_work: No: The thought is that with minor updates the "old" amp isn't actually out of date. | 22:05 |
| rm_work | if we're not taking action based on them | 22:05 |
| rm_work | right | 22:05 |
| rm_work | so, no action is taken? | 22:05 |
| sbalukoff | No action is necessary | 22:05 |
| rm_work | so then why even care unless we're doing something considered major? | 22:05 |
| rm_work | at which point we're back to the method i was mentioning, out of necessity | 22:05 |
| sbalukoff | Because you want to offer the new minor feature now. | 22:05 |
| *** xgerman has joined #openstack-lbaas | 22:05 | |
| rm_work | i meant, if we're not going to DO anything based on minor updates | 22:06 |
| rm_work | why are we even tracking whether the amp is out of date or not? | 22:06 |
| sbalukoff | No, you start a new controller version. | 22:06 |
| rm_work | also as I said, I think I need to re-read :P | 22:06 |
| rm_work | I skimmed a little bit of that part of the conversation | 22:06 |
| sbalukoff | So... 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 |
| sbalukoff | Now, as an operator, you can choose to anyway, if you want. | 22:07 |
| rm_work | well, for one, I hope our system is stable enough that it ISN'T risky to replace an amp ;P | 22:08 |
| sbalukoff | No matter how stable your system is, it's always going to be riskier to replace an amp than not to. :P | 22:08 |
| sbalukoff | Even so... | 22:08 |
| rm_work | shhh, trying to re-read this thread | 22:09 |
| sbalukoff | The point that's getting missed here is that for minor updates there's literally no difference between amp versions. | 22:09 |
| sbalukoff | And restarting / replacing controllers is actually a lot easier than replacing amps. | 22:09 |
| rm_work | err, didn't i say that? | 22:09 |
| rm_work | if there's literally no difference in the amps themselves | 22:09 |
| sbalukoff | I don't think so. | 22:09 |
| rm_work | then don't even mark them as old | 22:09 |
| sbalukoff | Right. | 22:09 |
| blogan | minor updates will be much more frequent than major correct? | 22:10 |
| rm_work | that'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 |
| sbalukoff | But 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 |
| xgerman | that's an assumption which isn't based on my limited reality :-) | 22:10 |
| sbalukoff | blogan: If we're offering L7 functionality, yes. | 22:10 |
| sbalukoff | Trust me. | 22:10 |
| rm_work | not 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 |
| xgerman | you need to push out the new config to each amp | 22:10 |
| xgerman | otherwise you are not updating | 22:11 |
| xgerman | so you need a way to do that | 22:11 |
| sbalukoff | xgerman: Wrong. You push out the new config if the user uses that feature. | 22:11 |
| blogan | if 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 amp | 22:11 |
| sbalukoff | xgerman: And you still have a way to do that because the "old" version of the amp can run the new config. | 22:11 |
| sbalukoff | blogan: +1 | 22:12 |
| xgerman | blogan +1 | 22:12 |
| rm_work | sbalukoff: 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 |
| xgerman | yep, and sbalukoff and I disagree on the frequency of minor updates but I migth be wrong | 22:12 |
| rm_work | actually i think i will just switch to blogan +1 on this probably | 22:13 |
| blogan | yeah 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 balancer | 22:13 |
| blogan | which isn't an apples to appels comparison | 22:14 |
| sbalukoff | rm_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 |
| sbalukoff | FWIW, 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 |
| sbalukoff | It's a good idea to have the driver. | 22:15 |
| xgerman | well, you can move that functionality on the amp | 22:16 |
| sbalukoff | xgerman: The 3rd party vendors can't. | 22:16 |
| sbalukoff | Or at least, you're forcing them to go through much more work to play nice with Octavia if you do that. | 22:16 |
| sbalukoff | And for no good reason, from what I can tell. | 22:16 |
| xgerman | yep, agreed. But they could also write custom controllers | 22:16 |
| xgerman | I am not sure how much of our controller would be applicable to 3rd party | 22:17 |
| sbalukoff | ... | 22:17 |
| sbalukoff | So, 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 |
| sbalukoff | That seems insane to me. | 22:17 |
| xgerman | my worry is that somebody might "rewrite" the controller ny makign an insane driver | 22:18 |
| sbalukoff | So we -2 their code. | 22:18 |
| sbalukoff | Easy peasy. | 22:18 |
| dougwig | Much of the controller is quite relevant. unless you don't interface the touch points. then it's spaghetti | 22:18 |
| xgerman | thanks, dougwig. I just don't know where we put the line | 22:19 |
| sbalukoff | I do! | 22:19 |
| sbalukoff | It's obvious. It's where everything puts the line: At the driver! | 22:19 |
| rm_work | well, having now mapped it out on paper, I think I agree with sbalukoff / blogan | 22:19 |
| blogan | sbalukoff: 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 it | 22:19 |
| xgerman | blogan +! | 22:20 |
| rm_work | but.... the ae in amphorae is the best part :P | 22:20 |
| sbalukoff | blogan: Right, so there's no driver in that model. | 22:20 |
| sbalukoff | Which again, is not a good idea. | 22:20 |
| blogan | well we could have a driver in the amp code, or just have totally different amps | 22:20 |
| xgerman | meeting - brb | 22:21 |
| blogan | xgerman: hopefully the controller code is abstracted enough taht any driver creators won't need to do any additional controller logic | 22:22 |
| sbalukoff | blogan: 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 |
| blogan | they will only need to do what is necessary for their drivers to render their config and pass it to the amphoras | 22:22 |
| dougwig | if 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's | 22:23 |
| dougwig | just human nature. | 22:23 |
| sbalukoff | dougwig: +1 | 22:23 |
| blogan | sbalukoff: sorry I'm jumping between controller rendering perspective and amphora rendering perspective, which comment are you referencing? | 22:24 |
| sbalukoff | I was responding to "[15:20:50] <blogan> well we could have a driver in the amp code, or just have totally different amps | 22:24 |
| sbalukoff | " | 22:24 |
| blogan | dougwig: that is probably best beacsue that would enable the ability to do it both ways, as long as the amphora they use are set up | 22:25 |
| blogan | but we do need to decide on a way we want to do it | 22:26 |
| blogan | at first at least | 22:26 |
| dougwig | +1, that's what i'm saying. not much added complexity, lots of add flexibility, more modular code. | 22:26 |
| sbalukoff | blogan: 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 |
| blogan | i hope we do a similar abstraction on the amphora as well then | 22:26 |
| sbalukoff | Keep 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 |
| blogan | sbalukoff: 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 it | 22:28 |
| dougwig | i'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 the | 22:29 |
| dougwig | driver 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 IRC | 22:29 | |
| blogan | if 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 is | 22:29 |
| *** sbfox has joined #openstack-lbaas | 22:29 | |
| sbalukoff | blogan: Correct. | 22:30 |
| blogan | sbalukoff: so I'm still trying to understand all the versions that xgerman was talking about in his email | 22:30 |
| dougwig | and 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 |
| sbalukoff | blogan: I am as well. | 22:30 |
| blogan | dougwig: i very much would like that too | 22:31 |
| dougwig | i'll wager that was for the statements at 4:29, not 4:30. | 22:31 |
| blogan | yes | 22:31 |
| sbalukoff | I'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 |
| blogan | and 4:30 statement i think would be fine for a 0.49 version (but thats splitting hairs) | 22:31 |
| dougwig | yeah, or 0.25. or whatever the first functional prototype is called. | 22:32 |
| blogan | i like how xgerman said amphora devices | 22:32 |
| blogan | it makes me cry a little inside | 22:32 |
| sbalukoff | Maybe 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 |
| dougwig | blogan: lol | 22:33 |
| sbalukoff | Heh! | 22:33 |
| blogan | an amphora's version will be based on code and haproxy version? | 22:35 |
| sbalukoff | blogan: 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 |
| sbalukoff | glue 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 |
| blogan | won't the glue code live in the image as well? | 22:42 |
| sbalukoff | Yes. 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 |
| blogan | also will the amphora's need to store anything other than the config? | 22:44 |
| sbalukoff | They will need to store TLS certificates, and potentially custom error pages. | 22:44 |
| blogan | i mean it won't need access to a database at all | 22:44 |
| sbalukoff | They shouldn't. | 22:44 |
| sbalukoff | As long as you're pushing a complete config each time (be that in JSON or haproxy.cfg form.) | 22:45 |
| blogan | yeah | 22:45 |
| sbalukoff | Put another way: the amps should definitely not have direct access to the database. | 22:46 |
| blogan | pending 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 ways | 22:48 |
| blogan | the amphora code can also have abstraction and clean interfaces as well | 22:48 |
| sbalukoff | "clean interface" being a synonym for a driver | 22:49 |
| blogan | pretty much | 22:49 |
| sbalukoff | blogan: Sure. | 22:49 |
| sbalukoff | I'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 IRC | 22:54 | |
| blogan | sbalukoff: 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 yet | 23:07 |
| sbalukoff | I'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 IRC | 23:18 | |
| rm_work | going back to 4:30, I don't really want to see Octavia having to install haproxy on base Ubuntu images ever >_> | 23:18 |
| rm_work | we should have images with haproxy pre-setup from the beginning (it is NOT difficult to do this...) | 23:19 |
| dougwig | rm_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 |
| sbalukoff | rw_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 |
| sbalukoff | Heck, 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 |
| sbalukoff | Not the driver's problem to solve that, IMO. | 23:26 |
| sbalukoff | But, as dougwig points out: If someone wants to write a driver to do that... I suppose they could. :P | 23:26 |
| blogan | see sbalukoff, its an implementation detail! | 23:35 |
| rm_work | heh true | 23:38 |
| rm_work | well, bbl | 23:39 |
| *** mwang2_ has quit IRC | 23:39 | |
| blogan | hmm so it looks like there are going to be many ways to actually configure the vip, which means we will have a few vip options | 23:48 |
| *** sbfox has quit IRC | 23:49 | |
| sbalukoff | blogan: Curse you! | 23:50 |
| blogan | sbalukoff: well i mean for what we want we're just going to need either a floating_ip_id or a floating_ip_network_id | 23:50 |
| sbalukoff | Oh, I was talking about the 'implementation details' comment. | 23:51 |
| blogan | sbalukoff: but I am sure there will be differences between all of us | 23:51 |
| blogan | oh lol | 23:51 |
| sbalukoff | blogan: 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 |
| blogan | yeah 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 up | 23:53 |
| blogan | np, i have been too | 23:53 |
| blogan | i should be leaving to go home soon actually but wanted to get these reviews up | 23:53 |
| blogan | but while you're here, ill get your opinion the matter | 23:53 |
| blogan | since 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 |
| blogan | it seems like it'd make sense to have a vip table to track those | 23:55 |
| blogan | instead of just being in the load balancer | 23:55 |
| blogan | all of them would be nullable of course | 23:55 |
| sbalukoff | Why is that? Wouldn't there be a 1:1 relationship between the vip table and the loadbalancer table? | 23:55 |
| blogan | yes, its just a context thing | 23:56 |
| sbalukoff | Hmmm.... | 23:56 |
| blogan | by that same logic, would't health monitor's attributes live on the pool? | 23:56 |
| sbalukoff | Then what attributes does the loadbalancer have? | 23:56 |
| sbalukoff | blogan: 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 |
| sbalukoff | In lbaas v1, there's not a 1:1 relationship beween pool and healthmonitor. :P | 23:57 |
| blogan | name description tenant prov_status op_status enabled | 23:57 |
| blogan | well there is now | 23:57 |
| blogan | and i still prefer them to be in separate tables | 23:57 |
| sbalukoff | Heh! | 23:57 |
| sbalukoff | Ok, that's mostly cosmetic from my perspective, but I don't really have a strong opinion against that. | 23:58 |
| blogan | and i suppose load balancer woudl have colocation and apolocation | 23:58 |
| blogan | but yes you're right all of these make sense on the same object as well | 23:58 |
| sbalukoff | And if I'm sneaky, it actually opens the door for having more than one IP (ie. ipv4 + ipv6) associated with a loadbalancer. | 23:58 |
| blogan | yes indeed | 23:59 |
| sbalukoff | So, it's a step in the right direction for my super-secret shadow agenda. | 23:59 |
| blogan | lol | 23:59 |
| blogan | i too thought about that as well | 23:59 |
| sbalukoff | Note to self: Do not mention super-secret shadow agenda. | 23:59 |
| blogan | well you already did, quick take taht cyanide pill | 23:59 |
| sbalukoff | Dammit! | 23:59 |
| sbalukoff | Brian to fingers filter isn't working so well today. | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!