18:01:11 <heckj> #startmeeting keystone
18:01:12 <openstack> Meeting started Tue Oct  2 18:01:11 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:14 <openstack> The meeting name has been set to 'keystone'
18:01:21 <ayoung> o/
18:01:22 <heckj> #topic agenda at http://wiki.openstack.org/Meetings/KeystoneMeeting
18:01:29 <heckj> ola guys
18:01:32 <heckj> any gyee? others?
18:02:09 <ayoung> ain't nobody here but us chickens
18:03:11 <heckj> heh
18:03:21 <heckj> #topic summit session
18:03:38 <heckj> We've got three hours open in our sessions so far - not feeling like I need to fill them, but FYI
18:03:47 <heckj> Can you two see: http://summit.openstack.org/cfp/topic/6
18:03:48 <heckj> ?
18:04:17 <dolphm> heckj: forbidden
18:04:24 <heckj> Ah well, fraid fo that
18:04:30 <heckj> It's the approved list for the summit
18:04:56 <heckj> I'll make a screenshot and send to you two so you can see that status
18:05:13 <dolphm> heckj: i can see this http://summit.openstack.org/
18:05:32 <dolphm> heckj: which shows unreviewed/preapproved/incomplete .. i just can't filter by topic?
18:05:54 <dolphm> heckj: i see 6 keystone sessions on that
18:05:56 <heckj> Spect so - I'm not entirely sure how permissions and such are set up with that app
18:06:09 <heckj> #topic bugs vs blueprints for feature work
18:06:12 <heckj> So...
18:06:58 <heckj> a couple of release meetings ago, ttx started getting on us for having a large number of "high" bugs in our project. Looking through, some of those bugs are really "work items", and some aren't going to be resolved until other larger work items are complete (i.e. the things that need a V3 API implementation).
18:07:19 <heckj> For the pure work items, I thought about trying to get us using blueprints more extensively.
18:07:26 <heckj> Figured I'd ask you two what you though.
18:07:54 <heckj> Jose, for example, opened a series of bugs for feature-improvements on LDAP - maybe that should've been in a blueprint instead of bugs.
18:07:57 <dolphm> i think launchpad's blueprints are a little broken as a system, but they're more appropriate
18:09:02 <heckj> yeah, I've found lots of restrictions in using blueprints - they seem to be most suitable to large, swatching feature request pieces rather than lots of work items/tasks to accomplish something.
18:09:09 <heckj> ayoung: any opinions or thoughts?
18:09:38 <heckj> I know you have to report up the food chain there regularly with what you've done in Keystone - would using BP more extensively do you any good, or would it be just another annoying system to deal with?
18:10:36 <dolphm> depends on if the PTL is volunteering to completely manage blueprints or if we have to do it ourselves
18:10:42 <ayoung> heckj, in general I agree, but the LDAP bugs do tend to stand alone
18:10:53 <ayoung> each of them is valid in the absense of the others
18:11:22 <heckj> makes sense
18:11:38 <heckj> the only other set of bugs that are really blueprint work is my fault - the implement V3 API stuff
18:11:40 <ayoung> calling them "feature enhancements" is splitting hairs.  Probably more honest to say my original work was proof-of-concept and this is productization
18:12:07 <heckj> Any qualms if I nuke this bugs and leave it to the blueprint to link up reviews?
18:12:17 <heckj> s/this/those/
18:12:33 <dolphm> nope
18:12:37 <heckj> kk
18:12:42 <heckj> #topic feature branch
18:12:48 <heckj> So - feature branch
18:12:56 <heckj> #topic - I'm lying, open discussion
18:13:09 <heckj> feature branch - how are we liking it?
18:13:20 <gyee> \o
18:13:22 <gyee> sorry I am late
18:13:34 <heckj> I'm finding it a little hard to use - to get all the pieces together to see the V3 API all together in a checkout
18:13:45 <ayoung> heckj, I can parse that two ways.  How do we like using a feature branch, or how do we like the way the V3 apis are coming along
18:14:19 <heckj> ayoung: I meant the "how do we like using a feature branch" - process wise, I'm finding it a little tricky to work with
18:14:42 <heckj> I've also been very slow to get reasonable reviews up for that work as well
18:14:44 <dolphm> i broke up some of the commits so they would merge with as few dependencies as possible -- not to make it easy to checkout in one go :-/
18:14:57 <ayoung> But for the first part, I think it is generally OK, except for the way "depends on review X which is outdated/"
18:15:47 <ayoung> the outdated thing seems wonky.
18:16:01 <dolphm> ayoung: how so? outdated doesn't imply a trivial rebase won't resolve it
18:16:19 <ayoung> dolphm, yeah, it just kindof says "don't bother reviewing"  which is wrong
18:16:28 <ayoung> trying to keep track of my tasks.
18:16:34 <dolphm> ayoung: should still certainly be reviewable in isolation
18:17:07 <ayoung> heckj, this one is, I think, needing your input.  https://review.openstack.org/#/c/12106/6
18:17:15 <ayoung> The rest all depend on that
18:17:19 <heckj> kk
18:17:20 <gyee> I agree with ayoung, this outdate/restore thingy is abit confusing
18:17:48 <dolphm> the two week timeout on reviews without activity has been biting me a lot lately
18:18:07 <ayoung> dolphm, should endpoint_id = sql.Column(sql.String(64), nullable=False)  also be a foreign key? in Policy?  If it can't be false...
18:18:11 <heckj> yeah, noticed that -
18:18:19 <heckj> some of that, I'm sure, is my slowness though
18:18:31 <dolphm> ayoung: can't do foreign keys across backend implementations (safely)
18:19:15 * ayoung annoyed by the use of technologies that gut the tools of their most useful features
18:19:23 <ayoung> dolphm, so SQL alchemy is broken?
18:19:42 <gyee> I am not even sure if foreign key work across all sql backends
18:19:45 <dolphm> ayoung: that's a limitation of our architecture -- the desire to plug random combinations of drivers together
18:20:02 <ayoung> I understand if, say, sqlite doesn't support it, but then SQL alchemy should abstract that away
18:20:23 <gyee> ayoung, then we'll have inconsistent enforcement
18:20:29 <dolphm> ayoung: i'm toying with the idea of writing a single, high performance, monolithic sqlalchemy driver that covers all backends
18:20:41 <dolphm> ayoung: and then we can use foreign keys, and cascade deletes and whatnot
18:21:24 <gyee> dolphm, +1
18:21:56 <ayoung> gyee, understood, but that doesn't mean that we should bypass intelligent constriants for the real DBMSs because we have ones that we are using only for testing
18:22:03 <dolphm> ayoung: if that existed, i think it might be possible to rewrite some of the existing drivers to extend it, and say, eliminate foreign keys and perform cascading deletes "manually" -- to then make a bunch of pluggable drivers out of one big driver
18:22:17 <dolphm> ayoung: and then you can mix ldap into ti :P
18:22:21 <ayoung> dolphm, no
18:22:35 <ayoung> we need you to do real work, not tilt at windmills
18:22:43 <ayoung> I assure you, they are not giants
18:23:16 <heckj> ooohh!! windmills!!!
18:23:19 <dolphm> ayoung: lol i think it needs to happen eventually, but if we don't do it, someone else will -- probably to whoever gets bitten first by performance
18:23:21 * heckj gets his horse
18:23:46 <ayoung> better instead for SQLite to ignore with a warning things it hasn't yet implemented, and then to file bugs in its driver
18:24:08 <dolphm> ayoung: i.e. that profile of keystone you sent -- i'd say performance is a known issue with sql, and i don't know how else to address it but write a smarter sql driver for a narrow use case
18:24:28 <ayoung> dolphm, ah,  that.  I think the problem is eventlet
18:24:39 <dolphm> ayoung: how so?
18:24:48 <dolphm> ayoung: our sql query performance is garbage
18:25:00 <ayoung> all SQL requests end up getting serialized, which means others are getting blocked
18:25:07 <heckj> what would probably be most useful is to nail down a benchmark test that we could run to measure and compare - that'll give us hard numbers to work against
18:25:08 <ayoung> I suspect the threading monkey_patch
18:25:21 <ayoung> I think we should benchmark running in apache HTTPD
18:25:39 <ayoung> I think we will be much happier, less work, and on a more secure platform
18:25:57 <dolphm> ayoung: it would help if we didn't have to execute N+1 sql queries to get a list of N items
18:25:58 <heckj> ayoung: I'd like to benchmark in multiple deployment configurations, and even more across the series of changes as we go through development.
18:25:59 <ayoung> We will also get IPv6 support, so my Uncle will be happy
18:26:18 <dolphm> heckj: +1 for benchmark
18:26:48 <dolphm> heckj: i have a keystoneclient script for v3 that might help there
18:27:12 <dolphm> heckj: creates and tears down a bunch of entities
18:27:24 <ayoung> BTW, devstack with Signed tokens is broken.  I've nailed down one issue, but have not yet solved the overall thing.
18:27:48 <dolphm> ayoung: symptoms?
18:27:50 <ayoung> The admin token is 80 characters long.  I had been checking for UUID token length, which is 32 chars long
18:27:53 <heckj> ayoung: well damn
18:28:10 <ayoung> but once I change the length limit to 80, it still fails,
18:28:13 <dolphm> ayoung: lol i told you token length wasn't a good metric
18:28:15 <ayoung> I haven't figured out why
18:28:32 <ayoung> dolphm, and I remember agreeing with you
18:28:39 <dolphm> ayoung: i think you need to try and decipher every token, and if it fails, assume it's not pki
18:28:48 <ayoung> dolphm, I can do something like start the PKI tokens with PKI-
18:29:13 <heckj> ayoung: a hint would make that much more reasonable - like the idea!
18:29:17 <ayoung> as a UUID token is, I think, limited to 0-9A-F
18:29:28 <ayoung> I'll open a ticket for that
18:29:49 <gyee> ayoung, +1 on prefixing
18:30:37 <dolphm> ayoung: correct, since we use .hex... however, hardcoded admin_token values could be anything
18:30:48 <dolphm> ayoung: hardcoded = keystone.conf'd
18:30:55 <dolphm> ayoung: hardconfigured?
18:32:00 <ayoung> dolphm, that is oK,  If they start them with PKI they are going to be treated as PKI tokens.
18:32:40 <ayoung> Chance of that happening unintentionally is vanishingly small enough that I will trust it to a release note
18:32:55 <gyee> or put in a check in the code
18:33:06 <dolphm> gyee: check for what?
18:33:11 <ayoung> anyway,  once I change the length to >80,  it fails, seemingly in the UUID token path.
18:33:20 <gyee> check to make sure admin token is properly prefix
18:33:21 <dolphm> if admin_token[:4] == 'PKI-'  throw a warning?
18:33:32 <gyee> yeah, something like that
18:33:46 <ayoung> gyee, file format?  fall back to online checking if it isnt cms?
18:34:26 <gyee> right, pki tokens are base64 encoded right?
18:34:50 <gyee> if we can't do base64 decode, then we can try the uuid route
18:35:43 <ayoung> https://bugs.launchpad.net/keystone/+bug/1060389
18:35:44 <uvirtbot> Launchpad bug 1060389 in keystone "Non PKI Tokens longer than 32 characters can never be valid" [Undecided,New]
18:35:47 <heckj> unrelated, I spent this past weekend grokking the keystoneclient code - I want to normalize it so that it can be used to auth in all the other clients with a clear internal API
18:35:57 <ayoung> that needs to be fixed before we can throw the switch on tokens to go PKI
18:35:59 <dolphm> heckj: +100000000
18:36:34 <gyee> heckj, I've been using keystoneclient to test API compatibility with HP
18:36:36 <gyee> works great :)
18:36:57 <heckj> It's annoying me that novaclient has it's own auth, and the glanceclient is using it internally, but without a clear internal API
18:37:05 <heckj> gyee: excellent!
18:37:31 <dolphm> gyee: awesome
18:37:43 <dolphm> gyee: rax recently started doing the same thing
18:37:53 <heckj> Oh - really awesome utility application y'all might be interested in: cloudenvy (github.com/bcwaldon/cloudenvy)
18:38:16 <heckj> gives you vagrant-like commands to spin up instances and provision them quickly in openstack clouds
18:38:30 <heckj> I've been using it to spin up a development environment for myself at Nebula on our clouds
18:38:56 <gyee> thanks, I'll check it out
18:39:20 <heckj> I'm going to make a fork of devstack that uses it to spin up devstack in a large instance for testing
18:39:47 <dolphm> heckj: ncie
18:44:27 <ayoung> so the real problem with the devstack install actually seems to be that the PKI token is somehow getting truncated
18:44:28 <heckj> I don't have anything else - will close up the meeting in 5 minu
18:44:53 <ayoung> the token passed to glance is glance --os-auth-token MIIFfQYJKoZIhvcNAQcCoIIFbjCCBWoCAQExCTAHBgUrDgMCGjCCBFYGCSqGSIb3DQEHAaCCBEcEggR
18:45:16 <ayoung> and that MIIF is actually a giveaway that this is a PKI token.  I think they all start with that, something about CMS.
18:45:19 <heckj> assumptions built into devstack then about how to get a token and how long it will be...
18:45:29 <ayoung> heckj, most likely.
18:45:51 <gyee> ayoung, that get pass in from command line?
18:46:15 <ayoung> Anyway, I set the token backend to SQL ( which I once again think we want to do by default) and I can see the token in there with the same prefix as above, matching out to where it is truncated
18:46:21 <ayoung> gyee, yes
18:46:35 <ayoung> ++ glance --os-auth-token MIIFfQYJKoZIhvcNAQcCoIIFbjCCBWoCAQExCTAHBgUrDgMCGjCCBFYGCSqGSIb3DQEHAaCCBEcEggR --os-image-url http://127.0.0.1:9292 image-create --name cirros-0.3.0-x86_64-uec-ramdisk --public --container-format ari --disk-format ari
18:48:18 <dolphm> ayoung: +1 for default to sql driver for tokens
18:50:40 <ayoung> dolphm, what do you think about the token length?  Should we provide an option to read tokens from a file?
18:51:01 <dolphm> ayoung: referring to keystone.conf?
18:51:15 <ayoung> dolphm, that too, but no, I meant for the various CLIs
18:51:39 <dolphm> ayoung: ooh ... specify a PKI token in a file for clients to use?
18:51:43 <ayoung> actually, I like the keyring option
18:51:58 <ayoung> but, yeah, a pki token file
18:52:10 <ayoung> try to get some token reuse
18:52:19 <dolphm> ayoung: token file seems like a logical first step before adding real keyring support
18:53:06 <ayoung> dolphm, really?  Why not just skip to the more secure solution?
18:53:44 <dolphm> ayoung: well -- how would you manage clearing the current token? or using an alternative token
18:54:09 <ayoung> dolphm, I don;t know.  That implies I know all about keyring.  I assume keyring has ways to handle it.
18:54:12 <dolphm> ayoung: i.e. i'm doing some tasks with these roles with this token, and some other tasks with these roles on another tenant with this other token
18:54:26 <ayoung> ah, I see why you like the file id
18:54:26 <ayoung> ea
18:54:29 <dolphm> ayoung: or even as different users
18:56:56 <dolphm> ayoung: just want to make sure we maintain the current flexibility in specifying how to auth (or bypass it) for every command
18:57:02 <ayoung> dolphm, file the enhancement request please
18:57:40 <dolphm> ayoung: filing request enhancement, please hold
18:58:29 <dolphm> ayoung: heckj: --token is becoming --os-token, correct?
18:58:37 <heckj> yep
18:58:55 <heckj> updated in keystoneclient as of latest (but not yet released as a .x update to PyPI)
18:59:11 <heckj> and --endpoint moved to --os-endpoint
18:59:17 <dolphm> heckj: cool, thought so
18:59:21 <heckj> both moving to match what's specified in UnifiedCLI
18:59:23 <dolphm> heckj: pretty sure i reviewed that lol
18:59:27 <heckj> heh
18:59:41 <heckj> Erp, we're outa time - closing this up
18:59:43 <heckj> #endmeeting