*** vivek-ebay has quit IRC | 00:15 | |
*** vivek-ebay has joined #openstack-lbaas | 00:17 | |
*** vivek-ebay has quit IRC | 00:17 | |
*** crc32 has quit IRC | 00:19 | |
*** sballe_ has quit IRC | 00:22 | |
*** sballe has joined #openstack-lbaas | 00:31 | |
*** mestery has quit IRC | 01:31 | |
*** mestery has joined #openstack-lbaas | 01:31 | |
*** sballe has quit IRC | 01:32 | |
*** mestery_ has joined #openstack-lbaas | 01:35 | |
*** mestery has quit IRC | 01:37 | |
*** vivek-ebay has joined #openstack-lbaas | 01:47 | |
*** sbalukoff has quit IRC | 02:09 | |
*** mestery_ is now known as mestery | 02:09 | |
*** sbalukoff has joined #openstack-lbaas | 02:09 | |
*** vivek-ebay has quit IRC | 02:19 | |
*** sbfox has quit IRC | 02:39 | |
*** woodster has quit IRC | 02:45 | |
*** sbfox has joined #openstack-lbaas | 03:42 | |
sbalukoff | Hey y'all! Finally got around to putting this together: https://wiki.openstack.org/wiki/Octavia/Non-arbitrary_Decisions | 03:58 |
---|---|---|
sbalukoff | I imagine we'll make another entry there when we decide on what we're going to call the vm / container / appliance / device / whatever. | 03:58 |
blogan | lol i was thinking the same thing | 03:59 |
blogan | and also API look | 03:59 |
sbalukoff | API look? | 04:02 |
blogan | one root entity versus all being root | 04:02 |
sbalukoff | Oh, yes! | 04:02 |
sbalukoff | Indeed we'll want to document that decision | 04:02 |
blogan | btw i'm starting on that as we speak, ill bring up what I believe we had consensus on in a thread on the ML once I get it set up | 04:03 |
sbalukoff | Sounds good! | 04:03 |
blogan | it'll just be an operator API that only talks to the db for now, but it'd be nice to actually have something running | 04:05 |
sbalukoff | Gotta start somewhere. | 04:06 |
sbalukoff | Maybe a no-op driver for Octavia? | 04:07 |
sbalukoff | (er.. for the Octavia VM / device / thingy) | 04:07 |
blogan | not a bad idea once the interfaces get created | 04:07 |
sbalukoff | No-op logging driver. | 04:07 |
sbalukoff | We've already done one of those, eh! | 04:07 |
blogan | doug did! | 04:07 |
sbalukoff | Yep. | 04:07 |
blogan | i think the interface blueprints are low hanging fruit blueprints | 04:08 |
blogan | so its something someone can do for first time coding | 04:09 |
blogan | and i didn't want to take that | 04:09 |
blogan | actually implementing a driver based on that will be the hard part (though the creating a good interface is not without its own obstacles) | 04:10 |
sbalukoff | Haha! Yeah, I may end up volunteering for that since I could use some python practice. | 04:11 |
sbalukoff | Unless I would be a bottleneck to others getting shit done. | 04:11 |
sbalukoff | (It's always my first priority to make sure I can keep others busy. ;) ) | 04:11 |
blogan | I don't think it will be much of a bottleneck, nothing really depending on it just yet | 04:13 |
blogan | plus you probably have a good idea on what these drivers should be doing, not exactly how they will do it | 04:14 |
sbalukoff | Cool beans. | 04:14 |
sbalukoff | Yes. | 04:14 |
*** vivek-ebay has joined #openstack-lbaas | 04:14 | |
blogan | i just keep thinking of more and more blueprints! | 04:15 |
sbalukoff | Haha! | 04:16 |
sbalukoff | Plenty for people to pick through if they're looking for something to do, eh! | 04:17 |
blogan | you could say there is a plethora | 04:17 |
blogan | https://www.youtube.com/watch?v=-mTUmczVdik | 04:18 |
sbalukoff | Oh, man, I haven't seen that movie in forever! | 04:18 |
blogan | i love that movie | 04:18 |
sbalukoff | Hehe! | 04:20 |
sbalukoff | Ok, I'mma head offline for a while, eh! Catch y'all later. | 04:21 |
blogan | later | 04:21 |
*** sbfox has quit IRC | 04:31 | |
*** sbfox has joined #openstack-lbaas | 04:38 | |
*** xgerman has joined #openstack-lbaas | 04:40 | |
*** amotoki has joined #openstack-lbaas | 04:56 | |
*** enikanorov__ has quit IRC | 05:23 | |
*** sbfox has quit IRC | 05:37 | |
*** vivek-ebay has quit IRC | 05:48 | |
*** xgerman has quit IRC | 06:26 | |
*** jschwarz has joined #openstack-lbaas | 07:49 | |
*** amotoki has quit IRC | 08:52 | |
*** markmcclain has joined #openstack-lbaas | 12:02 | |
*** markmcclain has quit IRC | 12:02 | |
*** HenryG is now known as HenryG_afk | 12:04 | |
*** markmcclain has joined #openstack-lbaas | 12:04 | |
*** enikanorov has joined #openstack-lbaas | 13:01 | |
*** woodster_ has joined #openstack-lbaas | 13:12 | |
*** enikanorov__ has joined #openstack-lbaas | 13:17 | |
*** enikanorov has quit IRC | 13:19 | |
*** vivek-ebay has joined #openstack-lbaas | 13:43 | |
*** rm_work is now known as rm_work|away | 14:03 | |
*** vivek-ebay has quit IRC | 14:18 | |
*** HenryG_afk is now known as HenryG | 14:36 | |
*** xgerman_ has joined #openstack-lbaas | 14:49 | |
*** vivek-ebay has joined #openstack-lbaas | 14:54 | |
*** sbfox has joined #openstack-lbaas | 14:57 | |
*** jorgem has joined #openstack-lbaas | 15:02 | |
*** Youcef has joined #openstack-lbaas | 15:07 | |
*** jorgem has quit IRC | 15:09 | |
*** ptoohill has joined #openstack-lbaas | 15:11 | |
*** jorgem has joined #openstack-lbaas | 15:13 | |
*** jorgem has quit IRC | 15:13 | |
*** vivek-ebay has quit IRC | 15:21 | |
*** vivek-ebay has joined #openstack-lbaas | 15:21 | |
*** ptoohill has quit IRC | 15:32 | |
*** jschwarz has quit IRC | 15:38 | |
*** vivek-eb_ has joined #openstack-lbaas | 15:42 | |
*** vivek-ebay has quit IRC | 15:44 | |
*** vivek-eb_ has quit IRC | 15:46 | |
*** mlavalle has joined #openstack-lbaas | 15:53 | |
*** mlavalle has quit IRC | 15:54 | |
*** mlavalle has joined #openstack-lbaas | 15:55 | |
*** jorgem has joined #openstack-lbaas | 15:58 | |
*** enikanorov has joined #openstack-lbaas | 16:00 | |
*** pckizer_ has joined #openstack-lbaas | 16:08 | |
*** ctracey_ has joined #openstack-lbaas | 16:08 | |
*** ctracey has quit IRC | 16:08 | |
*** dougwig has quit IRC | 16:08 | |
*** enikanorov_ has quit IRC | 16:08 | |
*** jkoelker has quit IRC | 16:08 | |
*** pckizer has quit IRC | 16:08 | |
*** ctracey_ is now known as ctracey | 16:08 | |
*** jkoelker has joined #openstack-lbaas | 16:09 | |
*** dougwig_ has joined #openstack-lbaas | 16:10 | |
*** rm_work|away is now known as rm_work | 16:22 | |
blogan | hello | 16:35 |
rm_work | hi | 16:39 |
*** vivek-ebay has joined #openstack-lbaas | 16:46 | |
*** Youcef has quit IRC | 16:50 | |
sbalukoff | 'allo! | 16:51 |
xgerman_ | blogan, morning!! | 16:56 |
dougwig_ | morning all. | 16:59 |
dougwig_ | xgerman_: the 0.5 review awaits your +A | 16:59 |
xgerman_ | coming... | 16:59 |
dougwig_ | everyone: please add your backend/vm/container/toaster naming input, as i want to drive that review to a close today: https://etherpad.openstack.org/p/octavia-backend-name | 16:59 |
sbalukoff | Wait... | 17:00 |
* dougwig_ waits | 17:00 | |
*** dougwig_ is now known as dougwig | 17:00 | |
sbalukoff | Hold off on the +A for a moment-- I noticed one other file that needs to be updated (waiting on the local tox run to complete before I push it up.) | 17:01 |
sbalukoff | dougwig_: On that naming input thing, are we allowed to -1 ideas we particularly don't like, too? | 17:02 |
sbalukoff | Or just +1 the ideas we like. | 17:02 |
sbalukoff | Oh, I see you already -1'ed one. XD | 17:03 |
xgerman_ | too late +A | 17:07 |
rm_work | heh I will put my vote in once I arrive in the office | 17:08 |
rm_work | keep getting stuck responding to things and fixing/reviewing CRs in the morning | 17:08 |
dougwig | sbalukoff: heck yes. | 17:08 |
dougwig | i +1'ed everything i liked, and -1'ed the one that i don't. | 17:08 |
openstackgerrit | Stephen Balukoff proposed a change to stackforge/octavia: Octavia v0.5 component design https://review.openstack.org/113458 | 17:08 |
sbalukoff | Interesting. I wonder what the system will do if a new patchset is uploaded after a +A, but prior to a merge. | 17:10 |
sbalukoff | I guess we're going to find out. | 17:10 |
rm_work | new patchset should kill +W | 17:12 |
rm_work | +A? | 17:12 |
rm_work | what is +A | 17:12 |
rm_work | ah | 17:13 |
rm_work | you meant the same thing | 17:13 |
rm_work | I guess I call it +W because … +W(orkflow) | 17:13 |
xgerman_ | so how do I assign blueprints? | 17:13 |
xgerman_ | blogan? Am I alcking some powers? | 17:13 |
rm_work | xgerman_: on the launchpad blueprint page it should have an edit pencil icon thing next to assignee | 17:14 |
rm_work | if you don't have that, then yes | 17:14 |
rm_work | usually only BP owners can do it? | 17:14 |
xgerman_ | no, I don't have the edit pencil | 17:14 |
rm_work | hmm | 17:15 |
rm_work | gah, i hate that they broke the CR->BP linkage | 17:15 |
xgerman_ | and neither does johnsonm_ -- so unless sballe has it you guys are cutting us :-( | 17:15 |
sbalukoff | rw_work: I think you're right. The Zuul status is showing octavia in the 'check' column, not the 'merge' column. | 17:15 |
sbalukoff | xgerman_: Can you go ahead and +A again? | 17:16 |
rm_work | sbalukoff: yes, I've had +W cancelled on me before T_T | 17:16 |
rm_work | xgerman_: don't listen to sbalukoff, wait for the check to pass before you +W >_< | 17:16 |
sbalukoff | Naaah! | 17:16 |
rm_work | also, am I missing something, why is it +A? >_> | 17:16 |
sbalukoff | It's probably going to fail the python 3.3 check, since it seems most things are failing that at the moment. :P | 17:16 |
sbalukoff | rm_work: No idea. | 17:16 |
sbalukoff | I'm happy to call it +W, just others started calling it +A first. | 17:17 |
rm_work | hmm | 17:17 |
rm_work | weird | 17:17 |
rm_work | well if +A is correct I want to be using that term | 17:17 |
sbalukoff | I'm not sure what's correct. | 17:17 |
rm_work | but I also don't want to blindly use a term I don't understand | 17:17 |
rm_work | so I'm stuck fo rnow :P | 17:17 |
sbalukoff | I'm just playing the card game 'Mao' here. | 17:17 |
rm_work | haha yes | 17:17 |
rm_work | I feel that way too sometimes <_< | 17:17 |
sbalukoff | xgerman_: Let me see what's going on there, why you can't edit stuff on the BP. | 17:19 |
dougwig | someone +2/+A that review again quick, so we nuke the other merge | 17:19 |
xgerman_ | dougwig, don't you have the power, too | 17:20 |
xgerman_ | I am trying to assign blueprints to my HP teammmates and me :-) | 17:20 |
dougwig | yep, but then our review lives in history with only one +2. bad form, though i'll do it if someone else doesn't update it soon. | 17:20 |
xgerman_ | ok, I will +2 | 17:20 |
xgerman_ | done | 17:21 |
xgerman_ | dougwig +A | 17:21 |
xgerman_ | or, you can +A -- the alst time got me into trouble and I am not falling for that again ;-) | 17:21 |
rm_work | dougwig: do YOU know why it's +A? | 17:21 |
dougwig | +Approved | 17:22 |
dougwig | the rest are just votes. | 17:22 |
dougwig | alright, zuul looks better now. cross your fingers that the file add doesn't break jenkins. | 17:23 |
sbalukoff | German: I added you to the octavia-core team on launchpad. Do you have access to do stuff there now? | 17:24 |
xgerman_ | Yes. Things look much better!! | 17:25 |
rm_work | dougwig: ah, ok. in Barbican everyone talks about "Workflow" -- "Can you workflow my change?" | 17:25 |
dougwig | from the gerrit UI: | 17:26 |
dougwig | Workflow: | 17:26 |
dougwig | +1 Approved | 17:26 |
dougwig | 0 Ready for reviews | 17:26 |
dougwig | -1 Work in progress | 17:26 |
dougwig | you can actually trigger +A with 0 +2's. it's the flag that matters. | 17:26 |
rm_work | well, you can if it's set up that way for your repo | 17:30 |
rm_work | you CAN set it up to *require* a number of +2s, right? | 17:31 |
rm_work | dougwig: see, reading that UI, I would still assume the action is "workflow" so you'd +Workflow or -Workflow | 17:31 |
sbalukoff | rm_work: Probably, but I generally prefer rules like that to be override-able and enforced by practice, not necessarily automated policy. | 17:32 |
rm_work | otherwise by that logic it'd be +A and -W | 17:32 |
xgerman_ | ok, Al Miller is part of HP. He started today with the LBaaS team in case you are wondering ;-) | 17:32 |
sbalukoff | Awesome! | 17:32 |
dougwig | is he in channel? | 17:34 |
rm_work | bbl | 17:34 |
dougwig | naming vote: https://etherpad.openstack.org/p/octavia-backend-name | 17:50 |
dougwig | i'm not going to let the review sit forever, so if you care at all, please speak up. | 17:50 |
*** jorgem has quit IRC | 17:57 | |
*** jorgem has joined #openstack-lbaas | 18:01 | |
openstackgerrit | A change was merged to stackforge/octavia: Octavia v0.5 component design https://review.openstack.org/113458 | 18:20 |
*** ajmiller has joined #openstack-lbaas | 18:34 | |
blogan | NO TO VM!!!!! | 18:41 |
blogan | i must come up with a campaign slogan | 18:41 |
blogan | xgerman_: are you able to assign now? | 18:41 |
blogan | xgerman_: nvm i see your response | 18:41 |
*** jorgem has quit IRC | 18:42 | |
dougwig | ha, i love how node had a mini-consensus a few days ago, and is now all -1. :) | 18:42 |
xgerman_ | yeah, sbalukoff hooked me up | 18:42 |
xgerman_ | and I asked our naming speicalist Julian to throw in some names ;-) | 18:42 |
dougwig | right now it's either backend or container, folks. vote early, vote often! err, wait. | 18:43 |
*** jorgem has joined #openstack-lbaas | 18:44 | |
blogan | there's really not going to be a name that just sticks out as being right | 18:51 |
blogan | i think this list should be wittled down to the most popular, and then people are only allowed to vote for one | 18:51 |
dougwig | https://www.irccloud.com/pastebin/sST8G9dT | 18:55 |
dougwig | pod is actually growing on me. | 18:56 |
blogan | me too, though the first thought was no way | 18:57 |
dougwig | yeah, i threw it in as a lark. | 18:58 |
dougwig | but it's not overloaded, it is a thing which contains something(s), and we can define our own vocabulary. | 18:58 |
blogan | im trying to get carlos and jorge to vote, don't worry i'm not telling them to vote for what i want | 18:58 |
dougwig | going to grab some food before the meeting | 19:04 |
*** ptoohill has joined #openstack-lbaas | 19:13 | |
*** crc32 has joined #openstack-lbaas | 19:20 | |
blogan | crc32, ptoohill: https://etherpad.openstack.org/p/octavia-backend-name | 19:21 |
*** crc32 has quit IRC | 19:21 | |
*** ajmiller_ has joined #openstack-lbaas | 19:29 | |
*** crc32 has joined #openstack-lbaas | 19:30 | |
*** ajmiller has quit IRC | 19:32 | |
sbalukoff | I just threw a few more suggestions up there. Please go -1 them. | 19:43 |
*** sballe has joined #openstack-lbaas | 19:47 | |
blogan | lol | 19:49 |
blogan | hmm | 19:49 |
*** vivek-ebay has quit IRC | 19:52 | |
dougwig | https://www.irccloud.com/pastebin/53hWEacA | 19:54 |
dougwig | there is currently only one with a positive number. | 19:54 |
sbalukoff | Isn't a pod a grouping of desks? | 19:55 |
sbalukoff | (Among other things, obviously) | 19:56 |
dougwig | it's also that thing they drop in your driveway, or a bean. | 19:56 |
dougwig | and the pod people. | 19:56 |
sbalukoff | 6 more suggestions for people to -1 | 19:57 |
sbalukoff | Also, your math is off: pod only has a +2 | 19:58 |
sbalukoff | So what's a grouping of pods? A plant? | 19:59 |
blogan | whats a grouping of groups? | 19:59 |
sbalukoff | (Thinking of what we call the thing holding the loadbalancer in the active-active topology which is a grouping of nova vms) | 19:59 |
sbalukoff | Or a vine? | 19:59 |
sbalukoff | Ok, meeting time, eh! | 20:00 |
sbalukoff | #startmeeting Octavia | 20:00 |
openstack | Meeting started Wed Sep 3 20:00:09 2014 UTC and is due to finish in 60 minutes. The chair is sbalukoff. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:00 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:00 |
openstack | The meeting name has been set to 'octavia' | 20:00 |
dougwig | sbalukoff: a stalk? | 20:00 |
sballe | o/ | 20:00 |
sbalukoff | Ok, folks! | 20:00 |
blogan | hi | 20:00 |
blogan | \o/ | 20:00 |
sbalukoff | Here's the agenda for today: | 20:00 |
sbalukoff | #link https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Meeting_2014-09-03 | 20:00 |
sbalukoff | Let's get going | 20:01 |
sbalukoff | #topic Briefly discuss Octavia/Non-arbitrary Decisions wiki page | 20:01 |
sbalukoff | I just wanted to briefly bring people's attention to this. | 20:01 |
sbalukoff | #link https://wiki.openstack.org/wiki/Octavia/Non-arbitrary_Decisions | 20:01 |
sbalukoff | We'll be using that for documenting decisions that took longer than a couple minutes to resolve (like the damn name thing). | 20:01 |
sbalukoff | Please let me know if you've got any questions about that. | 20:02 |
sbalukoff | If y'all have concerns about that, we can discuss at the next meeting. | 20:02 |
blogan | lgtm | 20:02 |
sbalukoff | (I am not expecting y'all to have concerns, as we discussed this in the last couple meetings.) | 20:02 |
sballe | sounds good to me. i am in a meeting and it is runnign late | 20:02 |
sbalukoff | Ok! | 20:03 |
sbalukoff | #topic Briefly discuss v0.5 component design under review, Brandon's initial database migrations, push for consensus on that. | 20:03 |
jorgem | hello! | 20:03 |
TrevorV | o/ | 20:03 |
sbalukoff | So, basically, this is about just making sure we're processing reviews in a timely manner. | 20:03 |
rm_work | o/ | 20:03 |
sbalukoff | Looks like the v0.5 component design was merged earlier today. | 20:03 |
dougwig | sbalukoff: the mentioned review is blocked on mine, which i will be trying to merge today. | 20:03 |
blogan | migrations need one more PS bc of the name thing, and need to add attributes to the health monitor | 20:04 |
sbalukoff | Other than the naming thing that we're discussing, which is clearly a blocker for a couple of these, any major concerns to discuss at this time? | 20:04 |
TrevorV | I have a topic if we have time. Not pressing, just wondering what people's thoughts are | 20:04 |
sbalukoff | TrevorV: Er... does it have to do with the current topic? | 20:05 |
sbalukoff | (current topic is essentially discussing outstanding concerns with outstanding gerrit review stuff.) | 20:05 |
sbalukoff | #link https://review.openstack.org/#/q/stackforge/octavia+status:open,n,z | 20:05 |
TrevorV | No it does not sballe | 20:05 |
rm_work | guessing not because he said he as a Topic :P | 20:05 |
TrevorV | sbalukoff, ** mah bad | 20:06 |
sbalukoff | Oh, haha! | 20:06 |
sbalukoff | Ok, we'll try to get through the remaining topics quickly if we can so we can discuss your topic, eh. | 20:06 |
sbalukoff | Ok! | 20:06 |
sbalukoff | So, moving on! | 20:06 |
sbalukoff | #topic Get consensus on name of "thingy" doing the load balancing (VM / appliance / device / strategy / toaster / whatever) | 20:06 |
dougwig | #link https://etherpad.openstack.org/p/octavia-backend-name | 20:06 |
dougwig | go vote. | 20:06 |
sbalukoff | Yes, please go vote | 20:07 |
sbalukoff | We need a decision on this today, because it's holding up other work. | 20:07 |
dougwig | in about 1 hour and 23 minutes, i'm going to update the patchset with the winner, and then push for reviews. we've had literally no other comments since the weekend except on naming. | 20:07 |
dougwig | the review in question: | 20:08 |
dougwig | #link https://review.openstack.org/#/c/117701/ | 20:08 |
blogan | dougwig: i think it'd be smart to get the top 3 adn then everyone vote on that, but only one vote | 20:08 |
sbalukoff | dougwig: That seems fair. | 20:08 |
sbalukoff | blogan: There's only one with a positive score right now, I think. | 20:08 |
rm_work | blogan +1, though that delays things again | 20:08 |
TrevorV | +1 blogan | 20:08 |
rm_work | but I think it is the fairest | 20:08 |
dougwig | blogan: eh, runoff's are good when you only have on vote amongst many. there is no limit here. | 20:08 |
dougwig | /on/one/ | 20:08 |
blogan | i think if there are 3 things and someone doesn't like any, but they had to choose one, the vote will be much clearer | 20:09 |
*** vivek-ebay has joined #openstack-lbaas | 20:09 | |
sbalukoff | One thing to consider with this name: | 20:09 |
rm_work | blogan +1 again | 20:09 |
dougwig | ok, at 3:30 we'll have a runoff. voting will end at 5pm (this is all mountain time.) | 20:09 |
sbalukoff | This describes a nova instance dedicated to running the octavia code + haproxy which actually does the load balancing in this solution. | 20:10 |
sbalukoff | In an active-active topology, there will be groupings of these which perform the load balancing. | 20:10 |
rm_work | please set your name if you are voting so we can see who everyone is :P | 20:10 |
dougwig | and at present, we literally have no names with >0 points. | 20:10 |
sbalukoff | So, it would be good if the name we choose has a logical grouping of some kind. | 20:10 |
sbalukoff | (eg. sheep / flock ) or something. | 20:10 |
sbalukoff | Not that I'm suggesting sheep at this point. | 20:11 |
blogan | may as well call it cats | 20:11 |
rm_work | cats / herd? | 20:11 |
dougwig | i'm definitely upload sheep. you don't want to know what i'm naming the driver/interface. | 20:11 |
blogan | indeed | 20:11 |
sbalukoff | Haha! | 20:11 |
rm_work | although RMS might get on us because of GNU/Herd | 20:11 |
*** tmc3inphilly has joined #openstack-lbaas | 20:11 | |
rm_work | or is that Hurd | 20:11 |
sbalukoff | That would be a good reflection of trying to get this group to agree on something. ;) | 20:11 |
rm_work | heh yes | 20:11 |
blogan | this will be the hardest problem we come across | 20:12 |
ptoohill | Battlestar-loadtallica is a logical grouping and should totally win | 20:12 |
sbalukoff | Absolutely. | 20:12 |
dougwig | ok, go vote, i think we can move on? | 20:12 |
sballe | My meeting is running even later. I'll have to read the minutes later | 20:12 |
rm_work | velociraptor / pack <-- just sayin' | 20:12 |
rm_work | kk | 20:12 |
rm_work | ah though WD uses velociraptor for a line of drives :/ | 20:13 |
sbalukoff | serial killer / bloodbath | 20:13 |
dougwig | one last note: there are a TON of -1's in there. try to find some +1's, or suggest something new. i don't want a vote among the least hated here. | 20:14 |
rm_work | truth | 20:14 |
TrevorV | I wish we had enough logical space to explain why people are placing -1 or +1. It always helps me make a decision when I know what people's thoughts are | 20:14 |
TrevorV | (logical space?) | 20:15 |
rm_work | doug has been adding briefly why he's -1'ing i think | 20:15 |
rm_work | or | 20:15 |
rm_work | I guess he and Jorge did | 20:15 |
TrevorV | honestly, "overloaded term" is a bad argument for a -1 since its already overloaded it seems to make sense to use it... IMO | 20:15 |
sbalukoff | TrevorV -1 | 20:16 |
sbalukoff | :) | 20:16 |
TrevorV | At most I'd say -0.5 | 20:16 |
dougwig | heh, note that i put that on "instance". :) | 20:16 |
sbalukoff | No, I disagree: Having an overloaded term used for something with a specific purpose just irritates me. | 20:16 |
sbalukoff | I know! Let's go with "server" | 20:17 |
sbalukoff | Yeah. No. | 20:17 |
dougwig | no, no. "object" | 20:17 |
blogan | but this is supposed to bea generic term | 20:17 |
sbalukoff | dougwig: That's making me physically ill. | 20:17 |
crc32 | yea I withdraw instance. Cause we'll need a term in front of it now. | 20:17 |
sbalukoff | blogan: "generic enough" | 20:17 |
TrevorV | blogan, +1, hence me saying overloaded-term doesn't make sense. | 20:17 |
sbalukoff | The octavia load balancing thingy actually has a specific purpose. | 20:17 |
blogan | well a container has a specific purpose, and its to hold things, but it has a genric name | 20:18 |
blogan | or does | 20:18 |
blogan | it | 20:18 |
blogan | oye | 20:18 |
*** KunalGandhiEbay has joined #openstack-lbaas | 20:18 | |
sbalukoff | It runs the software which actually delivers the load balancing service to the end user. | 20:18 |
sbalukoff | Right. | 20:18 |
TrevorV | So its a host, sbalukoff ? | 20:19 |
sbalukoff | TrevorV: You're lucky you're not within throwing distance. | 20:19 |
TrevorV | I'm actually serious here, since that seems appropriate to me with that description :D | 20:19 |
rm_work | peon / grunt? :P | 20:19 |
sbalukoff | rm_work: +1 | 20:19 |
crc32 | Sounds like a "<InsertTermHere>Manager" | 20:19 |
sbalukoff | These things shouldn't be that intelligent. | 20:19 |
vivek-ebay | I am confused. What are we suggesting name for? octavia-backend ? | 20:20 |
rm_work | totally adding both of those | 20:20 |
ptoohill | Oh dear, executive decision time on naming issues? Let's just default to toaster or something? Isn't there other pressing issues? | 20:20 |
TrevorV | Right, so what keeps us from using an overloaded-term? :) | 20:20 |
sbalukoff | vivek-ebay: Yes. | 20:20 |
sbalukoff | The Octavia VM in previous diagrams and component designs. | 20:20 |
dougwig | TrevorV: imagine if you're new to the project, clone it, and have nothing as a roadmap except the directory listing. there are a few generic terms that have enough meaning to help. host isn't one of them. | 20:20 |
rm_work | ptoohill: well unfortunately this is blocking a major CR | 20:20 |
xgerman_ | sorry for being late | 20:20 |
TrevorV | dougwig, that's fair. | 20:20 |
sbalukoff | ptoohill: Yes there are. | 20:20 |
sbalukoff | So! | 20:20 |
rm_work | I'm thinking about something that is a good metaphor | 20:21 |
rm_work | peon / grunt are that | 20:21 |
rm_work | they're the actual "workers" | 20:21 |
rm_work | oh | 20:21 |
sbalukoff | Add any suggestions you want before the end of this meeting... directly after the meeting, everyone please register your +1 / -1 / abstain on this. | 20:21 |
rm_work | is "workers" super overloaded? >_> | 20:21 |
dougwig | worker/colony/ant | 20:21 |
rm_work | i like worker/colony | 20:21 |
blogan | so as dougwig said, this vote will be until 330pm Mountain Time, and then the top 3 will have another vote which will close at 5pm Mountain Time | 20:21 |
dougwig | hive | 20:21 |
sbalukoff | Anyone have anything else to add to this discussion right now? | 20:21 |
sbalukoff | dougwig: bee | 20:22 |
dougwig | i think we're past time to move on. take your ideas to the etherpad, please | 20:22 |
vivek-ebay | beehive | 20:22 |
sbalukoff | Yep. | 20:22 |
ptoohill | Goooses | 20:22 |
sbalukoff | Ok! | 20:22 |
ptoohill | Oh were past that srry | 20:22 |
sbalukoff | #topic Discuss where haproxy config should be rendered (controller, driver, or Octavia VM / appliance)(Driver, of course.) | 20:22 |
sbalukoff | My thought echoes Dougwig's here: In the driver. | 20:22 |
jorgem | i added approach | 20:23 |
sbalukoff | (And then configs get pushed out to the octavia load balancer thingy) | 20:23 |
dougwig | (sorry for editorializing the agenda, i couldn't resist.) | 20:23 |
sbalukoff | Anyone have different ideas here? | 20:23 |
blogan | isn't the driver basiaclly in the controller? | 20:23 |
sbalukoff | blogan: Yes, ish. | 20:23 |
sbalukoff | ;) | 20:23 |
dougwig | blogan: yes, imported by controller. | 20:23 |
sbalukoff | It gets loaded by the controller. | 20:23 |
blogan | the controller will just instantiate whatever driver it needs to use | 20:23 |
xgerman_ | no, we like it to be in the VM | 20:23 |
sbalukoff | xgerman_: Please explain your reasoning. | 20:24 |
jorgem | +1 blogan | 20:24 |
xgerman_ | I though we discussed that last time | 20:24 |
dougwig | i actually don't care beyond it not being in the controller core. it's really a driver issue, but as long as the interface isn't hard-coded to haproxy, it matters not whether that occurs in the driver or VM. | 20:24 |
jorgem | It makes it easier to test as well | 20:24 |
jorgem | because we can mock stuff out | 20:24 |
rm_work | sbalukoff: +1, in the driver IMO | 20:24 |
blogan | xgerman_: any strong reasons why it should be on the VM side? | 20:25 |
xgerman_ | then I can switch haproxy, etc. without changing the controller | 20:25 |
dougwig | xgerman_: especially considering that if you roll a custom VM, you could make your driver a pass-through. | 20:25 |
johnsom_ | dougwig +1 | 20:25 |
sbalukoff | xgerman_: So a couple reasons I don't want this in the VM: 1. It puts more intelligence into the VM than is necessary (again, centralize intelligence, distribute workload) | 20:25 |
sbalukoff | 2. It makes the back-end API (ie. what the driver/controller speaks to the VM) more complicated | 20:25 |
TrevorV | +1 driver | 20:26 |
sbalukoff | Also: 3. It makes it more difficult to add new minor features... because you'll have to go out and update 10,000+ VMs instead of updating a few controllers. | 20:26 |
xgerman_ | well, you have to do that anyway in case of security updates | 20:26 |
sbalukoff | xgerman_: So, if you want to replace haproxy with nginx, that seems to call for a new driver in any case. | 20:27 |
sbalukoff | xgerman_: Yep, so let's not exacerbate the problem by having to do it for minor feature additions, too. Also, not all security updates will necessarily require that. If it's a problem that can be fixed with an update to a config (eg. "disable this kind of SSL") then that doesn't require updating all VMs. | 20:28 |
*** sballe has quit IRC | 20:28 | |
dougwig | i think this becomes a difference of, do we have an nginx and an haproxy driver, or do we have a nova VM driver, which different VM's? one of these schemes will fit inside the other. | 20:28 |
dougwig | /which/with/ | 20:28 |
sbalukoff | xgerman_: If you want to have an Octavia VM be able to run either haproxy or nginx, that's doable too-- and accomplishing this is still easier by writing a driver which can do both, and making a minor change to the back-end API. | 20:28 |
xgerman_ | well, my vision was that the controller talk to the VMs in some octavia protocol and the the vm renders it as needed | 20:28 |
sbalukoff | (Speaking from experience, as our BLBv1 product can do either haproxy or nginx) | 20:29 |
dougwig | (an aside, i will note that from minute zero in this conversation, we have used the term VM to describe what we're voting on naming.) | 20:29 |
xgerman_ | so now we need to bookkeerp which vm is compatible with which driver, versions need to fit, etc. | 20:29 |
sbalukoff | xgerman_: I think that's good in theory, but in practice will be more of a pain once you have a large deployment. | 20:29 |
rm_work | xgerman_: yeah that makes sense and I was thinking that too -- although then we have to define another whole interface level, which i think we can avoid by just doing it in the driver layer | 20:29 |
sbalukoff | xgerman_: All of that is solved if you have an API command to gather that info. Think of it like API versioning. | 20:30 |
rm_work | though yeah, i am concerned about the bookkeeping | 20:30 |
sbalukoff | Octavia VMs will also have a version, eh. | 20:30 |
xgerman_ | yep, so we might have to replace VMs + the driver | 20:30 |
xgerman_ | to solve the special case of "minor changes" | 20:31 |
sbalukoff | xgerman_: For major changes, yes. | 20:31 |
sbalukoff | But that's no different from the model you've proposed. | 20:31 |
sbalukoff | No, actually, you don't have to replace the VMs for minor changes. | 20:31 |
xgerman_ | yeah, but for major changes I do | 20:31 |
sbalukoff | xgerman_: Again, which is no different than the solution you've proposed. | 20:32 |
sbalukoff | The difference here is that you have to replace the VMs for minor changes as well. | 20:32 |
sbalukoff | I don't. | 20:32 |
xgerman_ | yep, so I don't create a special case | 20:32 |
sbalukoff | ... | 20:32 |
rm_work | (dougwig yeah we kind of anchored the discussion in a way by saying "vote on what to call VMs" :P) | 20:32 |
sbalukoff | xgerman_: The solution that allows for the least amount of overall pain is the best one, IMO. | 20:33 |
TrevorV | sbalukoff, +1 | 20:33 |
sbalukoff | Rather than making everything equally painful | 20:33 |
sbalukoff | Anyway, do we want to vote on this here, or do y'all think that mailing list discussion is warranted? | 20:34 |
dougwig | i think that if xgerman_ isn't convinced, this needs to be punted to ML or voice. | 20:34 |
xgerman_ | well, so far the advantage of your proposal id for minor upgrades; downside is more bookeeping | 20:34 |
dougwig | jinx | 20:34 |
sbalukoff | xgerman_: There's more than just that. | 20:35 |
blogan | if the config rendering gets done on the VM side, will the controller even need an haproxy/nginx driver? would that just be pushed to the VM? | 20:35 |
TrevorV | +1 to mailing list | 20:35 |
sbalukoff | The backend API is also far less complicated. | 20:35 |
TrevorV | blogan, I think the argument is having that all pushed to VM | 20:35 |
xgerman_ | ok, mailing list | 20:35 |
sbalukoff | And again, your solution goes against the whole "centralize intelligence / decentralize workload" design philosophy. | 20:35 |
dougwig | blogan: yes, because not all appliance backends will have the luxury of implementing it all inside the VM. | 20:35 |
blogan | dougwig: ++ for your use of appliance | 20:35 |
TrevorV | dougwig, (I see what you did there) | 20:36 |
sbalukoff | haha | 20:36 |
tmc3inphilly | Unit of Compute (UoC) | 20:36 |
sbalukoff | Ok, we'll punt to mailing list. | 20:36 |
xgerman_ | ok | 20:36 |
sbalukoff | xgerman_: Do you want to start that thread, or shall I? | 20:36 |
xgerman_ | you can start it | 20:37 |
sbalukoff | Ok, will do. | 20:37 |
sbalukoff | Ok, next topic | 20:37 |
sbalukoff | #topic Discuss DB model around loadbalancer VIPs in relation to different front-end topologies and how be to represent these abstractly | 20:37 |
sbalukoff | So, in looking at how to make the network stuff work, I think blogan and I realized that we've not yet come up with a good way to represent the types of connections the VMs / appliances will need to the rest of the network. | 20:38 |
rm_work | that's... quite a wordy topic :P | 20:39 |
sbalukoff | We could default to Neutron terms here, which I think is actually not good because it assumes a lot about layer-2 topology. | 20:39 |
dougwig | sbalukoff: can you give an example or two? | 20:39 |
TrevorV | +1 dougwig | 20:39 |
xgerman_ | +1 | 20:40 |
sbalukoff | dougwig: So, right now if we're working with just Neutron as a networking layer, if we want to represent the front-end connectivity to a VIP address (ie. part of the loadbalancer object), we need to record both the vip_address and vip_port_id | 20:40 |
sbalukoff | Or something like that.. | 20:40 |
sbalukoff | What the user is actually probably interested in is vip_address and subnet_id | 20:40 |
blogan | if octavia is responsible for creating the vip_port, then we need a subnet_id | 20:40 |
sbalukoff | But that's assuming layer-2 connectivity on the front-end. | 20:40 |
blogan | and if floating ips are being used, thats different | 20:41 |
sbalukoff | Things get more complicated with layer-3 (routed) connectivity | 20:41 |
dougwig | and overlapping subnets. | 20:41 |
sbalukoff | Because a layer-3 address isn't going to be associated with a port, it's going to be associated with a route. | 20:41 |
sbalukoff | dougwig: Well, ignoring the overlapping subnets problem for a bit, we still have trouble reliably representing things even if there isn't overlap. | 20:42 |
dougwig | we'll have to have some generic id fields, which the network_driver is going to have to map to neutron specifics. the question is how many id fields, and what to name them? | 20:42 |
dougwig | or a text blob where we can put whatever json the network_driver needs? | 20:42 |
blogan | dougwig: i believe that is the extent of the problem, making sure we have the necessary fields and good names (naming things!@#@##) | 20:42 |
sbalukoff | dougwig: I'd love it if we had a way to refer to these things in "Octavia language" or something, which the driver then translates to do whatever is necessary for that type of connectivity on the network side. | 20:42 |
TrevorV | dougwig, don't forget what is required versus optional | 20:42 |
sbalukoff | So, that we're using more industry standard terms and concepts, and aren't doing what I think to be "hackish" ways of handling this with Neutron specifically (eg. associating an address with a port and the not putting that port on any subnet, because that's how you handle a layer-3 route? really?) | 20:43 |
blogan | xgerman_: from HP's perspective, what information would you need to store for front end connectivity? | 20:43 |
sbalukoff | I don't want to bake that kind of hack-ish-ness into Octavia's design, if we can avoid it. | 20:44 |
blogan | sbalukoff: you can have a port without a subnet in neutron? | 20:44 |
xgerman_ | we are still discussing on our end how things will shape up | 20:44 |
dougwig | maybe we inch our way there? 0.25 is vip and members on same subnet, 0.5 is vips all on one subnet, members on others, etc... there's no reason these db models have to be perfect in the first rev; we're going to learn a lot in the first prototype. | 20:44 |
sbalukoff | blogan: I think so, but I could possibly be wrong. You might have to create the subnet, and then not attach it to a router. I forget-- it's been a few months since I looked into how to do this. | 20:45 |
blogan | dougwig: +1, I think that may end up being what we need to do because there is a lot of unknowns right now | 20:45 |
sbalukoff | dougwig: I guess I'm asking: Is anyone out there an expert who has an opinion on the right way to do this that can talk to us? | 20:45 |
blogan | sbalukoff: i'm not totally 100% sure, but I didn't think it was possible to have a port not on a subnet | 20:45 |
sbalukoff | Unfortunately, my neutron networking expert is on vacation this week. :P | 20:46 |
sbalukoff | blogan: Then I'm probably wrong, but I don't think I'm wrong about making floating IPs work a non-hackish kind of thing. ;) | 20:46 |
dougwig | sbalukoff: i think i'd still advocate getting some code on the books with a simpler topology first. | 20:46 |
blogan | could just store these things as generic for now, network_resource_id | 20:47 |
sbalukoff | dougwig: I'd really rather have this model figured out before we paint ourselves into a corner with an inadequate design baked into other components. :P | 20:47 |
*** sballe has joined #openstack-lbaas | 20:47 | |
TrevorV | dougwig, if I understood you correctly, you mean to just leave naming/fields tied to Neutron for now, and modify as needed later? | 20:47 |
sbalukoff | In any case, we don't need a final decision on that now, or even this or next week, IMO. | 20:48 |
dougwig | no, i mean as we find fields we need to add to support neutron, we think of generic names/concepts and add them to the migrations at that time, instead of waiting to have perfect models. | 20:48 |
blogan | sbalukoff: I don't think a major refactor before 0.5 will be a huge deal (famous last words I know) | 20:48 |
sbalukoff | dougwig: You're right that we can get some work done without having this figured out. | 20:48 |
TrevorV | dougwig, ah, gotcha, thanks | 20:48 |
sbalukoff | Mosty, I wanted to make the rest of y'all aware of the problem, so if you can pull in resources, or if you have a good idea on how to solve this in the long run that you'd like to share, I'd love to hear it. | 20:48 |
sbalukoff | (Over the next coming weeks, eh.) | 20:49 |
sbalukoff | Anyway, we've only got 10 minutes left, so I wanted to move on to the next topic. | 20:49 |
blogan | sbalukoff: in the meantime is using generic names acceptable? | 20:49 |
sbalukoff | blogan: I don't think we've got another choice. :) | 20:50 |
xgerman_ | blogan +1 | 20:50 |
blogan | done | 20:50 |
sbalukoff | blogan: Nobody is suggesting anything else at this time, eh. | 20:50 |
sbalukoff | Ok! | 20:50 |
dougwig | i'd put their neutron counterpart names in the models (as comments), where we differ. | 20:50 |
blogan | dougwig: good idea | 20:50 |
sbalukoff | dougwig: +1 | 20:50 |
sbalukoff | #topic Discuss blueprints here, look for volunteers: https://blueprints.launchpad.net/octavia/ | 20:50 |
sbalukoff | Ok, folks! | 20:50 |
sbalukoff | We have blueprints! Please start claiming them! | 20:50 |
sbalukoff | (And fleshing them out, doing work on them, etc.) | 20:51 |
xgerman_ | +1 | 20:51 |
blogan | everyoen agree on the process? | 20:51 |
sbalukoff | Also, please make sure to start updating the stand-up etherpad I created (modeled on the one Jorge did for Neutron LBaaS) | 20:51 |
blogan | giving more details in the blueprint work items/whiteboard? | 20:51 |
sbalukoff | #link https://etherpad.openstack.org/p/octavia-weekly-standup | 20:51 |
blogan | some things like interface designs are probably just easiest showing the code honestly | 20:52 |
xgerman_ | ok, good to know' | 20:52 |
johnsom_ | Can we capture the networking concerns on the ML so we can pass it around to people for comment? | 20:53 |
*** markmcclain1 has joined #openstack-lbaas | 20:53 | |
blogan | johnsom_: i think that is a good idea | 20:53 |
sbalukoff | johnsom_: Sure. | 20:53 |
sbalukoff | #action sbalukoff to start ML thread on front-end topology representation concerns | 20:54 |
*** markmcclain has quit IRC | 20:54 | |
sbalukoff | Ok, Trevor! What's your topic? | 20:54 |
dougwig | sbalukoff: switch the topic to open discussion... | 20:54 |
sbalukoff | #topic Open Discussion | 20:54 |
blogan | TrevorV: you had something | 20:55 |
TrevorV | So in some of my work with the db-repository blueprint, a question came up. Where do we do validation of request/ownership? | 20:55 |
TrevorV | For example: | 20:55 |
TrevorV | If a customer makes a request to retrieve a load balancer by an ID that doesn't belong to their tenant, where does the exception get thrown from? | 20:56 |
TrevorV | (Implementation detail, I know, but it helps) | 20:56 |
sbalukoff | TrevorV: So I see that as being a function of the API. | 20:56 |
*** jorgem has quit IRC | 20:56 | |
TrevorV | So the API layer would retrieve the object and then check its tenant_id? | 20:56 |
TrevorV | Sort of situation? | 20:56 |
blogan | i think the more generic question is how much validation do we want the database layer to be responsible for versus an actaul validation alyer? | 20:56 |
TrevorV | +1 blogan, much more concise | 20:57 |
xgerman_ | can you circumvent the validation layer? | 20:57 |
*** tmc3inphilly has quit IRC | 20:57 | |
sbalukoff | blogan: Syntax, santity checks at the DB layer, authorization at the validation layer? | 20:57 |
TrevorV | xgerman_, you shouldn't be able to unless you're accessing the operator api | 20:57 |
sbalukoff | Er... | 20:57 |
sbalukoff | Well, I suppose we could do all of that at the validation layer. | 20:57 |
rm_work | are we using RBAC using keystone middleware? | 20:57 |
blogan | xgerman_: i don't think the validation should be able to be circumvented at all, but that could be argued | 20:58 |
dougwig | i like permissions in controller, validation in ORM. but that's me. | 20:58 |
rm_work | if so, they we do it like barbican does it -- assign rbac roles and on the function we say to enforce a specific role requirement, and the middleware handles it | 20:58 |
a2hill | rm_work +1 RBAC can handle a lot of that for us | 20:58 |
xgerman_ | blogan_, I just want to make sure we don't open a security hole by designing it wrong | 20:58 |
xgerman_ | a2hill, rmwork +1 | 20:58 |
xgerman_ | I love roles | 20:58 |
sbalukoff | a2hill, rm_work: +1 | 20:59 |
sbalukoff | Why not go with a precedent, eh? | 20:59 |
blogan | thats fine, but for things that are not handled by rbac | 20:59 |
xgerman_ | example? | 20:59 |
dougwig | the counter-argument is to keep this stuff simple for now, since if we're a driver of lbaas, that crap will all be done for us. | 20:59 |
blogan | such as maximum values | 20:59 |
dougwig | (i.e. a trusted entity) | 20:59 |
dougwig | ((except by sbalukoff)) | 20:59 |
sbalukoff | Haha | 21:00 |
sbalukoff | Ok, well, we're out of time for this meeting. | 21:00 |
sbalukoff | I didn't get a chance to do the vote on whether to keep things here or move back to webex. | 21:00 |
sbalukoff | I'll add that as an agenda item for next time. | 21:00 |
xgerman_ | let's vote next time :-) | 21:00 |
sbalukoff | Thanks y'all! | 21:00 |
sbalukoff | #endmeeting | 21:00 |
openstack | Meeting ended Wed Sep 3 21:00:45 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:00 |
dougwig | yay, another IRC meeting! | 21:00 |
blogan | real quick, if the database can provide an automatic vlaidation (foreign key constraint) should we just rely on that? | 21:00 |
TrevorV | Sounds good, thanks! | 21:00 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-03-20.00.html | 21:00 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-03-20.00.txt | 21:00 |
TrevorV | \0 | 21:00 |
openstack | Log: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-03-20.00.log.html | 21:00 |
blogan | instead of making two calls? | 21:00 |
TrevorV | \o | 21:00 |
rm_work | i know the meeting is over, but | 21:01 |
*** markmcclain1 has quit IRC | 21:01 | |
dougwig | blogan: i hate getting SQL involved, because it makes swapping databases harder. | 21:01 |
rm_work | in response to xgerman_'s concerns, yeah, we shouldn't JUST count on the RBAC/keystone layer | 21:01 |
sbalukoff | rm_work: NO! YOU ARE ABSOLUTELY NOT ALLOWED TO KEEP TALKING | 21:01 |
*** markmcclain has joined #openstack-lbaas | 21:01 | |
sbalukoff | XD | 21:01 |
a2hill | The validation errors will bubble up as a proper error response then that would be fine imo | 21:01 |
dougwig | but i wouldn't object in that case. | 21:01 |
blogan | dougwig: so you're syaing make two calls to the database for that validation? | 21:01 |
rm_work | tenant_id should also be passed through with the object_id to the repository layer and included as part of the filter/lookup | 21:01 |
rm_work | which isn't strictly "validation" so much as "preventing really random bad things from happening" | 21:02 |
dougwig | blogan: i'll cop out, and say that i'd mostly go with the norm for other openstack projects. | 21:02 |
rm_work | sbalukoff: :P | 21:02 |
sbalukoff | dougwig: +1 | 21:02 |
xgerman_ | yeah, putting the tenant_id in the query sounds smart | 21:02 |
rm_work | yeah take a look at the SQLAlchemy layer in Barbican | 21:02 |
rm_work | they do what I am referring to | 21:02 |
blogan | dougwig: okay, going off of neutron, they do a lot of validation in the db module, which i'm not a fan off | 21:02 |
blogan | of | 21:02 |
blogan | however, if it prevents multiple database calls, i can see that point | 21:03 |
xgerman_ | I think Brabican is to right way to go | 21:03 |
rm_work | https://github.com/openstack/barbican/blob/master/barbican/model/repositories.py#L566 | 21:03 |
dougwig | sbalukoff: IRC doesn't seem to be cramping your ability to talk: | 21:03 |
dougwig | https://www.irccloud.com/pastebin/KurFnaFd | 21:03 |
dougwig | :) | 21:03 |
a2hill | but your db is a source of truth, so having that validation there isnt a bad thing is it? | 21:03 |
xgerman_ | yeah, our security people love it when it's almost impossible to get to anotehr tenant | 21:04 |
sbalukoff | dougwig: I could talk two or three times as fast via voice. | 21:04 |
sbalukoff | And so can everyone else. | 21:04 |
dougwig | correct me if i'm wrong, but we don't yet need a solution hardened to billions of hostile users. just one trusted entity. | 21:04 |
sbalukoff | ;) | 21:04 |
blogan | sbalukoff: but we met everythign on the agenda, and it was pretty packed | 21:04 |
sbalukoff | blogan: I felt like I had to cut off some conversations prematurely. | 21:05 |
dougwig | sbalukoff: you out-typed the next chattiest person by 3x !!. :) | 21:05 |
sbalukoff | Like the one we're still having. | 21:05 |
rm_work | sbalukoff: maybe YOU can, but on voice, no one else can talk while you are | 21:05 |
rm_work | sbalukoff: so TOTAL talking will be less | 21:05 |
a2hill | chirpchirp back to the delorean | 21:05 |
sbalukoff | rm_work: Yeah, but focus will be better. As will understanding. | 21:05 |
rm_work | eh | 21:05 |
rm_work | I liked being able to re-read some of the more complicated things people said | 21:05 |
rm_work | in voice it's gone and i have to try to remember and figure out WTF and just get confused :P | 21:06 |
sbalukoff | Really, text is a vastly inferior form of communication for most types of group conversations. | 21:06 |
sbalukoff | text is great if you have specific details to share. | 21:06 |
dougwig | sbalukoff: IMO, most of the conversations that have to end prematurely belong on the ML, so there's some contemplation time. | 21:06 |
rm_work | i'd say text is inferior for SMALL groups, but MUCH better for large groups | 21:06 |
sbalukoff | But it sucks when the point is to try to get consensus on things and understand differing points of view. | 21:06 |
blogan | there a pros and cons to both, but I think for what we are doing IRC is the best fit | 21:07 |
blogan | and you must comply sbalukoff | 21:07 |
sbalukoff | Well, we'll vote on it next week. But I remain unconvinced. :P | 21:07 |
rm_work | because again, while you maybe be able to talk faster than type, talking is limited to exactly 1h of "airtime", whereas if everyone were to talk out loud all the things they said in IRC, i think we'd have 3h+ of talking total :P | 21:07 |
sbalukoff | Haha | 21:07 |
blogan | have you ever been convinced that you were wrong? | 21:07 |
sbalukoff | rm_work: Actually no. If you read the transcript aloud you'll get through it in like 20 minutes. | 21:07 |
rm_work | for example I have said maybe three sentences per meeting in every webex we've had, because i have to compete for airtime | 21:08 |
sbalukoff | blogan: I have, actually. ;) | 21:08 |
rm_work | but i was able to say a lot here :P | 21:08 |
rm_work | sbalukoff: deciding now whether i want to actually make that audio recording just to see what happens | 21:08 |
rm_work | sbalukoff: i might do it | 21:08 |
blogan | lol sbalukoff, there we have precedence. once wrong, always wrong | 21:08 |
sbalukoff | blogan: I argue fiercely for the stuff I'm convinced of, and I guess I expect others to do the same. If I don't have a strong opinion I'll usually say that or refrain from adding much to a discussion, opting instead to listen to others' points of view. | 21:09 |
sbalukoff | But I have been wrong, many times. | 21:09 |
rm_work | i feel that sbalukoff and I are very similar in that regard | 21:09 |
blogan | rm_work: that wouldn't be an accurate measure because people still have to think before speaking so there would be some down time, unless you're sbalukoff | 21:09 |
sbalukoff | Heck, the design we're working off of here is not what I would have recommended last January. | 21:09 |
rm_work | except that i have not been wrong as often :P | 21:09 |
sbalukoff | I think the desing we've got here is vastly superior to what I came up with alone back then. | 21:09 |
* rm_work jabs sbalukoff | 21:09 | |
sbalukoff | blogan: Haha! | 21:10 |
rm_work | I would do it assuming appropriate pauses | 21:10 |
sbalukoff | crc32 did have a good point about IRC though: There is often lack of focus. | 21:10 |
rm_work | and by "appropriate" i mean probably a few seconds at least inbetween switching people | 21:10 |
blogan | sbalukoff: I'm just a terrible speaker when it comes to getting my point across and I do it best through text I believe. I feel that is also soemthing common in a lot of other people as well. | 21:10 |
sbalukoff | 3-4 different conversations happening at once in a single medium. | 21:10 |
rm_work | well, that is just up to the moderator | 21:10 |
dougwig | if anyone wants to channel their inner holy war: https://review.openstack.org/#/c/118479/ | 21:11 |
sbalukoff | It's confusing, especailly if you want to participate in all of these discussions. | 21:11 |
rm_work | but i don't think it's necessarily a bad thing | 21:11 |
dougwig | blogan: +1 | 21:11 |
rm_work | i think of it as parallelizing | 21:11 |
blogan | i'm not sure why having a currently broken env is a problem. can you explain? | 21:11 |
rm_work | but a moderator can easily say "please stick to the topic" | 21:11 |
sbalukoff | blogan: I have not had trouble understanding your points when you've expressed them via voice in the past. | 21:11 |
blogan | that one is kind of ironic | 21:11 |
rm_work | and "please take this out-of-channel or save it till after" and people will generally comply | 21:11 |
sbalukoff | rm_work: Yeah, except they don't. | 21:12 |
rm_work | well | 21:12 |
rm_work | you were the moderator | 21:12 |
sbalukoff | And people who are having trouble following along get left behind in the "text orgy" | 21:12 |
rm_work | feel free to do so :P | 21:12 |
sbalukoff | rm_work: Part of the reason I ended up typing 3x as much as the next person. | 21:12 |
blogan | sbalukoff: well i would argue that is because I've talked about them to you before the webex meeting | 21:12 |
rm_work | heh | 21:12 |
blogan | sbalukoff: on irc | 21:12 |
sbalukoff | blogan: Is that different here? | 21:13 |
sbalukoff | I mean-- we put the agenda out a day before the event. People have time to read through that and know what's going to be discussed and ask questions on IRC beforehand. | 21:13 |
blogan | no, but it obviously works well through IRC (and reviews obviously) | 21:13 |
sbalukoff | blogan: As long as we both agree on terminology and whatnot. | 21:13 |
sbalukoff | blogan: I can't tell you how many times I've seen simple misunderstandings there that would have been easily picked up in voice. | 21:14 |
sbalukoff | (From inflection, the way people actually say the words, etc.) | 21:14 |
rm_work | sbalukoff: i won't argue that what you're talking about doesn't happen | 21:14 |
rm_work | it definitely does | 21:14 |
sbalukoff | Also, sarcasm works really well in text. | 21:14 |
rm_work | but i don't think it's a good enough reason to move to a less accessible medium | 21:14 |
sbalukoff | In any case... | 21:14 |
dougwig | can't we all just agree that the best meeting medium would be emacs? | 21:14 |
dougwig | none of this vim stuff | 21:15 |
blogan | like i said pros and cons to both, IRC pros outweigh the webex pros in my mind | 21:15 |
rm_work | and i DARE you to argue that webex isn't "less accessible" than IRC <_< | 21:15 |
sbalukoff | I don't see me convincing you or you convincing me on this matter-- so I'll defer to what the majority wants when we vote on it next week, eh. | 21:15 |
blogan | sbalukoff: agreed to disagree | 21:15 |
blogan | i think we can all agree IRC is better | 21:15 |
blogan | no opposition, that statement is fact now | 21:16 |
sbalukoff | rm_work: Heh! From using the technology, yes, IRC is easier for most of us. For getting one's point across, if you're a slow typist, or have trouble sorting through the text orgy, IRC is worse. | 21:16 |
sbalukoff | blogan: I'm 1000% in agreement with you. | 21:16 |
rm_work | heh, well, i really want to do a recording of dictating the entire IRC chat... but i have somewhat lost my voice since last weekend (either from yelling too much during gaming, or from some sort of plague) | 21:16 |
blogan | sbalukoff: at least you have something to sort through, with voice you can't sort through any of it | 21:16 |
sbalukoff | blogan: If Trevor is still writing up meeting minutes from the recording, then I would argue that ends up being the best way to digest these meetings. His meeting minutes rock. | 21:17 |
rm_work | yeah, and when i have to look away for a minute (which happens to me REGULARLY during these meetings), i am not completely lost when I come back, I just read the scrollback | 21:17 |
blogan | sbalukoff: he is not allowed to do them anymore | 21:17 |
sbalukoff | blogan: But yes, if you're involved in a voice meeting you have to give your full attention to the meeting. Multi-tasking is less effective. | 21:17 |
sbalukoff | One might argue that's a good thing. ;) | 21:17 |
dougwig | blogan: lol | 21:18 |
rm_work | sbalukoff: it might be, but it doesn't keep me from NEEDING to shift attention >_> | 21:18 |
blogan | not a good thing if there are many things going on with the actual businesses we work for | 21:18 |
rm_work | yes | 21:18 |
dougwig | it's also easy to attend IRC meetings in noisy environments, like airports. which i have done many times. | 21:18 |
rm_work | yeah | 21:18 |
sbalukoff | blogan and rm_work: Again, opinions differ on this. | 21:18 |
blogan | i now | 21:19 |
blogan | i know, im just scratching my arguing itch | 21:19 |
rm_work | sbalukoff: opinions differ on whether or not things come up that cause people to stop paying attention to meetings? :P | 21:19 |
rm_work | i don't think that's an opinion thing | 21:19 |
rm_work | I think that's a fact thing :) | 21:19 |
blogan | sbalukoff: i was just hoping i could be around to see one of those times you would concede defeat | 21:19 |
sbalukoff | rm_work: No, on whether that makes for a more effective meeting. | 21:20 |
sbalukoff | Specifically... | 21:20 |
dougwig | y'all are just debate masturbating at this point. IRC is clearly superior for a variety of reasons, and none of the parties in this conversation are going to change their minds. | 21:20 |
blogan | so....Incubator? | 21:20 |
rm_work | if people have to step away for a minute, they should just be locked out of the discussion because "obviously it isn't important enough for them"? :P | 21:20 |
sbalukoff | We banned laptops and cell phones from a few key meetings in the past, and suddenly they got both a lot more focused, and we got through the material faster. | 21:20 |
sbalukoff | haha | 21:21 |
blogan | well you can't exactly force that on this community | 21:21 |
dougwig | project octavia, the iron fist of openstack. | 21:21 |
rm_work | dougwig +1 | 21:21 |
sbalukoff | Haha! | 21:21 |
blogan | in soviet octavia, meetings run you | 21:21 |
sbalukoff | rm_work: No, figure out how to handle those disruptions without losing focus on the meeting. :P | 21:22 |
blogan | alright i gotta get off for a bit | 21:22 |
blogan | ill be on later | 21:22 |
sbalukoff | I just really hate seeing things dragged out a lot longer than they need to be, which I think happens with IRC relatively frequently. | 21:22 |
blogan | i enjoyed this | 21:22 |
dougwig | sbalukoff: pay attention to the chairing of the next neutron meeting. things do not drag out. | 21:23 |
sbalukoff | dougwig: How quickly is consensus achieved? | 21:24 |
sbalukoff | Just because you got through an agenda doesn't mean it was an effective discussion. :P | 21:24 |
dougwig | either very quickly, or it's a damn fast punt to another medium. the meeting is just a synchronization point. | 21:24 |
dougwig | there is discussion and decisions. | 21:25 |
sbalukoff | Yeah, and what you're saying is that meetings are not appropriate for discussions. | 21:25 |
sbalukoff | This is a pretty fundamental difference from what I think. | 21:25 |
dougwig | FIVE MINUTES REMAIN TO VOTE. this is your last chance to load it up in another browser with a new color and go chicago on the results. | 21:25 |
sbalukoff | And I think that idea is imposed because having a good discussion on IRC in a short enough interval is next to impossible. | 21:26 |
dougwig | no, not what i said at all. some agenda items are flagged for discussions, and go on longer. | 21:26 |
rm_work | lol dougwig | 21:26 |
sbalukoff | How do the "discussions" happen? | 21:26 |
sbalukoff | Mailing list thread? | 21:26 |
rm_work | only one I like in there is Worker, really (and peon/grunt, but i don't expect others to like it) so whatev | 21:26 |
sbalukoff | Again, that's often not the best place for them. | 21:26 |
dougwig | depends. i've seen some in channel, a lot to ML, some to phone conferences. | 21:26 |
sbalukoff | Oh, so they do go to voice? | 21:26 |
dougwig | yeah, some of the incubator stuff went to voice. | 21:27 |
sbalukoff | Anyway, my point is that in the IRC meetings, no actual discussion of the topic takes place. As you were saying, it either gets decided quickly or gets punted to another medium. The IRC meetings are seen as a place to "synchronize" on what are presumably pretty much already-discussed points. | 21:29 |
sbalukoff | My point is that if you have a voice meeting, you actually can discuss things there because the bandwidth is so much higher, and the chances of being misunderstood are lower. | 21:30 |
sbalukoff | People are also less rude to each other via voice. | 21:30 |
sbalukoff | Generally speaking. | 21:30 |
dougwig | i saw quite a bit of discussion happening today. it's true that you can't always get to consensus, but some of those topics i wanted more time to think about anyway. | 21:31 |
dougwig | wait, how did i get sucked into arguing about this? we won't resolve this, via either an IRC argument or voice. :) | 21:32 |
sbalukoff | So, there's no reason you can't punt to another medium or later date when having a voice meeting. | 21:32 |
sbalukoff | And yes, we discussed things, but the point is that discussion was truncated often without a good conclusion. | 21:32 |
sbalukoff | Haha! | 21:32 |
sbalukoff | Wow, just looked at the line counts from the meeting. | 21:35 |
sbalukoff | I think I may have come close to matching the total of everyone else. XD | 21:35 |
sbalukoff | (I don't think that happens via voice, but I could be wrong-- I'm pretty sure I yield the floor more often than that when I'm not pushing insanely hard to actually get through the whole agenda like I felt pressured to do this week.) | 21:36 |
sbalukoff | ;) | 21:36 |
sbalukoff | Anyway, I'll quit talking about that now. | 21:36 |
* rm_work starts narrating into a recorder | 21:48 | |
sbalukoff | Haha! Awesome. | 21:53 |
*** rm_work has quit IRC | 21:54 | |
sbalukoff | Yay, google: http://www.mindwareconnections.com/blog/bid/79429/Can-I-Type-Faster-Than-I-Talk-A-Dragon-Comparison | 21:54 |
sbalukoff | That's mostly marketing, I think. | 21:55 |
sbalukoff | This is probably less biased: http://en.wikipedia.org/wiki/Words_per_minute | 21:55 |
sbalukoff | Also, rm_work: While you can have 3-4 different conversations going on at once, the extra time it takes to try to follow those conversations probably trumps any parallelism benefit. | 21:56 |
sbalukoff | But it is easier to get a word in edge-wise with IRC, mostly. | 21:56 |
sbalukoff | (Unless you're up against me, and I miss what you typed... :P ) | 21:57 |
sbalukoff | Because I can keep droning on, and on, and on. ;) | 21:57 |
sbalukoff | Like right now. | 21:57 |
sbalukoff | Why am I still typing? Even I don't know. | 21:57 |
sbalukoff | And like the rest of you, I kinda wish I'd shut up. | 21:57 |
*** TrevorV_ has joined #openstack-lbaas | 21:59 | |
*** rm_work|away has joined #openstack-lbaas | 22:01 | |
*** rm_work|away is now known as rm_work | 22:01 | |
*** rm_work has joined #openstack-lbaas | 22:01 | |
*** vivek-ebay has quit IRC | 22:02 | |
*** vivek-ebay has joined #openstack-lbaas | 22:03 | |
*** openstack has joined #openstack-lbaas | 22:10 | |
a2hill | battlestar-loadtallica won right? I mean it wasnt even a challenge right? | 22:11 |
*** markmcclain has quit IRC | 22:20 | |
dougwig | runoff voting is now open: https://etherpad.openstack.org/p/octavia-backend-name | 22:23 |
dougwig | heh, another benefit to IRC. if sbalukoff keeps talking, you can close the window. | 22:24 |
blogan | lol | 22:25 |
blogan | same with webex of course | 22:25 |
blogan | actually you can mute him in webex and watch all his hand motions | 22:25 |
blogan | which could be entertaining | 22:25 |
dougwig | ooh, that's a fun idea. | 22:26 |
a2hill | his video is usually disabled though :P | 22:26 |
blogan | is ant/colony really a serious contendor? | 22:26 |
a2hill | lmbo | 22:26 |
sbalukoff | I expect to see my actions re-dubbed into something funny if y'all are going to do that. XD | 22:26 |
sbalukoff | Yeah, my laptop camera has... spotty reliability. | 22:26 |
blogan | if Octavia was called AntFarm or AntHill or something, i could see that making sense | 22:26 |
dougwig | it had a total of 0. i already editorialized out one contender. i didn't want to do two. | 22:27 |
blogan | which one? | 22:27 |
dougwig | maybe we should take a page from the rotating times that neutron and nova use, and suggest rotating irc/voice every other week? | 22:27 |
dougwig | (peon) | 22:27 |
blogan | oh battlestar-loadtallica | 22:27 |
blogan | oh nevermind | 22:27 |
dougwig | oh, and that one. | 22:27 |
dougwig | i used number of votes to kind of sway in some lower ones. | 22:28 |
blogan | are you abstaining? | 22:28 |
dougwig | there are none that i *love* on that list, so i'm still thinking about it. | 22:29 |
*** vivek-ebay has quit IRC | 22:29 | |
blogan | i thought you would like mechanism the most | 22:29 |
*** vivek-ebay has joined #openstack-lbaas | 22:30 | |
*** TrevorV_ has quit IRC | 22:32 | |
rm_work | ah | 22:33 |
rm_work | how long for runnoff? | 22:33 |
blogan | 30 more mins | 22:33 |
*** vivek-ebay has quit IRC | 22:33 | |
rm_work | lol dougwig voted against one of his own later ideas :P | 22:34 |
*** vivek-ebay has joined #openstack-lbaas | 22:35 | |
sbalukoff | I should have voted agianst most of my suggestions there because they were mostly terrible. | 22:36 |
rm_work | heh | 22:37 |
rm_work | I liked worker / colony better than ant/colony, but ant made it :( | 22:37 |
rm_work | and I liked peon better than grunt :P but ah well | 22:37 |
dougwig | i'll leave the runoff until 9pm mountain. | 22:38 |
dougwig | blogan: my order is roughly: mechanism, pod, appliance, ... distant ..., ant/colony/grunt, ... far far away ..., device. | 22:38 |
sbalukoff | I totally changed my vote. | 22:41 |
sbalukoff | I'm so wishy-washy. | 22:41 |
sbalukoff | And... back again. | 22:41 |
sbalukoff | So sneaky! | 22:42 |
sbalukoff | Ok, so... I need to go AFK for a while, I've got a massive gut-ache and I'm starting to get loopy. Catch y'all later. | 22:42 |
rm_work | I thought you DIDN'T like Appliance? | 22:46 |
rm_work | or that Octavia as a whole is supposed to be an "appliance" | 22:46 |
rm_work | so having an Appliance with internal Appliances makes little sense | 22:46 |
dougwig | i don't like appliance, since depending on the lbaas spinout ,we could have appliance meaning two different things. | 22:46 |
rm_work | yes | 22:47 |
rm_work | it's on my list of "bad" | 22:47 |
dougwig | third on my list is not above the "like" line. :) | 22:47 |
rm_work | but now I am worried that if I spread out my vote, Appliance could win :) | 22:47 |
dougwig | lol | 22:47 |
rm_work | I don't like mechanism because the implication just seems... wrong to me | 22:47 |
rm_work | I'll vote for pod if you do :) | 22:47 |
rm_work | just please god not appliance | 22:48 |
dougwig | i don't like ant because it's such a common build system, that having an ant subdir will have obvious implications. | 22:48 |
rm_work | why did I forget to -1 appliance earlier T_T | 22:48 |
dougwig | i don't like device because it's about as vague as "object". | 22:48 |
rm_work | dougwig: right, agree | 22:48 |
rm_work | I liked worker for that T_T | 22:48 |
rm_work | worker/colony | 22:48 |
rm_work | ant is >_< | 22:48 |
rm_work | worker describes the thing quite well, not sure why people so vehemently dislike it | 22:48 |
dougwig | that combo was -1. | 22:49 |
dougwig | if i pull that in, the list gets way long. | 22:49 |
rm_work | yeah >_> | 22:50 |
rm_work | i think probably the only reason ant/colony wasn't -1 as well was because the person who -1'd the whole list including worker, was already offline when ant/colony was added :P | 22:50 |
rm_work | or, not the whole list, but... >_> | 22:51 |
rm_work | lol trevor did -1 to everything but toadlactica, "", and container | 22:51 |
rm_work | rofl | 22:51 |
rm_work | so wha'd'ya say? pod? i'm not a huge fan of mechanism, but I HATE appliance | 22:52 |
rm_work | and if we both vote pod, it's not as scary] | 22:52 |
blogan | do mechanism over pod | 22:52 |
rm_work | you voted for appliance >_> | 22:53 |
blogan | so | 22:53 |
blogan | id rather have mechanism over pod | 22:53 |
blogan | so you do as i say | 22:53 |
rm_work | lol | 22:53 |
sbalukoff | I'm back on the 'pod' bandwagon. | 22:53 |
rm_work | woot | 22:53 |
blogan | damny you sbalukoff! | 22:53 |
blogan | and damn | 22:53 |
rm_work | pod makes sense as a thing that "contains" the haproxy/nginx/whatever | 22:53 |
rm_work | mechanism... >_> | 22:54 |
rm_work | and appliance is a conflict | 22:54 |
blogan | this is going ot be shuffling of votes because i will vote for mechanism if it looks like appliance will be the equivalent of ron paul | 22:54 |
rm_work | lol | 22:54 |
blogan | honestly, i'd be fine with any of those 3 | 22:54 |
blogan | pod i feel a bit dirty with, but ive felt dirtier before and quickly got over that | 22:55 |
dougwig | too bad we didn't add some roman themed containers. amphora, aqueduct, etc. | 22:55 |
rm_work | I still like worker best but pod is my second choice from the list i think | 22:55 |
dougwig | given our project name. | 22:55 |
rm_work | yeah | 22:55 |
sbalukoff | cistern | 22:55 |
rm_work | dougwig: i was just thinking we are really bad shape here thematically | 22:55 |
blogan | quick dougwig | 22:55 |
blogan | do it | 22:55 |
rm_work | ohshiiiii\ | 22:55 |
blogan | find something | 22:55 |
rm_work | can we restart voting with better names plox >_> | 22:55 |
rm_work | even cistern is better | 22:55 |
rm_work | lol | 22:55 |
blogan | ive gotta take care of a baby | 22:55 |
rm_work | amphora is good actually | 22:56 |
dougwig | fuck it, voting is postponed until tomorrow. these names all suck. let's explore the roman theme. | 22:56 |
sbalukoff | ... | 22:56 |
sbalukoff | seriously? | 22:56 |
rm_work | dude, amphora | 22:56 |
rm_work | we should really have stuck to theme | 22:56 |
dougwig | sbalukoff: half? | 22:56 |
sbalukoff | That's true. | 22:56 |
sbalukoff | I guess Octavia is a roman name. | 22:56 |
rm_work | yes | 22:56 |
dougwig | i only thought of the roman thing 5 minutes ago. | 22:56 |
sbalukoff | See, dougwig! | 22:57 |
rm_work | that and this "second round of voting" after everyone at rackspace has left except me and brandon, is ... >_< | 22:57 |
sbalukoff | You should totally have taken this thing seriously earlier. XD | 22:57 |
rm_work | yeah I had been thinking about thematic names but i forgot it was roman | 22:57 |
sbalukoff | rm_work ... awesome? | 22:57 |
dougwig | dude, i have been trying to think of names since last week. i can't control inspiration. | 22:57 |
rm_work | sbalukoff: lol | 22:57 |
rm_work | right? just needed a muse | 22:57 |
sbalukoff | dougwig: There's an RFC for that. | 22:57 |
dougwig | haha, you switched to pod again? | 22:58 |
rm_work | so do all parties present agree to postpone? :P | 22:58 |
sbalukoff | (see earlier statements about me being loopy.) | 22:58 |
dougwig | what say ye, slip in some roman names and leave the final vote open until tomorrow? roll with what we've got? restart from scratch? | 22:58 |
sbalukoff | Well, let's hear some roman name suggestions. | 22:58 |
rm_work | Amphora | 22:58 |
rm_work | was his and mine | 22:58 |
dougwig | amphora, aqueduct, cistern | 22:59 |
dougwig | dolium | 22:59 |
rm_work | amphora is thematic, very accurate, and doesn't conflict directly with "container" | 22:59 |
rm_work | and a lot of people hopefully don't have to look it up, i think | 22:59 |
dougwig | chariot? | 22:59 |
rm_work | I knew the word already... | 22:59 |
rm_work | hmm | 22:59 |
rm_work | yeah anyway, I think we restart with this narrowed down list + roman stuff | 22:59 |
rm_work | I think there are some clear winners in the roman group | 23:00 |
sbalukoff | pithos | 23:00 |
dougwig | caltrop (i never knew that was roman) | 23:00 |
rm_work | but we have to be fair to the existing ones I guess | 23:00 |
sbalukoff | The amphora complements the large storage container, the pithos, which makes available capacities between one-half and two and one-half tons. | 23:00 |
rm_work | wait caltrop is roman? and... related? | 23:00 |
rm_work | isn't a caltrop a spike for injuring marching footmen/cavalry? | 23:00 |
sbalukoff | I like chariot | 23:00 |
sbalukoff | rm_work: It is. | 23:00 |
dougwig | rm_work: it was a hit when googling "roman device" | 23:01 |
rm_work | not sure caltrop provides great imagery :P | 23:01 |
rm_work | hah | 23:01 |
rm_work | I googled "roman container" | 23:01 |
rm_work | because other than the naming conflict, container is the idea we're trying to get across | 23:01 |
dougwig | yeah, that was my first google. | 23:01 |
rm_work | I see Dolium too | 23:01 |
rm_work | though I feel like that is less well known than Amphora | 23:02 |
rm_work | small, agile, and very numerous | 23:02 |
*** vivek-ebay has quit IRC | 23:02 | |
rm_work | and Amphorae is a good plural :P | 23:02 |
*** vivek-ebay has joined #openstack-lbaas | 23:03 | |
rm_work | I think Amphora has my vote, i feel MUCH better about that than any of the shitty options we started with :P | 23:03 |
rm_work | glad dougwig had some inspiration in the nick of time | 23:03 |
rm_work | ah so we're just adding them instead of voting to postpone? :P | 23:04 |
* dougwig feigns innocence | 23:04 | |
*** TrevorV_ has joined #openstack-lbaas | 23:04 | |
*** vivek-ebay has quit IRC | 23:04 | |
sbalukoff | Changing sides again. | 23:04 |
dougwig | i'm joining you | 23:04 |
sbalukoff | We can call it 'amp' for short. | 23:05 |
sbalukoff | Because I like shortening things. | 23:05 |
rm_work | yeah i like that | 23:05 |
rm_work | easy to shorten in conversation to "amps | 23:05 |
sbalukoff | And we totally won't call it by a 3-syllable name in the long run. ;) | 23:05 |
rm_work | " | 23:05 |
rm_work | blogan: quick, change your vote | 23:05 |
rm_work | :P | 23:05 |
sbalukoff | HAHA | 23:05 |
*** vivek-ebay has joined #openstack-lbaas | 23:05 | |
rm_work | cistern makes me think of toilets >_> | 23:06 |
blogan | so i do have some reservations about this now | 23:06 |
rm_work | blogan: i have some reservations about your face | 23:07 |
rm_work | but i'll let them slide this once | 23:07 |
sbalukoff | HAHA | 23:07 |
blogan | one argument for going against one of those is that someone new coming into the project would not know what appliance/device or whatever means | 23:07 |
sbalukoff | Good! Read some fscking docs. ;) | 23:07 |
rm_work | heh | 23:07 |
blogan | i guarandamntee you that new people will not know what amphora will be | 23:07 |
rm_work | right | 23:07 |
rm_work | but they won't MISTAKE IT for another concept | 23:07 |
sbalukoff | No really... that's probably because they don't understand what the actual meaning of the word 'amphora' is. | 23:07 |
rm_work | it'll just be an unknown until they read up | 23:07 |
sbalukoff | Once they learn that, they'll understand. | 23:07 |
blogan | sbalukoff: thats what i mean | 23:07 |
sbalukoff | rm_work: | 23:08 |
blogan | its a container | 23:08 |
sbalukoff | Yes, avoiding conflict with another term is actually better here. | 23:08 |
rm_work | right | 23:08 |
blogan | so if container had a problem wouldnt this? | 23:08 |
sbalukoff | Yeah, but we chose another term because 'container' means different things in other contexts. | 23:08 |
sbalukoff | It could very well be a VM. | 23:08 |
* rm_work gets out his gladiator gear in preparation to agree VIOLENTLY with sbalukoff | 23:08 | |
sbalukoff | Do you know of anything else named 'amphora' in IT? | 23:08 |
blogan | im not saying im against it, just saying there could be issues | 23:08 |
sbalukoff | or computer science? | 23:08 |
rm_work | yes, and Amphora MEANS container, but doesn't have the same specific connotation as the english WORD container | 23:09 |
rm_work | which is why it works | 23:09 |
sbalukoff | Oh man, I'm totally going to re-watch that movie tonight. | 23:09 |
rm_work | excellently | 23:09 |
blogan | is a good point | 23:09 |
sbalukoff | Specifically amphora is a smallish jar. | 23:09 |
sbalukoff | So, I like that over other words for 'container' in roman, too. | 23:09 |
rm_work | yeah. well, somewhat small. not small compared to a mason jar :P | 23:09 |
blogan | well, why are we sending commands to a smallish jar | 23:10 |
sbalukoff | Because these things are supposd to be smallish. We'll just have a ton of them in a large cloud. | 23:10 |
dougwig | we're not... we're sending them to AMPHORA!!!! | 23:10 |
rm_work | because we use smallish-VMs/containers :P | 23:10 |
blogan | lets just call it elysium | 23:10 |
rm_work | sbalukoff: exactly :P | 23:10 |
rm_work | and amphorae were small but used in large numbers :P | 23:10 |
rm_work | so, perfect! | 23:10 |
sbalukoff | rm_work is totally convincing me. | 23:10 |
rm_work | sbalukoff: pfft, what, *you* are convincing *me* | 23:11 |
rm_work | what's going on here | 23:11 |
blogan | he never quits until he has or one of you are dead | 23:11 |
rm_work | i'm confused because we are in a feedback loop i think | 23:11 |
rm_work | convincing each other | 23:11 |
sbalukoff | Haha | 23:11 |
rm_work | of the same thing | 23:11 |
sbalukoff | violent agreement. | 23:12 |
dougwig | circle jerk detected! | 23:12 |
blogan | i like it better than pod | 23:12 |
rm_work | haha | 23:12 |
sbalukoff | You're right, dammit! | 23:12 |
sbalukoff | blogan: +1 | 23:12 |
rm_work | +1s all around | 23:12 |
blogan | but also should this be decided on with a minority? | 23:12 |
* rm_work is going to be super disappointed when he looks in the morning and amphora is losing somehow | 23:12 | |
sbalukoff | Too late. I'mma go update design docs and diagrams now. | 23:12 |
sbalukoff | ;) | 23:13 |
rm_work | I mean, I think the plan is still to do the vote via the page | 23:13 |
rm_work | but | 23:13 |
blogan | when does the vote close? | 23:13 |
rm_work | amphora should be +4 now against 0 | 23:13 |
dougwig | the vote is staying open until tomorrow at lunchtime. | 23:13 |
* rm_work glares at blogan | 23:13 | |
sbalukoff | Haha! | 23:13 |
rm_work | oh wait, is that blogan voting for appliance, or some unnamed person | 23:13 |
sbalukoff | So, we'll document this decision on the non-arbitrary decisions page. | 23:13 |
rm_work | there's two of almost the same exact color | 23:13 |
sbalukoff | Though it still is rather arbitrary. | 23:13 |
blogan | so you're saying I have until lunch for you to pander to me for my vote? | 23:14 |
rm_work | lol | 23:14 |
dougwig | that's blogan. and you know what happened to traitors in rome. | 23:14 |
sbalukoff | But still. WE WASTED TIME ON THIS! So, we're definitely not not documenting it. | 23:14 |
blogan | gifted with gold and set free to go make their own country? | 23:14 |
rm_work | whelp. i'm happy with this "decision". | 23:14 |
rm_work | time to head home then :) | 23:14 |
dougwig | i'll note that my original patchset had vm/driver, which NOT ONE PERSON actually misunderstood. | 23:14 |
sbalukoff | blogan: Yes, of course. Let me just size up this cross for you... | 23:14 |
rm_work | ugh, early morning meeting tomorrow | 23:14 |
sbalukoff | rm_work: Yeah. :P | 23:15 |
rm_work | glad I'm no longer in PST... though I feel like I am >_> | 23:15 |
blogan | no one misunderstood because we've been using that term for a while because we know the first iterations will be using VMs | 23:15 |
sbalukoff | dougwig: Yep. | 23:15 |
*** mlavalle has quit IRC | 23:15 | |
blogan | my kid is so fussy right now | 23:17 |
sbalukoff | Why are you paying attention to your kid when you could be paying attention to me? | 23:18 |
sbalukoff | Has anyone thought of my feelings here? | 23:18 |
sbalukoff | Ok, seriously, heading offline now. | 23:19 |
blogan | you are like baby huey | 23:19 |
*** mlavalle_ has joined #openstack-lbaas | 23:21 | |
TrevorV_ | HA I forgot to vote... damnit :D | 23:22 |
TrevorV_ | Sucks to be me | 23:22 |
sbalukoff | http://33.media.tumblr.com/tumblr_lhhkdyZ4zm1qcrozeo1_500.gif | 23:23 |
sbalukoff | Maybe like that. | 23:23 |
sbalukoff | TrevorV_: VOTE! It's ongoing. | 23:24 |
sbalukoff | But you missed the discussion of amphora earlier | 23:24 |
sbalukoff | You're totally off the project if you don't vote for amphora. | 23:24 |
sbalukoff | Just sayin' | 23:24 |
TrevorV_ | sbalukoff: You're supposed to be offline by now right? | 23:25 |
TrevorV_ | Link me real quick, I'll put in a vote | 23:25 |
sbalukoff | Argh! Dammit! | 23:25 |
TrevorV_ | Lulz | 23:25 |
*** ptoohill has quit IRC | 23:25 | |
sbalukoff | https://etherpad.openstack.org/p/octavia-backend-name | 23:25 |
sbalukoff | I am supposed to be offline. | 23:25 |
TrevorV_ | See you tomorrow morning sbalukoff (so GTFO bruh!) | 23:26 |
sbalukoff | Heh! Will do! | 23:26 |
rm_work | ha, spirited away baby :P | 23:28 |
rm_work | oh right and i was going home | 23:28 |
* rm_work homes | 23:28 | |
*** TrevorV_ has quit IRC | 23:28 | |
*** mlavalle_ has quit IRC | 23:54 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!