18:02:20 <dolphm> #startmeeting keystone
18:02:21 <openstack> Meeting started Tue Aug 13 18:02:20 2013 UTC and is due to finish in 60 minutes.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:24 <openstack> The meeting name has been set to 'keystone'
18:02:36 <dolphm> #topic FeatureProposalFreeze
18:02:37 <ayoung> I sent him email, but he is in the Ukraine, so it is pretty late in the day for him
18:02:48 <dolphm> #link http://lists.openstack.org/pipermail/openstack-dev/2013-August/013278.html
18:02:53 <dolphm> #link https://wiki.openstack.org/wiki/FeatureProposalFreeze
18:03:12 <dolphm> hopefully this isn't a surprise because i already spammed everyone about this, but read the above if you haven't ^
18:03:29 <ayoung> Looks good here.
18:03:36 <topol> hi
18:03:37 <morganfainberg> makes sense to me
18:03:46 <ayoung> dolphm, format date is...?
18:03:51 <fabiog> hi
18:03:51 <ayoung> formal
18:03:52 <dolphm> i don't expect any surprises, but wanted to bring everyone's attention to it again anyway :)
18:03:57 <stevemar> dolphm: i think the people who need to know about it, know about it
18:04:11 <bknudson> we're already drowned in code reviews
18:04:15 <dolphm> bknudson: ++
18:04:18 <dolphm> #topic morganfainberg
18:04:25 <dolphm> thankfully we have a new core reviewer to help with that :)
18:04:29 <morganfainberg> yay!
18:04:31 <bknudson> awesome!
18:04:32 <lbragstad> +1
18:04:33 <dolphm> official welcome to morganfainberg :)
18:04:33 <henrynash> congrats!
18:04:34 <morganfainberg> i've been trying. :)
18:04:35 <stevemar> +1
18:04:37 <morganfainberg> thanks
18:04:41 <fabiog> congrats!
18:04:47 <ayoung> dolphm, is there some other launchpad setting he needs in order to assign bugs to people?
18:05:01 <topol> congrats!!! Very wel deserved
18:05:15 <gyee> morganfainberg, you are buying beer on the next summit?
18:05:21 <dolphm> morganfainberg: ayoung: not sure, poke me after the meeting if something is wrong with lp
18:05:23 <morganfainberg> gyee… hrmm… we shall see.
18:05:29 <dolphm> yay
18:05:36 <dolphm> #action morganfainberg to buy everyone beer
18:05:40 <gyee> ha
18:05:43 <dolphm> #topic critical issues
18:05:54 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1210590
18:05:57 <uvirtbot> Launchpad bug 1210590 in keystone "Split backend crashes with AttributeError" [Critical,Confirmed]
18:06:01 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1211445
18:06:03 <uvirtbot> Launchpad bug 1211445 in keystone "deleting an unassigned role causes 500" [Critical,Confirmed]
18:06:10 <dolphm> these are two nasty ones on v3 that i've seen reported a couple times
18:06:25 <henrynash> dolphmL I can't seem to reproduce…tried what you di and it worked
18:07:19 <henrynash> dolphm: at least could not reproduce #link https://bugs.launchpad.net/keystone/+bug/1210590
18:07:19 <dolphm> henrynash: hmm... i'll try to reproduce once more
18:07:21 <uvirtbot> Launchpad bug 1210590 in keystone "Split backend crashes with AttributeError" [Critical,Confirmed]
18:07:33 <henrynash> dolphm: is you db migrated or new?
18:07:56 <dolphm> henrynash: brand new
18:08:03 <henrynash> dolphm: hmmm
18:08:10 <ayoung> henrynash, let me know if you want a hand with either
18:08:21 <dolphm> henrynash: i have the steps to repro mostly scripted for a different bug
18:08:26 <henrynash> dollphm: and we unit test exactly the url you tried
18:08:50 <henrynash> dolphm: ok…if you can shed any more light…I'll get in and debug
18:08:55 <dolphm> henrynash: will do
18:09:08 <bknudson> the role exists but it's not assigned?
18:09:17 <ayoung> dolphm, suspect that the differenc might be the LDAP backend.  THe unicode thing leads me to think it might be a Directory server issue
18:09:37 <dolphm> bknudson: yeah, new user, new project, new role ... and create a role assignment of the three -> 500
18:09:42 <morganfainberg> dolphm ayoung: wasn't there a recent unicode relate ldap thing?
18:09:53 <dolphm> morganfainberg: i'm not aware of one?
18:10:02 <morganfainberg> dolphm: i might be thinking internal code
18:10:04 <henrynash> bknduson: so I made a change where the list of roles for a user/probject pair became a list of dicts instead
18:10:08 <morganfainberg> dolphm: i'll check
18:10:11 <bknudson> spzala had a work in progress for unicode
18:10:21 <morganfainberg> bknudson: ah that might be what i saw.
18:10:29 <henrynash> my guess is that I missed something somewhere and something is still returning an old style list
18:10:33 <ayoung> morganfainberg, yes, there is a well known issue.
18:10:50 <ayoung> https://bugs.launchpad.net/keystone/+bug/1172106
18:10:53 <uvirtbot> Launchpad bug 1172106 in keystone "Live LDAP tests fail on unicode names" [Medium,In progress]
18:10:54 <dolphm> could use some LDAP-expert feedback on bug 1211643
18:10:56 <uvirtbot> Launchpad bug 1211643 in keystone "Update user name failed with LDAP back end by CLI" [Undecided,In progress] https://launchpad.net/bugs/1211643
18:11:07 <dolphm> maybe that needs to be configurable
18:11:09 <spzala> yep, it's specific to the LDAP though
18:11:32 <bknudson> it's strange we don't allow change name in ldap backend.
18:11:35 <spzala> ayoung: thanks for the bug link
18:11:50 <bknudson> since it's not like you can't change the name attribute in an entry.
18:12:28 <ayoung> dolphm, assign any ldap bugs to me
18:13:06 <gyee> you should be able to update user name
18:13:20 <gyee> sounds like a bug in the code
18:13:52 <gyee> unless your LDAP ACL is configure to have it read only
18:13:54 <bknudson> let them try to change the name and if the ldap server doesn't like it it can reject the request.
18:14:03 <dolphm> gyee: it was expected behavior when it was implemented
18:14:09 <dolphm> gyee: i'd be careful about suddenly allowing it
18:14:48 <dolphm> bknudson: hmm... that's probably a safe approach
18:15:02 <bknudson> sql could do the same thing
18:15:14 <gyee> dolphm, you mean we don't allow updating user name?
18:15:19 <bknudson> maybe ldap doesn't check for duplicates?
18:15:20 <ayoung> username is typically modifiable, so long as the userid is immutable.  Should be enforced by ACLs.
18:15:22 <dolphm> gyee: historically, no
18:15:26 <ayoung> so, yeah, lets allow it.
18:15:30 <morganfainberg> bknudson: depends on schema
18:15:45 <morganfainberg> bknudson: and acls
18:16:17 <ayoung> dolphm, is that a general rule across all backends?  If so, then the bug can be closed notabug
18:16:26 <dolphm> continue this discussion in the bug / review?
18:16:29 <gyee> ok then, we need to distinguished what we can do versus what LDAP can do
18:16:37 <ayoung> dolphm, agreed
18:16:47 <dolphm> this isn't high priority, just wanted to bring some attention to it
18:16:51 <dolphm> #link https://review.openstack.org/#/c/41603/
18:17:04 <dolphm> #topic pagination
18:17:20 <gyee> :)
18:17:30 <dolphm> #link http://lists.openstack.org/pipermail/openstack-dev/2013-August/013493.html
18:17:32 <henrynash> ok, so quite lively ML discussion going on
18:17:42 <ayoung> So I think we need pagination short term, but we should be wary of depending on it over the long.  LDAP and pagination is a bad mix
18:17:57 <ayoung> listing all users is also a bad practice.
18:17:59 <morganfainberg> ayoung: +1
18:18:09 <gyee> lets pass the query parameters into the drivers and let the drivers optimize
18:18:45 <henrynash> so it's worth reading the ML trail
18:18:54 <ayoung> dolphm, I opened a handful of related wishlist items  yesterdat.
18:19:04 <gyee> would be hard to standardize if drivers don't speak the same language
18:19:10 <dolphm> ayoung: use google as an example :) you can't go to google.com and see "all search results" with a blank query string
18:19:17 <henrynash> Jay certainly advocating we support the same thing that other projects do, i.e. limit/marker
18:19:22 <ayoung> dolphm, good point
18:19:47 <bknudson> I think it would be best if we followed what other OS projects are doing.
18:19:58 <henrynash> Is there a reason we WOULDN'T do what the other projects have done?
18:20:06 <morganfainberg> bknudson: at the very least it makes it easier for developers to interact with keystone then
18:20:19 <ayoung> http://bit.ly/168qd2d
18:20:27 <bknudson> should be able to use shared code to do paging.
18:20:29 <ayoung> those are new and wishlist bugs
18:20:33 <dolphm> sort key and sort order are particularly important to have consistent, even if we don't expose that to the api yet
18:20:43 <gyee> bknudson, we don't follow, we lead :)
18:20:50 <henrynash> Here's my most recent ML post:
18:20:51 <ayoung> https://bugs.launchpad.net/keystone/+bug/1211582
18:20:51 <henrynash> 1) Support 'limit' and 'marker' (as opposed to 'page', 'page_szie', or anything else).  These would be standard, independent of what backing store keystone was using.  If neither are included in the url, then we return the first N entires, where N is defined by the cloud provider.  This ensures that for at least smaller deployments, non-pagination aware clients still work.  If either 'limit' or 'marker' are specified, then we pagi
18:20:51 <henrynash> down into the driver layer wherever possible to ensure efficiency (some drivers may not be able to support pagination, hence we will do this, inefficiently, at a higher layer)
18:20:52 <henrynash> 2) If we are paginating at the driver level, we must, by definition, be doing all the filtering down there as well (otherwise it all gets mucked)
18:20:53 <henrynash> 3) We should look at supporting the other standard options (sort order etc.), but irrespective of that, by definition, we must ensure that we any driver that is paginating must be getting is entries back in a consistent order (otherwise, again, pagination doesn't work reliably)
18:20:54 <uvirtbot> Launchpad bug 1211582 in keystone "Filter user list by partial attributes" [Wishlist,New]
18:21:27 <bknudson> btw - the identity API spec doesn't have page / page_size anymore... I submitted a change to remove them since they weren't implemented.
18:21:52 <bknudson> can always add them back in again.
18:21:59 <henrynash> bknudson…has that gone in…I checked earlier today and they were still there...
18:22:04 <morganfainberg> yeah, better to add them when we have support.
18:22:04 <ayoung> let me, once again, reiterate the LDAP specific concerns,  1)  limit the number of entries returnsed.  2) LDAP does not guarantee order, which means paging requires a cursor.  3) Cursors don't scale
18:22:15 <bknudson> https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md doesn't have them
18:22:20 <dolphm> #link https://review.openstack.org/#/c/39828/
18:22:37 <bknudson> ldap servers can have their own limit on results anyways
18:22:56 <henrynash> ayoung: so that's fine, we just return N items as I describe
18:23:02 <bknudson> I think Active Directory has paging of member attribute.
18:23:28 <ayoung> bknudson, yeah, but we should also allow Keystone to specify the limit.  See the problem with the HP ED taking an hour+ to return
18:24:14 <henrynash> ayoung: agreed, we should have a keystone limit
18:24:16 <gyee> ayoung, that's because HP ED is miss configured :)
18:24:24 <gyee> misconfigured
18:24:27 <ayoung> --sizeLimit 200
18:24:41 <ayoung> option value for all LDAP queries, I think?
18:24:43 <dolphm> lol
18:24:48 <morganfainberg> gyee: right, but regardless, we should limit (or optionally be able to provide a limit) to solve that.
18:25:12 <gyee> sure, I am fine with having limit on the client-side
18:25:15 <morganfainberg> s/solve/make keystone better regardless of misconfiguration
18:25:18 <morganfainberg> of the server
18:25:25 <gyee> LDAP servers usually don't take hours and return you thousands of entries
18:25:35 <gyee> if configured correctly
18:25:44 <henrynash> so are there any objections to my most recent proposal…it does seem to cover all the above issues?
18:25:50 <ayoung> on paging, there was some question about the implementation.  Are we just punting on it?
18:25:59 <gyee> LDAP, by design, is for *fast lookup*
18:26:21 <rcrit> should there be a knob for ldap search time limit though?
18:26:41 <ayoung> rcrit, it can be optional, too
18:26:45 <rcrit> at least with 389-ds there is one, even if the user doesn't set it themself
18:26:52 <ayoung> rcrit, file that as a wishlist bug
18:27:03 <rcrit> I don't wish it, just asking :-)
18:27:08 <ayoung> or tag it on to the limit
18:27:26 <ayoung> rcrit, I know better than that....
18:27:32 <bknudson> why just ldap search? can't sql query take a long time, too?
18:27:49 <ayoung> bknudson, I think because timeout is a standard part of an ldap query
18:28:00 <gyee> bknudson, if an LDAP query takes a long time, something is misconfigured
18:28:06 <ayoung> pretty sure SQL has not such standard
18:28:08 <rcrit> it's a server-side thing.
18:28:17 <rcrit> I think, anyway
18:28:27 <ayoung> ldapsearch --hostname localhost -p 1389 --baseDn 'uid=user.0,ou=people,dc=example,dc=com' \
18:28:27 <ayoung> --searchScope base --sizeLimit 1 --timeLimit 1 '(&)' @inetOrgPerson
18:28:46 <bknudson> keystone doesn't have any control over the ldap server settings.
18:29:05 <ayoung> bknudson, no, but it can chose to use server side controls if they are available
18:29:06 <dolphm> bknudson: but we should totally change that
18:29:15 <dolphm> bknudson: keystone-manage configure_ldap_correctly
18:29:25 <henrynash> proposal: I'll create an etherpad that contains my most recent proposal from the ML (that is essentially to do things the way other projects do), link it to the bp and let others comment?
18:29:27 <gyee> damn straight
18:29:45 <topol> henrynash +1
18:29:51 <ayoung> bknudson, there is already something like that for AD, where it can make use of a control if the server supports it.  I'd have to dig up the commit.  Was probably done by CERN
18:30:02 <dolphm> henrynash: the way other projects do it is a great approach for SQL
18:30:07 <ayoung> henrynash, blueprint, link to the wishlist bugs
18:30:36 <henrynash> dolphm: I believe that my proposal at least ensures that we don't get long delays from LDAP
18:31:05 <henrynash> ayoung: this isn't a wishlst, we are implementing  a solution for H3
18:31:08 <bknudson> ldap.search_ext_s has a timeout= parameter.
18:31:20 <ayoung> henrynash, then up the priority of the bug
18:31:38 <bknudson> and can pass server and client controls if that's an option.
18:32:43 <ayoung> OK, I think we have an approach.Just please add me as a review on any LDAP changes.  I'll try to keep an eye out for them.  make sure LDAP is in the patch description
18:32:53 <gyee> meee 2
18:33:02 <henrynash> ayoung, gyee: ok!
18:33:23 <henrynash> dolphm: probably time for a new topic
18:33:26 <bknudson> what's the marker parameter? a value from the next entry?
18:33:53 <gyee> marker is suppose to be the last entry from the previous batch
18:33:54 <dolphm> henrynash: ++
18:34:01 <topol> henrynash I will be happy to review as well
18:34:03 <bknudson> so like uid?
18:34:09 <henrynash> bknudson: yep
18:34:10 <dolphm> ayoung: skip common client auth?
18:34:15 <ayoung> dolphm, no
18:34:25 <dolphm> #topic common client auth
18:34:25 <ayoung> just want people to know:
18:34:30 <dolphm> #link https://review.openstack.org/#/c/28043/
18:34:38 <henrynash> (ok, I have to duck out….sorry folks…., be back on later)
18:34:43 <ayoung> I submite a revert review for the osl change to auth client
18:34:44 <dolphm> giant patch
18:34:55 <ayoung> https://review.openstack.org/#/c/41578/
18:35:12 <bknudson> who reviewed the original patch in oslo-incubator?
18:35:14 <ayoung> and I talked with aababilov
18:35:24 <ayoung> we are going to work to get this integrated directly into the keystone client
18:35:41 <ayoung> jamielennox is aware and has responded to him as well.  This should be a good approach
18:36:18 <bknudson> I guess we can move it oslo-incubator after it's been used in keystoneclient if that's necessary
18:36:27 <dolphm> ayoung: i'm in favor of the notion... if absolutely nothing else, it's more likely we'll have more security-sensitive eyes on the code that way
18:36:27 <ayoung> bknudson, doesn't really matter.  I don't think they were aware that this was supposed to be a Keystone thing, too
18:36:28 <bknudson> but other clients should be able to import keystoneclient?
18:36:33 <ayoung> bknudson, no
18:36:44 <ayoung> bknudson, other clients should pull in keystone client as a library
18:36:56 <ayoung> won't go into oslo
18:37:13 <ayoung> bknudson, "but other clients should be able to import keystoneclient?" yes
18:37:53 <morganfainberg> much easier to keep it "correct" if keystoneclient owns it and it's not in oslo
18:38:00 <dolphm> ++
18:38:07 <morganfainberg> it means we wont run into projects lagging in sync
18:38:19 <morganfainberg> and causing auth issues.
18:38:21 <lbragstad> morganfainberg: +1
18:38:25 <ayoung> we may decide we want to break up keystone client over time.  I could easily see it as:  command line, keystone common library, keystone client library, and middleware.
18:38:29 <dolphm> morganfainberg: we need to make it stupid easy for other projects to consume us, which is NOT the case today :(
18:38:39 <morganfainberg> dolphm: yes, that is related to the topic.
18:38:40 <bknudson> different installs might have different levels of the client, and now we have to be very careful of backwards compatibility.
18:38:46 <morganfainberg> dolphm: and ++
18:39:08 <dolphm> everything from auth options -> client side token management -> authenticating requests to other services
18:39:12 <morganfainberg> bknudson: i think we are already having to watch closely on that wrt auth_token.
18:39:19 <ayoung> it would be nice if we could build that out of a single git repo.
18:39:39 <gyee> dolphm, like secured by default? which does nothing :)
18:39:42 <cody-somerville> Does shared common client auth also include the service catalog stuff?
18:39:51 <ayoung> cody-somerville, yes
18:40:11 <ayoung> cody-somerville, it is implicit that when you get a token you get the service catalog with it.
18:41:05 <cody-somerville> because it's broken in keystoneclient trunk currently - region_name get passed to AccessInfo (which would pass it on to ServiceCatalog if it was) and thus region_name is ignored.
18:41:28 <cody-somerville> and everyone seems to do things like url_for differently.
18:41:36 <ayoung> cody-somerville, file it in launchpad, or if it is filed, please link the bug
18:41:48 <cody-somerville> I haven't filed it yet but will be doing so today.
18:41:52 <gyee> service catalog needs a bit more work
18:42:03 <dolphm> the way we expose the service catalog is sad
18:42:07 <ayoung> cody-somerville, there was an expired review for region work,  which jaypipes is planing on resubmitting as an extension.
18:42:13 <cody-somerville> oops, I typoed: region_name *does not* get passed to AccessInfo
18:42:15 <ayoung> cody-somerville, thanks
18:42:25 <cody-somerville> +1
18:42:27 <gyee> dolphm, yeah, we need to go back to the drawing board on this one
18:42:45 <gyee> like how to facilitate API versioned urls
18:43:47 <cody-somerville> I'll note that it would probably be much appreciated if you guys kept the heat people appraised of any changes here
18:43:55 <ayoung> cody-somerville, will do
18:44:22 <bknudson> eventually we want all clients to use the common auth stuff
18:44:24 <dolphm> #topic open discussion
18:44:45 <bknudson> which means someone has to go through all the other clients and update them to use common auth
18:44:46 <dolphm> there's some high priority code reviews on the agenda --
18:44:56 <dolphm> #link https://review.openstack.org/#/c/39530/
18:45:02 <dolphm> #link https://review.openstack.org/#/c/38308/
18:45:07 <dolphm> #link https://review.openstack.org/#/c/40692/5
18:45:36 <morganfainberg> Ahh good, KDS has a new patchset.
18:45:39 <JoeHazzers> also, is there anything happening regarding external authentication methods?
18:45:54 <stevemar> #link https://review.openstack.org/#/c/29130/ dolphm, this one too :)
18:46:03 <ayoung> morganfainberg, the API does, yeah.  simo will  sync the code to API once it is clear there is not too much churn
18:46:12 <morganfainberg> ayoung: yep, that was what i meant
18:46:57 <gyee> code reviews from here on out
18:47:04 <ayoung> stevemar, I think oauth is close
18:47:16 <stevemar> ayoung, yay
18:47:22 <morganfainberg> stevemar: yeah, it's looking really good.
18:47:32 <gyee> JoeHazzers, what do you have in mind?
18:47:33 <topol> stevemar +1
18:47:53 <ayoung> I'll give it another look.  I assume no major changes since last I looked.  I withdraw the requests for making access tokensi nto Keystone tokens....although it might be worth revisint that in the future.
18:48:07 <ayoung> revisiting
18:48:08 <gyee> oauth ftw
18:48:19 <dolphm> ayoung: that reminds me... https://gist.github.com/dolph/6198529
18:48:26 <JoeHazzers> gyee: i know someone who wants to integrate kerberos, x509 and other authentication methods with keystone, such that the client and server (if running under say apache) can negotiate and authenticate via other methods than a simple username and password
18:48:44 <ayoung> dolphm, neat
18:48:46 <dolphm> ayoung: my first pass was with PKI-based oauth access_keys ... i switched to AES in the current gist, but will be switching back
18:48:49 <morganfainberg> dolphm: thats cool.
18:48:58 <ayoung> JoeHazzers, already done in Apache HTTPD
18:49:12 <ayoung> JoeHazzers, would not recommend trying to do it in Eventlet
18:49:14 <dolphm> basically the oauth secret is encrypted into the access key along with basic authz attributes
18:49:29 <JoeHazzers> yes, but how does client discovery or knowledge of these methods work?
18:50:02 <dolphm> project_id, role_names, secret = verify_access_key(access_key)
18:50:03 <ayoung> JoeHazzers, we are working on an extension for that.  THe kent federation review is going to split that off into its own extension
18:50:16 <JoeHazzers> okay!
18:51:37 <ayoung> JoeHazzers, the review is here: https://review.openstack.org/#/c/39499/ see the first two items on the list:  listing IdPs and listing protocols supported.
18:52:09 <ayoung> dolphm, should that piece end up part of keystone client?
18:52:35 <ayoung> One other review:   https://review.openstack.org/#/c/41471/
18:53:00 <morganfainberg> ayoung: i am checking on that FK constraint right now
18:53:20 <morganfainberg> I don't see it in the DB, but I'm going to 2x check to see what is going on.
18:54:08 <morganfainberg> trying it from a clean slate.
18:54:18 <dolphm> ayoung: yeah, parts of it
18:54:56 <dolphm> ayoung: keystoneclient doesn't have any business creating access tokens, but keystoneclient should be able to verify them (a la keystoneclient.common.cms.verify_token())
18:55:11 <ayoung> dolphm, yeah, that is what I was thinking
18:55:43 <dolphm> ayoung: keystoneclient.contrib.oauth.verify_access_token() or something?
18:55:48 <dolphm> oauth1*
18:56:52 <ayoung> 4 minutes.  Any last burning topics?
18:58:03 <gyee> who's going to IceHouse summit?
18:58:12 <morganfainberg> I'll be there
18:58:22 <topol> I plan on being there
18:58:24 <ayoung> I'll be there.
18:58:29 <gyee> same here
18:58:33 <stevemar> gyee: hopefully!
18:58:43 <ayoung> jamielennox and simo from RH as well representing IdM
18:58:49 <dolphm> gyee: o/
18:58:55 <topol> ayoung, a much better answer than last time
18:59:07 <ayoung> topol, I even have a book on Cantonese
18:59:21 <topol> ayoung, wow
18:59:21 <gyee> ayoung, I can teach the good stuff :)
18:59:23 <morganfainberg> ayoung: hehe
18:59:35 <ayoung> 我迷路了，請幫我
18:59:39 <topol> Im just gonna follow gyee everywhere
18:59:42 <stevemar> hehe
18:59:47 <stevemar> nice one ayoung
18:59:48 <morganfainberg> topol: that is a good idea
18:59:56 <topol> gyee, where we going to dinner. gyee what is this on the menu
19:00:16 <gyee> topol, I'll let you know what I ordered, after dinner :)
19:00:32 <ayoung> 我的氣墊船​​鰻魚
19:00:38 <topol> gyee, I've fallen for that before
19:00:55 <dolphm> #endmeeting