18:01:11 #startmeeting keystone 18:01:12 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:14 The meeting name has been set to 'keystone' 18:01:21 o/ 18:01:22 #topic agenda at http://wiki.openstack.org/Meetings/KeystoneMeeting 18:01:29 ola guys 18:01:32 any gyee? others? 18:02:09 ain't nobody here but us chickens 18:03:11 heh 18:03:21 #topic summit session 18:03:38 We've got three hours open in our sessions so far - not feeling like I need to fill them, but FYI 18:03:47 Can you two see: http://summit.openstack.org/cfp/topic/6 18:03:48 ? 18:04:17 heckj: forbidden 18:04:24 Ah well, fraid fo that 18:04:30 It's the approved list for the summit 18:04:56 I'll make a screenshot and send to you two so you can see that status 18:05:13 heckj: i can see this http://summit.openstack.org/ 18:05:32 heckj: which shows unreviewed/preapproved/incomplete .. i just can't filter by topic? 18:05:54 heckj: i see 6 keystone sessions on that 18:05:56 Spect so - I'm not entirely sure how permissions and such are set up with that app 18:06:09 #topic bugs vs blueprints for feature work 18:06:12 So... 18:06:58 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 For the pure work items, I thought about trying to get us using blueprints more extensively. 18:07:26 Figured I'd ask you two what you though. 18:07:54 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 i think launchpad's blueprints are a little broken as a system, but they're more appropriate 18:09:02 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 ayoung: any opinions or thoughts? 18:09:38 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 depends on if the PTL is volunteering to completely manage blueprints or if we have to do it ourselves 18:10:42 heckj, in general I agree, but the LDAP bugs do tend to stand alone 18:10:53 each of them is valid in the absense of the others 18:11:22 makes sense 18:11:38 the only other set of bugs that are really blueprint work is my fault - the implement V3 API stuff 18:11:40 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 Any qualms if I nuke this bugs and leave it to the blueprint to link up reviews? 18:12:17 s/this/those/ 18:12:33 nope 18:12:37 kk 18:12:42 #topic feature branch 18:12:48 So - feature branch 18:12:56 #topic - I'm lying, open discussion 18:13:09 feature branch - how are we liking it? 18:13:20 \o 18:13:22 sorry I am late 18:13:34 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 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 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 I've also been very slow to get reasonable reviews up for that work as well 18:14:44 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 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 the outdated thing seems wonky. 18:16:01 ayoung: how so? outdated doesn't imply a trivial rebase won't resolve it 18:16:19 dolphm, yeah, it just kindof says "don't bother reviewing" which is wrong 18:16:28 trying to keep track of my tasks. 18:16:34 ayoung: should still certainly be reviewable in isolation 18:17:07 heckj, this one is, I think, needing your input. https://review.openstack.org/#/c/12106/6 18:17:15 The rest all depend on that 18:17:19 kk 18:17:20 I agree with ayoung, this outdate/restore thingy is abit confusing 18:17:48 the two week timeout on reviews without activity has been biting me a lot lately 18:18:07 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 yeah, noticed that - 18:18:19 some of that, I'm sure, is my slowness though 18:18:31 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 dolphm, so SQL alchemy is broken? 18:19:42 I am not even sure if foreign key work across all sql backends 18:19:45 ayoung: that's a limitation of our architecture -- the desire to plug random combinations of drivers together 18:20:02 I understand if, say, sqlite doesn't support it, but then SQL alchemy should abstract that away 18:20:23 ayoung, then we'll have inconsistent enforcement 18:20:29 ayoung: i'm toying with the idea of writing a single, high performance, monolithic sqlalchemy driver that covers all backends 18:20:41 ayoung: and then we can use foreign keys, and cascade deletes and whatnot 18:21:24 dolphm, +1 18:21:56 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 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 ayoung: and then you can mix ldap into ti :P 18:22:21 dolphm, no 18:22:35 we need you to do real work, not tilt at windmills 18:22:43 I assure you, they are not giants 18:23:16 ooohh!! windmills!!! 18:23:19 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 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 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 dolphm, ah, that. I think the problem is eventlet 18:24:39 ayoung: how so? 18:24:48 ayoung: our sql query performance is garbage 18:25:00 all SQL requests end up getting serialized, which means others are getting blocked 18:25:07 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 I suspect the threading monkey_patch 18:25:21 I think we should benchmark running in apache HTTPD 18:25:39 I think we will be much happier, less work, and on a more secure platform 18:25:57 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 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 We will also get IPv6 support, so my Uncle will be happy 18:26:18 heckj: +1 for benchmark 18:26:48 heckj: i have a keystoneclient script for v3 that might help there 18:27:12 heckj: creates and tears down a bunch of entities 18:27:24 BTW, devstack with Signed tokens is broken. I've nailed down one issue, but have not yet solved the overall thing. 18:27:48 ayoung: symptoms? 18:27:50 The admin token is 80 characters long. I had been checking for UUID token length, which is 32 chars long 18:27:53 ayoung: well damn 18:28:10 but once I change the length limit to 80, it still fails, 18:28:13 ayoung: lol i told you token length wasn't a good metric 18:28:15 I haven't figured out why 18:28:32 dolphm, and I remember agreeing with you 18:28:39 ayoung: i think you need to try and decipher every token, and if it fails, assume it's not pki 18:28:48 dolphm, I can do something like start the PKI tokens with PKI- 18:29:13 ayoung: a hint would make that much more reasonable - like the idea! 18:29:17 as a UUID token is, I think, limited to 0-9A-F 18:29:28 I'll open a ticket for that 18:29:49 ayoung, +1 on prefixing 18:30:37 ayoung: correct, since we use .hex... however, hardcoded admin_token values could be anything 18:30:48 ayoung: hardcoded = keystone.conf'd 18:30:55 ayoung: hardconfigured? 18:32:00 dolphm, that is oK, If they start them with PKI they are going to be treated as PKI tokens. 18:32:40 Chance of that happening unintentionally is vanishingly small enough that I will trust it to a release note 18:32:55 or put in a check in the code 18:33:06 gyee: check for what? 18:33:11 anyway, once I change the length to >80, it fails, seemingly in the UUID token path. 18:33:20 check to make sure admin token is properly prefix 18:33:21 if admin_token[:4] == 'PKI-' throw a warning? 18:33:32 yeah, something like that 18:33:46 gyee, file format? fall back to online checking if it isnt cms? 18:34:26 right, pki tokens are base64 encoded right? 18:34:50 if we can't do base64 decode, then we can try the uuid route 18:35:43 https://bugs.launchpad.net/keystone/+bug/1060389 18:35:44 Launchpad bug 1060389 in keystone "Non PKI Tokens longer than 32 characters can never be valid" [Undecided,New] 18:35:47 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 that needs to be fixed before we can throw the switch on tokens to go PKI 18:35:59 heckj: +100000000 18:36:34 heckj, I've been using keystoneclient to test API compatibility with HP 18:36:36 works great :) 18:36:57 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 gyee: excellent! 18:37:31 gyee: awesome 18:37:43 gyee: rax recently started doing the same thing 18:37:53 Oh - really awesome utility application y'all might be interested in: cloudenvy (github.com/bcwaldon/cloudenvy) 18:38:16 gives you vagrant-like commands to spin up instances and provision them quickly in openstack clouds 18:38:30 I've been using it to spin up a development environment for myself at Nebula on our clouds 18:38:56 thanks, I'll check it out 18:39:20 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 heckj: ncie 18:44:27 so the real problem with the devstack install actually seems to be that the PKI token is somehow getting truncated 18:44:28 I don't have anything else - will close up the meeting in 5 minu 18:44:53 the token passed to glance is glance --os-auth-token MIIFfQYJKoZIhvcNAQcCoIIFbjCCBWoCAQExCTAHBgUrDgMCGjCCBFYGCSqGSIb3DQEHAaCCBEcEggR 18:45:16 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 assumptions built into devstack then about how to get a token and how long it will be... 18:45:29 heckj, most likely. 18:45:51 ayoung, that get pass in from command line? 18:46:15 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 gyee, yes 18:46:35 ++ 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 ayoung: +1 for default to sql driver for tokens 18:50:40 dolphm, what do you think about the token length? Should we provide an option to read tokens from a file? 18:51:01 ayoung: referring to keystone.conf? 18:51:15 dolphm, that too, but no, I meant for the various CLIs 18:51:39 ayoung: ooh ... specify a PKI token in a file for clients to use? 18:51:43 actually, I like the keyring option 18:51:58 but, yeah, a pki token file 18:52:10 try to get some token reuse 18:52:19 ayoung: token file seems like a logical first step before adding real keyring support 18:53:06 dolphm, really? Why not just skip to the more secure solution? 18:53:44 ayoung: well -- how would you manage clearing the current token? or using an alternative token 18:54:09 dolphm, I don;t know. That implies I know all about keyring. I assume keyring has ways to handle it. 18:54:12 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 ah, I see why you like the file id 18:54:26 ea 18:54:29 ayoung: or even as different users 18:56:56 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 dolphm, file the enhancement request please 18:57:40 ayoung: filing request enhancement, please hold 18:58:29 ayoung: heckj: --token is becoming --os-token, correct? 18:58:37 yep 18:58:55 updated in keystoneclient as of latest (but not yet released as a .x update to PyPI) 18:59:11 and --endpoint moved to --os-endpoint 18:59:17 heckj: cool, thought so 18:59:21 both moving to match what's specified in UnifiedCLI 18:59:23 heckj: pretty sure i reviewed that lol 18:59:27 heh 18:59:41 Erp, we're outa time - closing this up 18:59:43 #endmeeting