18:02:34 <dolphm> #startmeeting keystone
18:02:34 <topol> what was the 1970 bad cartoon. Ive seen them all
18:02:36 <openstack> Meeting started Tue Aug  6 18:02:34 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:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:40 <openstack> The meeting name has been set to 'keystone'
18:02:52 <dolphm> henrynash: thanks for last week!
18:03:04 <fabio> Hi
18:03:05 <henrynash> dolphm: no
18:03:14 <henrynash> dolphm: np (!)
18:03:17 <dolphm> lol
18:03:28 * topol awkward
18:03:38 <spzala> Hi!
18:03:51 <ayoung> this is turning into a real community effort.
18:03:53 <dolphm> forgive me, i'm still getting back up to speed :)
18:03:57 <henrynash> dolphm: (that'l teach me to type with apple pie and custard in one hand)
18:04:14 <dolphm> henrynash: you should use a plate
18:04:24 <henrynash> dolphm: yes, it is a bit gooey
18:04:26 <dolphm> henrynash: and maybe a desk
18:04:42 <gyee> henrynash, what's on your *other hand*? :)
18:04:55 <henrynash> dolphm: bad boy
18:05:00 <dolphm> i definitely want to go through havana-3 BP's today, but that can just be open discussion
18:05:01 <henrynash> gyee: bad boy
18:05:20 <dolphm> #topic Critical issues
18:05:36 <ayoung> No critical bugs as of right now
18:05:44 <dolphm> i'm way behind on triaging new bugs though :(
18:06:00 <gyee> dolphm, I filed one for auth_token middleware, apparently we are using v2.0 for admin token
18:06:02 <dolphm> if anyone is aware of an issue that's still New, feel free to mention it
18:06:18 <dolphm> gyee: link?
18:06:37 <ayoung> dolphm, I've been doing abit of triage.  Please feel free to assign any LDAP based bugs you come across to me, to include stuff on the mixed Identity backend
18:06:37 <gyee> https://bugs.launchpad.net/bugs/1207922
18:06:39 <uvirtbot> Launchpad bug 1207922 in python-keystoneclient "auth_token middleware always use v2.0 to request admin token" [Undecided,Confirmed]
18:06:55 <gyee> dolphm, I am about to file another one
18:07:07 <dolphm> gyee: that's not immediately breaking something though, right?
18:07:24 <gyee> we should not be using httplib in auth_token middleware anymore as it does not validate server cert
18:07:32 <gyee> that might be a security issue
18:07:32 <dolphm> gyee: there's a bug and bp for that already
18:07:49 <dolphm> gyee: i think it's assigned to jamielennox
18:08:00 <gyee> dolphm, oh ok, that's good
18:08:01 <ayoung> dolphm, he's working on it, and a lot of client related issues
18:08:07 <dolphm> ayoung: +1
18:08:34 <ayoung> dolphm, he broke his work up in to a series of reviews.
18:08:49 <dolphm> i'll assume there's nothing too exciting going on, but again... i had literally 100+ emails from launchpad about bugs when i got back lol
18:08:50 <ayoung> dolphm, last week I was haranguing the core keystone devs to do more client reviews
18:09:24 <ayoung> so y'all consider yourselves re-harangued:  do more client reviews
18:09:25 <dolphm> ayoung: thanks! the client should really get more of everyone's attention than it does
18:09:41 <gyee> yes absolutely
18:10:03 <ayoung> dolphm, so the problem is that I think people don't really understand how the client is put together until they deep dive it
18:10:14 * dolphm harangue
18:10:19 <morganfainberg> ayoung: thankfully diving into it isn't too bad.
18:10:25 <ayoung> dolphm, maybe next week we put a few minutes aside for a walk through?
18:10:36 <topol> ayoung +1
18:10:42 <dolphm> ayoung: during the meeting?
18:10:47 <lbragstad> ayoung: +1
18:11:02 <ayoung> dolphm, it is the only time we have everyone together.  Either then, or a special one off/
18:11:03 <topol> I have a callin number. would we use that?
18:11:19 <morganfainberg> ayoung: i'd think a special one off might be easier.
18:11:19 <ayoung> I think it might be time well spent.  And, morganfainberg is right, it isn't that bad
18:11:34 <topol> or is it an irc based walkthrough?
18:11:42 <morganfainberg> ayoung: we can setup webex/g2meeting or something with audio as well, might help.
18:11:43 <ayoung> topol, I think IRC would be sufficient
18:11:52 <dolphm> sure, if someone wants to coordinate something, this would be the best place to promote it, but i'm not sure it's the best venue to conduct it
18:11:55 <morganfainberg> i'll defer if you think IRC is suffcient though
18:11:55 <ayoung> I'm partial to elluminate myself
18:12:09 * dolphm always happy to answer questions on irc
18:12:13 <ayoung> dolphm, cool, put down an action item and I'll try to arrainge
18:12:20 <gyee> com'on ppl, topol is offering his bridge
18:12:23 <dolphm> #action ayoung to coordinate client walkthrough
18:12:24 <gyee> take advantage of it!
18:12:29 <topol> gyee +1
18:12:34 <ayoung> ideally, we would get jamielennox there, which makes it a little late for the Europe folks
18:12:36 <dolphm> #action topol to make bridges
18:12:40 <stevemar> topol, gyee +1
18:12:42 <gyee> for one, I like to hear ayoung's voice
18:12:47 <ayoung> gyee, you lie
18:12:49 <gyee> make sure his real
18:12:56 * ayoung lies too
18:12:58 <morganfainberg> gyee: lol
18:13:04 <dolphm> what's jamielennox's time zone?
18:13:12 <ayoung> dolphm, brisbane australia
18:13:18 <dolphm> oh wow
18:13:19 <topol> do we want a web conference as well or just abridge?
18:13:36 <bknudson> record it and then we can watch it whenever
18:13:38 <ayoung> 4:13 AM for him right now
18:13:39 <dolphm> bknudson: +1
18:13:42 <lbragstad> bknudson: +1
18:13:43 <morganfainberg> bknudson: +1
18:13:49 <dolphm> (who put bp notifications on the agenda?)
18:13:58 <lbragstad> me
18:14:03 <dolphm> #topic bp notifications
18:14:08 <dolphm> #link https://blueprints.launchpad.net/keystone/+spec/notifications
18:14:08 <lbragstad> Got keystone running in apache per ayoung and bknudson notes. Pulled in the latest olso notifier and dependencies. Applied the logging fix to remove eventlet issues in keystone/openstack/common/local.py. Applied notifications module and tested with tenants on CUD, first step, tested with log notifier, then tested with rpc notifier. Applied a patch to https://github.com/openstack/oslo-incubator/blob/master/openstack/common/rpc/amqp.
18:14:11 <ayoung> dolphm, with the exception of henrynash I think we are all US eastern or later.  Our team meets at 5:30 PM on Modnay, and he can make that meeting
18:14:39 <lbragstad> the short of it.. the current olso notification implementation works in keystone apache httpd
18:14:49 <lbragstad> for tenant create, update, and delete
18:14:50 <ayoung> lbragstad, nice
18:14:50 <dolphm> lbragstad: yay!
18:14:51 <morganfainberg> lbragstad: nice.
18:15:00 <bknudson> lbragstad: is the code posted for review?
18:15:04 <ayoung> lbragstad, do I need to remove a -2 somewhere then?
18:15:05 <dolphm> lbragstad: should notifications be targetted at havana-m3 then?
18:15:12 <dolphm> lbragstad: probably lol
18:15:18 <dolphm> ayoung: * ^
18:15:26 <lbragstad> no, it's strung together in like 6 commits on my local branches
18:15:36 <lbragstad> I have to fix something i Oslo
18:15:39 <lbragstad> in oslo
18:15:42 <dolphm> i guess https://blueprints.launchpad.net/keystone/+spec/unified-logging-in-keystone should be targetted first
18:15:52 <lbragstad> dolphm: correct
18:15:59 <lbragstad> that *needs* to be fixed
18:16:00 <dolphm> lbragstad: is that a realistic goal?
18:16:05 <ayoung> lbragstad, are you planning on  submitting them as 6 commits, or squashing?
18:16:07 <dolphm> lbragstad: one or both for m3
18:16:29 <lbragstad> I am going to have to clean them up and submit them individually
18:16:38 <ayoung> We have a month.  THat should be realistic, assuming Oslo moves, and they are pretty responsive.
18:16:47 <lbragstad> grabbing alink
18:16:53 <dolphm> assuming we can be officially unblocked by oslo
18:16:55 <lbragstad> here is part of it *( the logging fix)
18:17:05 <lbragstad> #link https://review.openstack.org/#/c/39934/
18:17:33 <lbragstad> that implements unified logging for kestyone using the fix for local.py that removes the eventlet dependency
18:17:42 <lbragstad> from there, we can sync with the notifier in oslo
18:17:52 <dolphm> sweet
18:18:07 <lbragstad> and then I can push the notification module/tests/implementation as a commit on it's own
18:18:09 <bknudson> I think there are 3 reviews now pulling in the same stuff from oslo
18:18:17 <ayoung> OK, recommend we target this for H3, then
18:18:17 <lbragstad> bknudson: yes
18:18:21 <dolphm> lbragstad: updated bp unified-logging-in-keystone target & impl
18:18:26 <lbragstad> dolphm: thank you
18:18:34 <lbragstad> Ihave to look into the jenkins issue
18:19:21 <lbragstad> I have some fixes that are in keystone/openstack/common/rpc/amqp.py that need to land in Oslo first
18:19:32 <lbragstad> I can get started on filing a bug for that later today
18:19:37 <dolphm> lbragstad: let's leave notification targeted at 'next' until logging is totally complete, then we can see how much time we have
18:19:48 <lbragstad> dolphm: ok, that sounds fair
18:20:30 <ayoung> dolphm, henrynash has an interesting review that seems to slip in under the letter of the law for an acceptable feature
18:20:32 <dolphm> #topic High priority code reviews
18:20:38 <dolphm> link em up
18:20:46 <ayoung> https://review.openstack.org/#/c/39530/
18:20:48 <dolphm> #link https://review.openstack.org/#/c/40170/
18:20:55 <ayoung> #link https://review.openstack.org/#/c/39530/
18:21:37 <ayoung> "Implement domain specific Identity backends"
18:21:48 <morganfainberg> ayoung: henrynash's change is pretty cool.
18:22:02 <ayoung> dolphm, it has no new API and config file is 100% backwards compat
18:22:03 <henrynash> so this was already targeted at H3
18:22:22 <bknudson> can we have multiple identity_api providers now?
18:22:35 <ayoung> bknudson, with 39530, yes
18:22:46 <bknudson> but the dependency registry only supports a single one?
18:22:54 <ayoung> please take a look at the config file changes
18:23:09 <henrynash> but I would like some guidance on the config changes…
18:23:17 <ayoung> there is some need to push up a cleaner API to the oslo code base, but it supports what we want to do
18:23:26 <ayoung> there are two options.  I'll link
18:23:34 <henrynash> …the goals is to be able  to create new config structure for each instantiated bbackend driver
18:23:43 <ayoung> #link https://review.openstack.org/#/c/39530/11/keystone/common/config.py
18:23:47 <henrynash> ayoung: do 11 and the most recent
18:24:00 <ayoung> and
18:24:18 <ayoung> #link https://review.openstack.org/#/c/39530/12/keystone/common/config.py
18:24:27 <henrynash> ayoung: yep, those are the two
18:24:48 <ayoung> ideally, the helper methods like register_cli_int  would be on the config object itself
18:24:51 <ayoung> so we could do
18:24:57 <ayoung> conf.register_cli_int
18:25:03 <dolphm> ayoung: oslo's config object?
18:25:09 <ayoung> dolphm, yeah
18:25:18 <dolphm> ayoung: oslo hates that we use those functions at all
18:25:35 <henrynash> dolphm: so the 2nd link is a version that removes them
18:25:36 <ayoung> dolphm, is version 12 how they want us to do it?
18:25:38 <gyee> henrynash, look like good stuff at the first glance
18:25:50 <dolphm> ayoung: i'd ask markmc, and take his advice :)
18:25:51 <morganfainberg> oh we have a review to remove those helper functions?
18:25:54 <henrynash> dolphmL, while the first one is a version that tries to keep them
18:26:01 <henrynash> gyee: thx
18:26:03 <dolphm> ayoung: henrynash: get markmc on that review!
18:26:26 <henrynash> dolphm: ok
18:26:30 <ayoung> added him
18:26:30 <dolphm> henrynash: thanks
18:26:40 <bknudson> I thought the whole point of oslo config is that you could have command-line overrides for all the options.
18:26:49 <ayoung> bknudson, this is not command line, though
18:26:51 <bknudson> although I've never tried it.
18:26:54 <morganfainberg> bknudson: that was my understanding.
18:26:54 <ayoung> this is multiple config files
18:27:09 <ayoung> henrynash, care to explain what you are doing in a bit more detail?
18:27:09 <bknudson> right, the command-line overrides the value in the config file
18:27:14 <henrynash> sure
18:27:33 <dolphm> bknudson: in part, yes... and i'm not sure how i would expect CLI options to interact with / override per-domain config
18:28:04 <henrynash> so we use the identity Manager layer to allow multiplexing of driver backends (e.g, LDAP server 1 for domainA, LDAP sever 3 for domain b, the rest share SQL etc.)
18:28:22 * dolphm [X] multiplexing
18:28:37 <dolphm> more checkboxes for marketing
18:28:48 <gyee> nice
18:28:52 <henrynash> for each domain that wants its one backend, you create a 'keystone.<domain_name>.comf' file that just contains the config overrides for the domain
18:29:00 <topol> henrynash, very cool!
18:29:30 <henrynash> so the manger picks up all those files, creates a new conf structure for each one and inits the request driver withit
18:29:59 <henrynash> …hence the need to be able to create a separate conf structure (which is where we came into this discusion)
18:30:56 <ayoung> one possible use of this pattern in the future is multiple SQL datasources
18:30:56 <gyee> henrynash, besides LDAP, are there any other use case for this?
18:31:08 <dolphm> henrynash: as long as you can exploit with something dumb like POST /v3/domains {"domain": {"name": "/../../etc/passwd; #"}}
18:31:28 <henrynash> gyee: well, yes it isn't constrained to ldap….you could have separate SQL drivers if you wanted to keep data in different DBs per domain
18:31:53 <henrynash> dolphm: not sure I follow
18:32:12 <bknudson> do I have to restart Keystone when create domain?
18:32:17 <dolphm> henrynash: you're reading paths off the file system that are provided by API users
18:32:25 <dolphm> henrynash: generally that's not a good idea
18:32:41 <ayoung> henrynash, actually, I was thinking that it would be good to be able to split table spaces on module lines, so, say tokens could go into a separate RDBMS than policy or something, too.  I think you are setting up a pattern, and I want people to validate that.
18:32:42 <gyee> dolphm, some injection attack? :)
18:32:57 <dolphm> henrynash: if the format was keystone.{domain_id}.conf then the file names would be determined by keystone, and not the API user, and we can all be a lot less paranoid
18:33:29 <henrynash> dolphm: I toyed with whether it should be domain_id or domain_name
18:33:31 <dolphm> henrynash: you're also requiring that domain names be encodable in the constraints of the file system... another problem that system-assigned ID's would solve
18:33:39 <ayoung> keystone.{domain drop table tokens;}.conf
18:33:44 * topol just because you are paranoid doesn't mean they aren't out to get you
18:34:02 <henrynash> dolphm: was just concerned over readability….but I'm oK with Ids
18:34:09 <henrynash> bknudson: yes, that is an issue
18:34:43 <henrynash> bknduson: I was going to have a separate extension that provided a new API call to re-init a domain…and have that called by keystone-manage
18:35:00 <dolphm> henrynash: i certainly understand the readability issue
18:35:05 <henrynash> bknudson: that would be the only extension bit of this…
18:35:06 <bknudson> not a big concern since this requires config option.
18:35:11 <topol> when would re-init get called?
18:35:23 <dolphm> henrynash: init?
18:35:28 <henrynash> topol: so today, it's a keystone restart
18:35:37 <topol> yep
18:35:37 <henrynash> dolphm: yes, the manager init
18:35:43 <dolphm> henrynash: oh to initialize drivers and whatnot
18:35:48 <topol> and in the future?
18:36:14 <dolphm> henrynash: normally that wouldn't be done through a web api
18:36:20 <henrynash> topol: so I thought for now we might allow keystone-mange to have a "domain-init" function?
18:36:40 <henrynash> dolplhm: open to how best to do that
18:36:41 <topol> henrynash, OK
18:37:33 <gyee> henrynash, more fun when we have the need to support nested domains?
18:37:55 <henrynash> dolphm: on the domain_name vs domain_id issue, I also thought that anyone using external serves like LDAP etc. would likely have good domain names
18:37:57 <ayoung> domain is in the assignments backend.  It is OK to modify that to have additional information about the domains config
18:38:01 <topol> nested domains, we have a use case for that???
18:38:02 <dolphm> henrynash: i'd make sure it's an issue with people actually deploying keystone before you pursue some complicated proprietary solution to a problem that doesn't actually exist :(
18:38:03 <henrynash> gyee: hmm, indeed :-)
18:38:25 <ayoung> gyee is instigating
18:38:26 <morganfainberg> gyee: domains all the way down?
18:38:37 <dolphm> henrynash: restarting a keystone process to pick up new config isn't unreasonable
18:38:47 <topol> dolphm +1
18:38:57 <henrynash> dolphm: that's what you have today out of the box
18:38:59 <topol> (until someone complains :-) )
18:39:09 <dolphm> topol: +1
18:39:34 <dolphm> #topic open discussion
18:39:49 <dolphm> #link https://launchpad.net/keystone/+milestone/havana-3
18:39:55 <ayoung> Do bug triage
18:40:04 <henrynash> i raised the issue on the agenda of the migration being proposed to fix the credentials index?
18:40:07 * dolphm will do
18:40:13 <bknudson> server never supported paging, so suggest removing it from spec: https://review.openstack.org/#/c/39828/
18:40:15 <dolphm> #action dolphm to triage all the bugs
18:40:37 <fabio> dolphm, regarding OS-EP-FILTER
18:40:39 <dolphm> bknudson: thanks!
18:40:44 <fabio> #link https://review.openstack.org/#/c/33118/
18:41:00 <henrynash> #link https://review.openstack.org/#/c/40170/
18:41:01 <bknudson> henrynash: that review is mysql-only
18:41:16 <ayoung> dolphm, that is not just for you
18:41:18 <henrynash> bknduson: err, do you mean sqlite?
18:41:27 <bknudson> if migrate_engine.name != 'mysql': return
18:41:43 <bknudson> so it only runs if mysql
18:41:56 <dolphm> ayoung: aww, that'd be appreciated lol
18:41:57 <ayoung> dolphm, suggestion: for all bugs that are new, assign them to someone on core to verify
18:42:00 <henrynash> bknuson: ahh, hmm I thought it was sqllite that was the problem…oh, well
18:42:12 <topol> (thats got to go: if migrate_engine.name != 'mysql': return )
18:42:17 <ayoung> dolphm, once we've verified, mark as verified, and then you can triage
18:42:18 <bknudson> I don't understand why only mysql had this problem.
18:42:20 <dolphm> ayoung: how about subscribing ya'll as appropriate?
18:42:22 <topol> go away
18:42:28 <dolphm> ayoung: and you assign to yourself
18:42:34 <henrynash> topol : the reaso is that I think it's only broken for one DB type
18:42:39 <ayoung> dolphm, I've been grabbing ones
18:42:51 <ayoung> mostly around LDAP and identity
18:43:02 <dolphm> ayoung: i don't want to assign bugs to only core, as i don't want to block non-core from feeling like they can contribute fixes
18:43:16 <ayoung> dolphm, fair enough
18:43:17 <dolphm> ayoung: MUCH appreciated
18:43:26 <dolphm> ayoung: like for serious
18:43:34 <topol> henrynash, perhaps a comment then metnioning that
18:43:42 <henrynash> bkudson: I think it was a previous change that removed a constraint, and left an index hanging around…but if that is true for msysql, I agree it should be true for postgres etc.
18:44:08 <henrynash> bkundson: confused face in place
18:44:53 <bknudson> henrynash: once the tests are fixed to verify on all engines, I'll give it a whirl.
18:44:58 <ayoung> dolphm, I think we have 97 bugs open that have no one assigned, if I performed the query correctly
18:45:30 <ayoung> Oh, some of those have fix committed
18:45:35 <henrynash> dolphm: my reason to raise it all is that we had said "no more migrations"…do we allow this one if we think it is fixing a real issue?
18:45:38 <dolphm> henrynash: still planning on working this bp during m3, or should it be untargeted? https://blueprints.launchpad.net/keystone/+spec/pagination-backend-support
18:45:59 <henrynash> dolphm: I am planning to attack it next week
18:46:04 <dolphm> ayoung: it's still a lot of bugs :(
18:46:10 <dolphm> henrynash: cool, just wanted to check
18:46:25 <dolphm> henrynash: it's our only 'not started' .. no pressure ;)
18:46:35 <henrynash> dolphm: :-)
18:46:50 <dolphm> henrynash: i'm lost on the context of your question about migrations though
18:47:02 <morganfainberg> dolphm: as soon as i have a little breathing room on dayjob front, I'll hit some of the bugs i can.
18:47:13 <dolphm> morganfainberg: what's your dayjob, anyway?
18:47:16 * topol my money's on henynash getting is started :-)
18:47:30 <morganfainberg> dolphm: writing openstack code internally for my company.
18:47:33 <henrynash> dolphm: I thought we had said (maybe I 'm wrong) that we had decided no more sql migrations for H3
18:47:52 <ayoung> https://bugs.launchpad.net/keystone/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.importance%3Alist=UNDECIDED&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.
18:47:53 <ayoung> has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on
18:47:54 <dolphm> henrynash: i guess i missed that discussion... why not?
18:47:59 <ayoung> ugh, too long
18:48:00 <bknudson> if there's no new features then there's no new migrations
18:48:08 <dolphm> ayoung: bit.ly?
18:48:15 <ayoung> dolphm, yeah, one sec
18:48:18 <dolphm> bknudson: migrations can fix bugs, though
18:48:22 <henrynash> dolphm: For some reason I thought we were trying to have no DB changes between H2 -> H3
18:48:39 <henrynash> dolphm: sounds like I was imagining this… :-)
18:48:45 <ayoung> http://bit.ly/11KfaLF
18:48:55 <dolphm> bknudson: the ec2 -> credentials migration would be another that wouldn't fit
18:49:03 <ayoung> Those should be the ones on one has looked at yet:  new, undecided priority
18:49:05 <nachi> dolphm: https://review.openstack.org/#/c/38367/
18:49:48 <dolphm> henrynash: sounds like something that might happen by coincidence, but i certainly wouldn't -2 any migration review until icehouse or anything
18:50:11 <dolphm> henrynash: bknudson: check out nachi's review above ^
18:50:21 <gyee> dolphm, I am lost, we are saying no new migrations till IceHouse?
18:50:28 <ayoung> dolphm, so my thought was that extension migrations would go in their own repos, but for core, we would still allow them in the common repo.
18:50:32 <henrynash> dolphm: Ok, fine…I'll chalk that up to eating too much blue cheese late at night....
18:50:34 <dolphm> gyee: no no, i was asking where that notion came from
18:50:53 <dolphm> gyee: if there was a discussion about it, i missed it is all
18:51:06 <gyee> dolphm, no, that why I was confused
18:51:16 <dolphm> i suspect it's something we should take review by review though?
18:51:23 <gyee> agreed
18:51:26 <ayoung> dolphm, that is why I was pushing for the repo split, to make things clearer.  But it looks like we are not all of the same mind there.
18:51:40 <bknudson> I like the repo split
18:52:00 <bknudson> if someone wants to use it they'll be able to once the code's in.
18:52:28 <dolphm> ayoung: i'm not opposed to splitting the repo, i'm mostly playing devil's advocate there / don't see an immediate benefit
18:52:47 <fabio> ayoung: is the repo split targeted for m3?
18:52:52 <bknudson> some people think there should be no extensions.
18:52:53 <ayoung> bknudson, the one concern that dolphm has voiced that is worth repeating here is that with Alembic, we will end up with multiple steps .
18:53:22 <dolphm> s/immediate benefit/immediate benefit for anyone but us/
18:53:28 <ayoung> heh, we are going to have extensions.  jaypipes is actually going to resubmit his "regions" change as an extension, even after that discussion
18:53:39 <jaypipes> indeed.
18:53:42 <dolphm> ayoung: he hasn't done that though, and i now see why :P
18:53:43 <ayoung> dolphm, so, my though was that it lest su split out an extension from the main database.  I was thinking
18:53:53 <ayoung> for something like kds, that may not belon in Keystone lng term
18:54:03 <gyee> jaypipes, you decided that after a couple of drinks? :)
18:54:03 <dolphm> i assume he's philosophically opposed to authoring an api extension :)
18:54:31 <ayoung> dolphm, no, he is philosophically opposed to wastingtime when a core dev decides to roadblock
18:54:34 <topol> "couple"  -- you are being generous  :-)
18:54:36 <jaypipes> gyee: no, I was always willing to do what what was asked of me... doesn't mean I can't debate it in public though ;)
18:55:12 * dolphm <3 open source community spirit
18:55:48 <ayoung> dolphm, so I see the repo split as the logical result of the focus on extensions.  It lets us keep separate concerns separate
18:56:13 <ayoung> and, if we decide that something should be spun off into its own server, we have a way of deploying just that extension...sort of.
18:56:31 <gyee> ayoung, speaking of that, shouldn't we be concerned about repo split with henry's separate driver per domain thingy?
18:56:33 <ayoung> It means that the changes for that extnesion are not intertwined with the migrations for unrelated code/
18:56:45 <ayoung> gyee, nope.  Doesnt' affect it
18:56:58 <bknudson> gyee: yes, interesting, how to keystone-manage db_sync with multiple sql backends?
18:57:01 <ayoung> gyee, his is, right now, only LDAP
18:57:09 <dolphm> ayoung: agree, that's certainly a benefit for devs
18:57:26 <dolphm> ayoung: i don't want to inconvenience deployers at all in the process though
18:57:30 <ayoung> dolphm, I was thinking also that we could enable extenstions in the future
18:57:36 <dolphm> ayoung: when they don't get anything out of it
18:57:44 <gyee> bknudson, especially if we are using different backends per domain, we have to make sure db_sync work correctly
18:57:51 <ayoung> so, say KDS becomes a long term supported extension, we make it a default migration when you run db_sync
18:58:02 <dolphm> gyee: eek, hadn't considered that
18:58:03 <ayoung> right now, there are no default migrations, but it doesn;t have to stay that way
18:58:06 <bknudson> gyee: or at least document what you need to do.
18:58:32 <dolphm> ayoung: what do you mean by default migrations?
18:58:49 <ayoung> gyee, if we have that, each would have a migrate_version table (or the alembic equivalent) and we would be able to query it  to see what it supported
18:59:03 <bknudson> db_sync --domain xxxx
18:59:05 <ayoung> dolphm, as of latest patch now db_syn only runs through what is in common
18:59:15 <ayoung> dolphm, and you suggested that it run through everything
18:59:21 <gyee> I mean it could get ugly if we are not careful
18:59:21 <ayoung> I am thinking of a middle ground
18:59:33 <ayoung> it will run through common, and a list of default support extensions
19:00:02 <ayoung> so, in icehouse, if we make an extension supported by default, we will run through its migrations when db_sync is run with no parameters
19:00:16 <ayoung> dolphm, this way, an extension is really 0 impact if it is not enabled
19:00:43 <dolphm> #endmeeting