14:00:04 <dougwig> #startmeeting neutron lbaas
14:00:05 <openstack> Meeting started Thu Sep 11 14:00:04 2014 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:09 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:09 <dougwig> agenda:
14:00:11 <dougwig> #link https://wiki.openstack.org/wiki/Network/LBaaS#Meeting_11.09.2014
14:00:21 <balles> morning
14:00:24 <dougwig> #topic Announcements
14:00:26 <xgerman> morning
14:00:30 <jorgem> morning
14:00:36 <rm_work> o/
14:00:46 <vivek-ebay> \o/
14:00:49 <sbalukoff> Morning!
14:00:49 <dougwig> i think we're in the middle of rc1.  i don't think that has any lbaas stuff
14:00:49 <johnsom> morning team
14:00:51 <dougwig> #link #link https://launchpad.net/neutron/+milestone/juno-rc1
14:00:54 <dougwig> link link
14:00:55 <dougwig> #link https://launchpad.net/neutron/+milestone/juno-rc1
14:01:07 <dougwig> kilo specs are around the corner.
14:01:20 <dougwig> any other announcements?
14:01:45 <dougwig> moving
14:01:46 <dougwig> on
14:01:56 <dougwig> #topic Barbican integration -- Keystone Trusts, comments and concerns (rm_work)
14:01:58 <dougwig> rm_work?
14:02:02 <rm_work> yeah
14:02:08 <dougwig> the floor is yours
14:02:26 <rm_work> so, this was my action item from last week (actually to send this to the mailing list) but there were some … complications
14:02:42 <rm_work> so, this is the workflow I had hoped we could use: http://i.imgur.com/74BUbMf.png
14:03:05 <xgerman> I object to the word "hijacks"
14:03:11 <sbalukoff> Heh!
14:03:13 <rm_work> yes
14:03:15 <rm_work> well
14:03:23 <rm_work> i'm getting to WHY i use that term specifically
14:03:44 <rm_work> so, more granularly, it looks like this: http://goo.gl/X3kKIX
14:04:34 <jorgem> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgTEJhYVMtS2V5c3RvbmUtQmFyYmljYW4gSW50ZXJhY3Rpb24gKGFzc3VtaW5nIGFuIEFzeW5jIEFwcGxpYW5jZSkKClVzZXItPgA7CDogR2V0IGEgVXNlciBUb2tlbgpub3RlIGxlZnQgb2YAEwU6IHVzaW5nAB8FbmFtZS9QYXNzd29yZAoAgQAJPgAiBlJldHVybgBBDgBqBgCBIgg6IENyZWF0ZSBhIFNlY3JldCAiQ2VydGlmaWNhdGUiAF8eAIEaBwCBbggAZw8ASgZJRDEAUSJQcml2YXRlIEtleQAuRTIAgUwaQ29udGFpbmVyICJNeSAAgSRIAE0JSUQAg0oHAIQVBQCCUwtUTFMgVGVybWluYXRlZCB
14:04:40 <sbalukoff> That'll take a minute to digest.
14:04:44 <jorgem> that doesn't have ad stuff
14:04:46 <rm_work> jorgem: the full link is unworkable for IRC <_<
14:04:52 <blogan> i think my day has been settled
14:05:00 <rm_work> you actually only posted like 1/2 of it :P
14:05:06 <blogan> wtg jorgem
14:05:16 <xgerman> somehow jorgem's link worked for me
14:05:16 <rm_work> err maybe 1/4 of it
14:05:18 <jorgem> i see the whole link…oh well
14:05:23 <rm_work> look at the diagram
14:05:27 <rm_work> it goes down to like
14:05:38 <dougwig> #link http://i.imgur.com/74BUbMf.png
14:05:40 <rm_work> 1/8 of the length of the full one
14:05:44 <rm_work> anyway
14:05:48 <dougwig> #link http://goo.gl/X3kKIX
14:06:07 <dougwig> #link
14:06:07 <dougwig> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgTEJhYVMtS2V5c3RvbmUtQmFyYmljYW4gSW50ZXJhY3Rpb24gKGFzc3VtaW5nIGFuIEFzeW5jIEFwcGxpYW5jZSkKClVzZXItPgA7CDogR2V0IGEgVXNlciBUb2tlbgpub3RlIGxlZnQgb2YAEwU6IHVzaW5nAB8FbmFtZS9QYXNzd29yZAoAgQAJPgAiBlJldHVybgBBDgBqBgCBIgg6IENyZWF0ZSBhIFNlY3JldCAiQ2VydGlmaWNhdGUiAF8eAIEaBwCBbggAZw8ASgZJRDEAUSJQcml2YXRlIEtleQAu
14:06:07 <dougwig> RTIAgUwaQ29udGFpbmVyICJNeSAAgSRIAE0JSUQAg0oHAIQVBQCCUwtUTFMgVGVybWluYXRlZCB
14:06:09 <rm_work> yeah is it ok if I give people a minute to digest that before I move on?
14:06:12 <dougwig> heh
14:06:14 <rm_work> yeah seriously
14:06:17 <rm_work> the link doesn't work in IRC :P
14:06:26 <blogan> i object to the word "appliance"
14:06:35 <xgerman> heh
14:06:36 <balles> I did a copy link and was able to get that link up in my browser
14:06:38 <rm_work> blogan: I object to your face, but that's equally irrelevant
14:06:56 <rm_work> balles: it's not the WHOLE diagram
14:07:00 <rm_work> it cuts off
14:07:03 <rm_work> trust me :P
14:07:04 <sbalukoff> Haha
14:07:05 <balles> oh I see
14:07:11 <balles> lol
14:07:18 <blogan> i blame jorgem for this
14:07:33 <rm_work> #link the last link is not useful
14:07:37 <rm_work> anyway
14:08:04 <rm_work> maybe people have managed to kind of look through that
14:08:49 <rm_work> so, the issue is with the kind of Keystone Tokens that will be coming in
14:08:51 <sbalukoff> I don't see anything wrong with this sequence at first glance. Note that it is early, and I'm not sure my usual snarkiness is awake.
14:09:10 <xgerman> you say that likes a bad thing
14:09:15 <rm_work> So, this is great from a usability standpoint, because it is completely transparent to the user
14:09:25 <xgerman> yep, I oike that
14:09:55 <rm_work> but (and this is the reason I used "hijack" in the first chart, on purpose) it really is a bit scary from a security perspective
14:10:16 <rm_work> and besides that, apparently Trusts cannot be created using a Token that is already a Trust Token
14:10:28 <rm_work> which is what HEAT and possibly Horizon will be using
14:10:42 <samuelbercovici> so in this case instead of having the "user cred" we store the "Trust ID"?
14:10:46 <rm_work> or a Token which the user has specifically made lower privilege, which apparently is a thing people do?
14:10:51 <rm_work> samuelbercovici: yes
14:11:13 <rm_work> which then allows us to "Execute the Trust" with Keystone, which is very similar to getting a token to begin with
14:11:27 <vivek-ebay> is storing "Trust ID" equally dangerous as storing password ?
14:11:32 <balles> rm_work, I know Trove is doing something similar
14:11:34 <rm_work> we use our own token to talk to keystone and pass the trust ID, and we get a Trust Token back
14:11:45 <samuelbercovici> can "Trust ID" be hijacked? in other words if someone elase has the "trus id" can he then read the secured information?
14:12:02 <rm_work> vivek-ebay: well, the trust is only useful for our account, so they'd need the TrustID *and* a valid token for our service account
14:12:08 <rm_work> samuelbercovici: ^^
14:12:25 <rm_work> the TrustID is linked specifically between two accounts
14:12:36 <sbalukoff> So it's slightly less dangerous than storing the user's password. But only slightly.
14:12:36 <rm_work> but Keystone *does* consider them "sensitive data"
14:12:55 <xgerman> well, what's the alternative? Storing the certs in our DB?
14:12:58 <sbalukoff> Is there any way around that?
14:13:01 <sbalukoff> jinx!
14:13:10 <samuelbercovici> ic. so the hijacker needs to impersonat the LBaaS service user whic is supposed to be non-interactive?
14:13:12 <rm_work> if someone were to compromise our API box, yeah, they could get the password to our service account from config, and also access to our DB and then to the TrustIDs
14:13:25 <dougwig> is this the new way of doing cross-service stuff?  i note that for using nova, there is just a user/pass in the clear in neutron.conf
14:13:31 <vivek-ebay> I assume this is not specific to LBaaS and should be a common problem. What does Barbican guys suggest ?
14:13:47 <rm_work> well, I have seem some stuff about Postern
14:13:49 <dougwig> ahh, you answered my question one line before i asked it.
14:13:53 <rm_work> but it's kind of a chicken/egg problem
14:14:03 <xgerman> well, we can use encrypted config files
14:14:13 <xgerman> we can force users to enter pwd at startup...
14:14:23 <xgerman> that's am old /solved problem in CS
14:14:31 <sbalukoff> Eew and eew.
14:14:33 <sbalukoff> ;)
14:14:45 <rm_work> #link https://github.com/cloudkeep/postern
14:14:58 <rm_work> I think that's the right repo
14:15:06 <rm_work> but obviously… not ready
14:15:49 <rm_work> so anyway, we've got two real issues here
14:16:12 <rm_work> 1) This whole thing is a security issue (almost just kicking the rock down the road)
14:16:36 <rm_work> 2) We may not actually be able to do Trust creation on our side -- it may be NECESSARY to have the user do it themselves (though we can provide them a template)
14:16:45 * TrevorV late but present :(
14:16:57 <xgerman> 2) Worries me more than 1)
14:17:04 <blogan> 2 is a terrible user experience
14:17:06 <rm_work> I don't know if #1 is solvable at the moment, and this is still better than just plaintext certs in the DB
14:17:17 <xgerman> rm_work +1
14:17:19 <rm_work> so yes, #2 here is my real discussion topic
14:17:45 <xgerman> can horizon do #2?
14:17:53 <samuelbercovici> so in other words, the user authorizes lbaas to be allowed access to his secrets, right?
14:18:07 <rm_work> Well, I need to get in touch with someone from Horizon -- I asked in their IRC channel yesterday but never got a response
14:18:09 <balles> It looks like the use has to do something with rehards to trusts. The doc says: In both cases, the users authorizes it at setup time to perform this action any time in the future, long after the token is expired.
14:18:12 <rm_work> samuelbercovici: yes
14:18:31 <balles> rm_work, ^^^ but I am sure you know that already
14:18:36 <rm_work> balles: right, it allows us to essentially get a new token
14:18:38 <rm_work> on our own
14:18:52 <rm_work> but the issue is that Creating Trusts requires a "full privilege" user token
14:19:12 <rm_work> and many of the use-cases will have some other service already using a lower privilege Trust Token
14:19:19 <xgerman> so let's split that problem
14:19:24 <rm_work> so we'll be given a token that doesn't have the ability to create a Trust
14:19:48 <blogan> even if horizon exposes it, if horizon uses a trust then horizon would not be able to create another trust for lbaas
14:20:05 <rm_work> blogan: yeah, and i am not 100% clear on that
14:20:07 <xgerman> I am ok with the command line being cumbersome
14:20:10 <rm_work> but i don't know how else horizon would work?
14:20:26 <rm_work> if we think 99% of our users will come from the API, then … whatever? we just ignore the issue and tell them to use a real token
14:20:28 <xgerman> but Horizon should be more like press an Accept button
14:20:48 <rm_work> if we think a ton of people will come in through Horizon (which is my theory) then this may still be a problem
14:20:55 <dougwig> is this a case of openstack deciding that something "should" be a certain way, telling people to do it that way, even though it's really used everywhere in an entirely different fashion, and is nowhere near ready for the "new and correct" way?
14:21:05 <samuelbercovici> rm_work: is there a way that the uses will just authorize lbaas service user access to the private info?
14:21:07 <balles> rm_work, ok make sense.
14:21:08 <rm_work> dougwig: I thought so at first
14:21:27 <rm_work> dougwig: but the Keystone guys actually showed me that in a lot of cases my plan will actually fail
14:21:32 <samuelbercovici> actualy since lbaas runs inside neutron, it may be the neutron service user
14:21:33 <rm_work> dougwig: HEAT was the certain example
14:21:33 <samuelbercovici> ?
14:21:40 <rm_work> samuelbercovici: correct
14:21:45 <rm_work> for now it is the Neutron service user
14:22:21 <rm_work> samuelbercovici: so, the way to just "authorize our user" on their side is for them to hit Keystone and create the Trust themselves (using a template we provide) which is the officially recommended approach
14:22:29 <rm_work> but is what everyone is saying is an unacceptable user experience
14:22:40 <rm_work> (I don't disagree that it is quite cumbersome for the user)
14:22:53 <dougwig> so this sounds like it'll be something that we need horizon solve (and which a lot of projects will need).
14:22:57 <xgerman> I am ok for it to becumbersome when using the CLI
14:22:57 <rm_work> yes
14:23:02 <blogan> say horizon uses a full privelaged token, and it makes setting up trusts simple for a user, wouldn't horizon need some way to know which service account to set a trust up with?
14:23:18 <rm_work> So, I don't know that this is something we have the knowledge to really answer right now, but I want people to be aware of what's going on
14:23:37 <rm_work> blogan: also yes, but we could code that in as part of our plugin maybe?
14:23:40 <samuelbercovici> ok. so the user creates the cer, key and container and afther that, runs the "template...." whicg grants access to neutron services. did you talk with VPNaaS guys on this?
14:23:55 <blogan> rm_work: actually sounds like an admin api type of operation
14:24:02 <rm_work> samuelbercovici: not yet, I only got this far in the process of understanding this yesterday afternoon
14:24:27 <rm_work> blogan: erg. yeah
14:24:52 <rm_work> so, the *original* original plan was to just straight up have the Neutron service account be a "god account"
14:25:01 <rm_work> and we could just read data willy-nilly
14:25:13 <rm_work> but that's actually scary enough that i'd never want to see it in production
14:25:13 <xgerman> and why did that fail?
14:25:16 <blogan> rm_work: this is probably a bad idea, but what is stopping us from just reusing the token the user passes to lbaas and talking to barbican with that? other than the token expiring and we have no way to talk to barbican later
14:25:26 <samuelbercovici> theoreticaly speaking, the LBaaS horizon module, may have a section used to upload certificates as part of the lb creation, in this case, it may be easier to implement this "authorization" part in there....
14:25:31 <rm_work> blogan: um… the thing you just said is the problem
14:25:42 <balles> rm_work, how is it today? Is neutron admin only admin for Neutron?
14:25:51 <rm_work> balles: yes, I believe so
14:25:58 <blogan> okay so thats the only problem
14:25:59 <rm_work> and possibly on specific other services
14:26:13 <rm_work> blogan: yes.
14:26:57 <rm_work> so the OTHER option is to go all the way back to one of the original alternatives, which is: hijack user token, read data from barbican, store data on the neutron-service-account
14:27:02 <rm_work> (back in Barbican)
14:27:05 <rm_work> the shadow-copy thing
14:27:17 <dougwig> that's a lot to digest at 8am.  :)  i assume you will be following up with the horizon guys and coming up with a plan?
14:27:18 <rm_work> that would stop us from needed to ever retain access to the user's data
14:27:23 <rm_work> dougwig: that's the idea
14:27:34 <samuelbercovici> rm_work: this is worse.
14:27:40 <rm_work> samuelbercovici: i agree
14:27:58 <samuelbercovici> if we wanted to store such data in neutron, we would not be jumping through such hoops
14:28:09 <rm_work> samuelbercovici: i mean, we'd be storing it in Barbican again
14:28:16 <rm_work> samuelbercovici: just, using our service account
14:28:31 <rm_work> but yeah, it's not ideal either
14:28:32 <xgerman> Having a PKI is exactly the reason we don't ewant copies
14:28:35 <johnsom> I don't like the idea of duplicating the certs
14:28:43 <xgerman> +1
14:28:49 <rm_work> I hope people realize I'm still not advocating this
14:28:51 <rm_work> :P
14:28:55 <rm_work> anyway
14:28:58 <samuelbercovici> yep, i do not like this
14:29:01 <blogan> quit advocating it
14:29:07 <rm_work> I just wanted to get people on the same page
14:29:11 <dougwig> ok, let's circle back to this next week (or the ML) when you get more info on the user experience
14:29:17 <rm_work> I don't think we can solve this with discussion right now
14:29:28 <xgerman> nope
14:29:42 <rm_work> but if anyone thinks of anything… let me know :)
14:30:01 <rm_work> keep this tumbling in your subconscious :)
14:30:03 <samuelbercovici> and to me it has the same problem as geting authorized to acces the data. if the attack vectos is by jeoperdizing the neutron service account, than both solution will have similar cosequences
14:30:09 <balles> rm_work, I appreciate you bringing this up for discussions. Has this been on the ML already?  I am behind on my emails
14:30:29 <rm_work> balles: no, I did't get it "finished" so I never sent it out
14:30:34 <rm_work> I may send our a brief summary of this
14:30:36 <rm_work> today
14:30:46 <rm_work> even though it's still not a finished proposal
14:31:04 <vivek-ebay> >> I assume this is not specific to LBaaS and should be a common problem. What does Barbican guys suggest ?
14:31:07 <balles> Ok I am going to ask Guang from our keystone teamto chime in on this thread. He had some ideas around Truts
14:31:23 <rm_work> vivek-ebay: the only idea they had so far was mentioning the Postern project
14:31:30 <rm_work> balles: ok, thanks
14:31:37 <dougwig> let's move on, and continue this next week or on the ML.  good stuff, rm_work
14:31:44 <balles> vivek-ebay, I agree with you especially the other advanced services
14:31:48 <rm_work> dougwig: yeah, didn't mean to take *half the meeting* :P
14:31:50 <samuelbercovici> does babican has similar notion of also including the node from which the information is requested (same as ssh)? in this case, you can only get the information using neutron user but also only if it is from the neutron(s) api nodes
14:32:16 <dougwig> rm_work: it's good, there wasn't anything else of substance on the agenda.  :)
14:32:20 <rm_work> samuelbercovici: it might be possible to do this from their RBAC policy? MAYBE? But it is not a native concept
14:32:54 <dougwig> ok, and now for a less contentious topic...
14:32:55 <dougwig> #topic Incubator update
14:33:06 <rm_work> samuelbercovici: there is something coming down the pipe for more granularly scoped keystone trusts, but it isn't here yet
14:33:09 <dougwig> mestery, anything new to report?
14:33:10 <balles> samuelbercovici, In our deployment we have certs all over the place. I believe a lot of our security is added when we deploy the services as part of our cloud
14:33:37 <balles> the same with username/password It is all encrypted
14:33:56 <mestery> dougwig: Only that markmcclain and I hope to get it rolling this week again. We were focusing on FFE BPs, but the gate queue is now at 30+ hours so ... :(
14:34:13 <balles> dougwig, I had the same question :-) I am assuming you mean around the incubator thingy
14:34:18 <rm_work> mestery: do you guys operate on Valve Time? :P
14:34:30 <mestery> rm_work: Something like that I think ;)
14:34:42 <rm_work> (for reference: https://developer.valvesoftware.com/wiki/Valve_Time )
14:34:46 <rm_work> mestery: :P
14:34:46 <blogan> its a combination of valve and blizzard time
14:34:55 <TrevorV> lols at rm_work
14:34:58 <samuelbercovici> i guess it was "Destiny" ;-)
14:35:12 <rm_work> heh
14:35:12 <mestery> Honestly, I apologize for how long this has all taken, we're doing our best here.
14:35:22 <rm_work> mestery: yeah, all in good humor :)
14:35:23 <balles> mestery, What's FFE?
14:35:25 <mestery> Yesterday we spent a few hours looking at a huge spike in neutron full job failures
14:35:29 <mestery> Which ended up being a nova patch
14:35:33 <mestery> But the finger was pointed at neutron first :)
14:35:38 <mestery> FFE == Feature Freeze Exception
14:35:41 <rm_work> that's always fun <_<
14:35:42 <mestery> BPs which got on are due by tomorrow
14:35:44 <mestery> rm_work: ++
14:36:08 <dougwig> look at the link that opened the meeting for a list of rc1/ffe blueprints that need reviewer eyeballs.
14:36:34 <mestery> dougwig: ++ and thanks!
14:37:11 <dougwig> #topic Open Discussion
14:37:33 <balles> mestery, it is clear to me that you guys need to delegate "dev-core" power to the incubated Neutron projects
14:37:34 <balles> otherwise you will continue to be bottlenecks
14:37:35 <dougwig> anything else to discuss today?
14:37:48 <mestery> balles: :)
14:38:23 <jorgem> I think he agreed with you ;)
14:38:59 <dougwig> there's been a long discussion from the nova team on the ML about that, and kyle has made a few appearances.  it's worth reading.
14:39:25 <blogan> yep
14:39:30 <balles> dougwig, thanks for the pointer. I will read it after the IRC is done
14:39:58 <dougwig> #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html
14:40:05 <samuelbercovici> on another matter: summit Paris talks. Are all the people patricipating in LBaaS v2 talk planning to attend?
14:40:24 <vivek-ebay> are voting results out ?
14:40:28 <samuelbercovici> yes
14:40:33 <blogan> samuelbercovici: as of now, yes, but could be subject to change
14:40:41 <dougwig> samuelbercovici: yes
14:40:47 <dougwig> vivek-ebay: emails were sent out with results
14:40:51 <blogan> and its totally out of my control if it does cahnge
14:41:04 <vivek-ebay> can we please summarize lbaas selections ?
14:41:12 <dougwig> blogan: if you're not there, we will blame all warts on you and rackspace.
14:41:16 <vivek-ebay> which topics got selected
14:41:18 <sbalukoff> samuelbercovici: I'll definitely be there.
14:41:22 <balles> blogan, This is great news! you guys will be at the summit
14:41:53 <rm_work> balles: hopefully, yes, but we will see what the next month or so brings
14:41:58 <samuelbercovici> #link https://openstacksummitnovember2014paris.sched.org/
14:41:59 <balles> The Octavia talk  didn't get selected :-(
14:42:13 <vivek-ebay> We at ebay missed submitting topics for talks due to internal firefight. We had some great stuff to showcase.
14:42:19 <blogan> balles: not all of us but some of us, though some things have come up that lead me to believe all or most that were going may not be now, but I won't know until tomorrow probably
14:42:26 <rm_work> vivek-ebay: :(
14:42:42 <balles> blogan, Crossing my fingers for you guys
14:42:45 <rm_work> blogan: you think tomorrow? :P
14:42:46 <blogan> balles: i would hav ebeen surprised if it did, no one knows what it is
14:43:10 <vivek-ebay> we got miss by few days. Requested exceptions from core...didn't got :(
14:43:13 <blogan> rm_work: yes, through the grapevine
14:43:15 <balles> blogan,  :) The HP reviewers commented that ti was more a design session topic
14:43:22 <rm_work> blogan / balles: yeah, it's sad no one knows what it is so it doesn't get voted on, so no talk, so no one knows what it is :P
14:43:31 <sbalukoff> vivek-ebay: That's too bad, eh.
14:43:54 <blogan> time to put that HP marketing power behind Octavia, super bowl commercials
14:44:02 <samuelbercovici> vivek-ebay: is there still the notion of "flash talks"?
14:44:04 <balles> Did we get more than one talk? Sam & co. 's LBaaS V2. Anything else
14:44:13 <vivek-ebay> yes, 10 mins
14:44:17 <rm_work> HP Hellion: now with the power of Octavia! *queue roman gods B footage*
14:44:19 <vivek-ebay> not enough...
14:44:20 <blogan> balles: i dont believe so
14:44:38 <samuelbercovici> I also do: https://openstacksummitnovember2014paris.sched.org/event/2b85b682ccaf3a5961e463b61e2403f8#.VBG1TvmSzY8
14:45:15 <blogan> ah interesting, ill attend that one if I do go
14:46:04 <rm_work> If I go, I'll be doing a lightning talk on Barbican service integration… assuming it eventually works out :P
14:46:17 <johnsom> rm_work That is funny
14:46:30 <blogan> rm_work: I have a feeling that talk would need more than 10 mins
14:46:32 <samuelbercovici> rm_work: eventualy might weight a kilo
14:46:32 <dougwig> anything else anyone wants to discuss?
14:46:36 <rm_work> lol
14:47:04 <xgerman> we need Octavia stickers and T-Shirts :-)
14:47:10 <rm_work> xgerman: ah, yes
14:47:19 <blogan> i would like to discuss...bears
14:47:22 <rm_work> we can have a little Amphora as part of our logo
14:47:32 <dougwig> blogan: black or grizzly?
14:47:36 * blogan vomits into an amphora
14:47:40 <VijayB_> samuelbercovici: lol
14:47:43 <rm_work> maybe an Amphora on a scale? :P
14:47:52 <xgerman> with bears to make blogan happy
14:48:08 <blogan> if bears came along and smashed a room full of amphorae, that'd be great
14:48:08 <rm_work> alright, discussion has sufficiently devolved ^_^
14:48:12 <blogan> a great marketing ploy as well
14:48:23 <dougwig> i'm sensing an imminent endmeeting....  :)
14:48:27 <sbalukoff> xgerman: Totally!
14:48:32 <blogan> this is highly relevant
14:48:46 * rm_work gets out his Photoshop hat
14:48:48 <blogan> end it dougwig
14:48:55 <dougwig> #endmeeting