18:00:58 <henrynash> #startmeeting keystone
18:00:59 <openstack> Meeting started Tue Jul 30 18:00:58 2013 UTC and is due to finish in 60 minutes.  The chair is henrynash. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:02 <openstack> The meeting name has been set to 'keystone'
18:01:16 <bknudson> hi
18:01:23 <topol> Hi
18:01:37 <henrynash> ok, first off reminder that Havana m3 cut in Sept 4th
18:01:37 <ayoung> all present and accounted for
18:01:53 <henrynash> #info Havana m3 cut in Sept 4th
18:02:24 <henrynash> is anyone working on a bp that ISN't already tagged as heading for m3 ?
18:02:37 <ayoung> hmm , I may be
18:02:38 <henrynash> (i.e. they are expecting it to land for m3_
18:02:39 <bknudson> henrynash: yes...
18:02:43 <ayoung> multi repos
18:02:43 <bknudson> https://blueprints.launchpad.net/openstack/?searchtext=user-locale-api
18:02:58 <ayoung> #link https://launchpad.net/keystone/+milestone/havana-3
18:03:19 <bknudson> #link https://blueprints.launchpad.net/keystone/+spec/user-locale-api
18:03:42 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/multiple-sql-migrate-repos
18:03:51 <henrynash> #action all to make sure any bps they are planning for m3 are tagge as such
18:04:06 <ayoung> henrynash, ^^ should be a prereq for any extensions going in that need sql schema updates\
18:04:10 <henrynash> that way, we'll have a good picture as we burn down
18:04:11 <bknudson> henrynash: Is that something I do myself?
18:04:46 <henrynash> bknudson: as core, yes you can do that (Dolphm might change it…but you should set it)
18:05:19 <bknudson> henrynash: that was easy
18:05:33 <henrynash> ayoung: re we targeting the sql migrate at Havana…thought i saw a discussion about it going to iceHouse?
18:05:44 <henrynash> bknudson :-)
18:05:58 * topol sql migrate seems scary
18:06:02 <morganfainberg> ayoung / henrynash: I'm going to write up an updated BP based upon my conversations w/ dolph about caching layer instead of the revocation-list caching
18:06:20 <morganfainberg> henrynash / ayoung: this should be tagged for h3
18:06:46 <bknudson> caching revocation list makes sense since it doesn't change that much
18:07:14 <morganfainberg> bknudson: the revocation-list caching will be implementing the same way.
18:07:25 <henrynash> morganfainberg: Ok, but get it in their quick so you can get comment….as the clock ticks down we'll not want too many new Bps flowing in
18:07:35 <morganfainberg> henrynash: i'll write it up today.
18:07:43 <henrynash> ayoung: back to migrate, so you are planning this for m3?
18:07:47 <topol> morganfainberg, no API changes required for that?
18:07:53 <henrynash> morganfainberg: thx
18:08:10 <gyee> we should fix migrate in m3
18:08:22 <morganfainberg> topol: no.  it'll be just caching on top of current driver/manager calls
18:08:38 <morganfainberg> topol: and config options to make it functional.
18:08:43 <topol> morganfainberg. cool. I look fwd to reading the BP
18:08:53 <morganfainberg> topol: nod.
18:08:56 <gyee> morganfainberg, you caching it at the driver level?
18:08:58 <ayoung> henrynash, yes
18:09:04 <ayoung> henrynash, migrtate should go in ASAP
18:09:07 <henrynash> gyee: fix, as in fix anything we have broken?
18:09:20 <ayoung> henrynash, the Alembic migration should wait until icehouse
18:09:25 <morganfainberg> gyee: there is a WIP that dolph put up as an example. it'll work a lot like that
18:09:28 <gyee> henrynash, we need to get migration straighten out ASAP
18:09:40 <ayoung> morganfainberg, you mean the one I did?
18:09:48 <topol> besides the Alembic migration what are you referring too?
18:09:52 <morganfainberg> ayoung: you did that and dolph posted it?
18:09:56 <henrynash> gyee: are you referring to young's patch, or just tables we have mucked up
18:10:04 <ayoung> topol, migrations for extensions in their own repos
18:10:10 <gyee> henrynash, sorry, I mean migration for the extensions
18:10:11 <ayoung> I'll post an example here in a second
18:10:19 <henrynash> guee: Ok
18:10:21 <morganfainberg> ayoung: https://review.openstack.org/#/c/38866/
18:10:30 <morganfainberg> using dogpile.cache
18:10:34 <topol> ayoung, I remember you mentioning those. I thought they were tied to Alembic migration..
18:10:46 <gyee> dogpile? w00t!
18:10:52 <morganfainberg> gyee:  :)
18:11:08 <henrynash> ok, so let's get the meeting back to an agenda!
18:11:20 <ayoung> henrynash, I am referring to https://review.openstack.org/#/c/36731/
18:11:22 <morganfainberg> yeah sorry.  didn't mean to derail.
18:11:31 <henrynash> we'll pick up discussion on the migrate items under high priority code reviews
18:11:33 <ayoung> the comments say it needs documentation
18:11:36 <morganfainberg> thought i was jumpin in ontime for h3 ...
18:11:53 <bknudson> ayoung: I'd like docs too, but can go in a separate commit.
18:12:08 <henrynash> #topic HIgh priority bugs or immediate issues?
18:12:30 <henrynash> anything hot?
18:12:47 <ayoung> No bugs marked as Critical
18:12:58 <bknudson> builds were broken by a dependency over the weekend but that's fixed.
18:13:02 <ayoung> can we change that Agenda item to "Critical Priority bugs" in the future?
18:13:04 <henrynash> ayoung: agreed…think we are Ok shape
18:13:23 * topol maybe we can all go on that hawaii vacation for m3 like I suggested before...
18:13:31 <henrynash> #action henrynash to change item to "Critical Priority bugs"
18:13:51 <henrynash> topol: there's a plan...
18:14:10 <henrynash> #topic Reducing the default token duration in support of abandoning token revocation
18:14:31 <bknudson> what do we need to cache token revocations for if we have this?
18:14:42 <henrynash> who's item is this?
18:14:52 <topol> dolphm, I believe
18:15:04 <henrynash> topol: I had a feeling someone would say that
18:15:17 <gyee> to 1 hour?
18:15:21 <topol> He wanted to start stress testing the idea of tokens expiring to see what breaks
18:15:36 <henrynash> #link https://review.openstack.org/#/c/38672/
18:15:38 <topol> I put a comment in that said, did you inform the other PTLs???
18:16:20 <ayoung> henrynash, I want to do that, but it is not in H3 time frame
18:16:22 <morganfainberg> bknudson: we still need to cache, people can ask for longer tokens.
18:16:42 <morganfainberg> and limiting the backend impact… is good.
18:16:46 <henrynash> do we expect it to break (I know if we set it to minutes it definitely breaks)
18:17:02 <topol> morganfainberg, but when you change the default and folks find out by surprise....
18:17:10 <ayoung> any work flow that lasts longer than the token duration will break.
18:17:25 <henrynash> ayoung: yep
18:17:27 <morganfainberg> topol: right. don't surprise people ;
18:17:29 <bknudson> assuming you can't get another token
18:17:37 <ayoung> But a 1 hour token duration was too long to avoid the need for revocation, according to backlash from the community
18:17:42 <topol> ayoung, I thought folks were supposed to code such that they reauthenticate if the token expires... Not true???
18:17:58 <ayoung> we need something like this
18:17:59 <gyee> ayoung, that's where to pluggable token providers come in handy, you can customize expiration base on account :)
18:18:01 <morganfainberg> topol: that was my understanding
18:18:01 <gyee> just saying
18:18:17 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/delegation-workplans
18:18:40 <henrynash> Ok, sounds like need to circle back with dolphm on this one….to see how he plans to "experiment" with this.
18:18:43 <topol> gyee, no. its a matter of correct expectations... Either we are allowed to assume folks can code properly to this or we need to back it out
18:18:48 <ayoung> that way, you can say "use this trust or oauth request token to get the token you need whne you need it"
18:19:38 <bknudson> clients need to be able to handle tokens becoming invalid for other reasons already
18:19:45 <brich1> topol: if you code such that you can re-authenticate, you risk leaving the "secret" (password) out in the clear where bad things can happen...
18:19:51 <gyee> topol, client behaves the same way, regardless of expiration policy
18:19:55 <topol> if he other projects arent ready to handle this I need to change my vote...
18:20:14 <ayoung> brich1, that is why we have ecure delgation mechanisms now
18:20:15 <gyee> if token expires, get a new one
18:20:23 <ayoung> ecure -> secure
18:20:46 <topol> ugg... forcing folks to adopt something new by changing a default that nows screws them is not how we should do this..
18:20:56 <henrynash> #action dolphm to explain approach to rolling this out and discussion with other projects
18:21:00 <ayoung> topol, they will just change it back in the puppet module anyway
18:21:09 * topol need to go change my vote
18:21:26 <henrynash> #topic High priority code reviews
18:21:35 <gyee> topol, if client code is so depended on the default expiration, something is fundamentally wrong
18:21:38 <ayoung> Client reviews!
18:21:39 <henrynash> ok, so what's in most need of pushing ahead
18:21:40 <topol> ayoung, yeah after getting pissed off at us
18:21:56 <ayoung> As jamielennox's daytime voice, I need to push people to do more client reviews
18:22:00 <ayoung> fear not the client
18:22:05 <bknudson> those client reviews are always so scary because everybody seems to want to rewrite it.
18:22:09 <ayoung> heh
18:22:38 <henrynash> ayoung: ok, so migration,
18:22:43 <ayoung> I have a WIP to show
18:22:51 <ayoung> #link https://review.openstack.org/#/c/39351/
18:22:57 <ayoung> this is based on simo'
18:23:00 <ayoung> s kds patch
18:23:10 <topol> gyee, either we have a plan for success for our stakeholders for using shorter token expiration or we dont. sounds like we dont
18:23:21 <ayoung> topol, Icehouse
18:23:52 <topol> ayoung, K. then change default *in icehouse*
18:24:03 <gyee> topol, I am more worried on other issues, like performance
18:24:04 <ayoung> on migrations, the question is whether I should contineu on with the sql migrations as is, or wshould we do the alembic move before we split out the extension repos
18:24:17 <ayoung> I think that Alembic support is going to require some thinking
18:24:19 <henrynash> topol, gyee: have set action for dolphm to come back with the plan….let's move on
18:24:21 <morganfainberg> ayoung: i am for doing the migration work now.
18:24:26 <ayoung> and I don't really want to force that through
18:24:26 <henrynash> ayoung: agred
18:24:31 <ayoung> morganfainberg, I do to
18:24:37 <topol> ayoung, avoid death or glory. go crawl walk run
18:24:38 <morganfainberg> and hit alembric in Icehouce
18:24:48 <topol> morganfainberg +1
18:25:02 <ayoung> dolph had the objection, so if we drive on, we have to be ready to convince him when he comes back.  Do we have unanimous support for it?
18:25:21 <topol> support for doing it in stages???
18:25:26 <bknudson> I think his problem was that we now have to do alembic on multiple repos
18:25:26 <henrynash> ayoung: I'd just like clarification of how a "complex" extension work work with a separate repo?
18:25:34 <ayoung> topol, for doign the migrations per extension in the existing technology
18:25:42 <ayoung> henrynash, see the above link
18:26:15 <topol> ayoung, yes that to me means stages.  Unless thatmakes alembic 10 times harder later...
18:26:15 <ayoung> henrynash, the short of it is you need a migrate_repo subdir, a versions subdir under that, a config file, and a couple empty __init__.puy files
18:26:21 <gyee> ayoung, is alembic required for separating out the extension migration?
18:26:21 <henrynash> ayoung: so I posted a question on patch 11 to this end
18:26:30 <bknudson> if we have multiple repos and have alembic, we have to decide how we're going to do the sqlalchemy -> alembic change.
18:26:53 <ayoung> henrynash, yep,. just got to the point that I had one to show, and I will convert that to documentation in both the commit message and in the doc dir
18:27:19 <ayoung> bknudson, we need to do that anyway, and I think the migration will be no more complex with or without the split
18:27:30 <ayoung> gyee, alembic is not required
18:28:00 <gyee> ayoung, I would vote for getting the extension migration done first
18:28:01 <bknudson> ayoung: ok, I don't know how the sqlalchemy -> alembic migration works. Other projects always have a point where they consolidate migrations
18:28:04 <henrynash> ayoung: my question is much more fundamental…my initial reaction is that complex extensions will no long rbe possible since we won't have the DB changes sequenced with core…any sometimes I think you need to….so I am yet to be convinced over the whole approach
18:28:07 <ayoung> gyee, doing alembic support after the split means that we will have to deal with multiple migrate repos in the conversion, but that should be only slightly more complex than what we are doing now
18:28:12 <bknudson> but keystone hasn't done that (consolidation)
18:28:32 <ayoung> henrynash, if an extension needs to talk to the db, and change the core schema, it  can still do that in common
18:28:44 <ayoung> we just should not allow that in a review with out serious justification
18:28:44 <henrynash> ayoung: I'd suggest we need a better BP that explains what will and won't be possible…like before we start coding it
18:30:03 <ayoung> henrynash, extension , by definition, are defined to be split out from the main keystone server.  I don't want any more extesnions going in until we resolve this
18:30:15 <morganfainberg> ayoung:  +1
18:30:25 <ayoung> henrynash, credentials should have had its own repo, hell, Identity and token stuff should be in their own repos
18:30:39 <ayoung> catalog and policy should certainly be in their own repos, too
18:30:50 <gyee> ayoung, amen brother
18:31:40 <ayoung> So, henrynash do you really think an extension should be allowed to communicate with the underlying sql schema?
18:32:02 <henrynash> ayoung: so i get those suggestions….I thought the primary point of an extension was to allow API changes that we are not necessarily committing to support long ter,
18:32:11 <gyee> ayoung, you sure you didn't work on OSGi before?
18:33:09 <gyee> henrynash, having sql-specific schema dependencies is pretty messy
18:33:27 <gyee> especially we are supporting different backend drivers
18:33:36 <ayoung> gyee, I've worked on everything before
18:33:56 <henrynash> ayoung: I (think what I ) am advocating is that often an extension might need to change a core schema.  The schema change might be done in core (and not part of the extension) as long as it is benign….but "private" sql extension changes would be in their own repo
18:34:01 <morganfainberg> gyee: yes, it makes sense especially with the pluggable nature/mutiple backends.
18:34:45 <ayoung> henrynash, I would argue that if you are modifying a set of tables, all the changes to those should be in a single repo.  Extensions *can* and *should* have their own sql repos, but because some extensions are already munged into the common repo, we can't make that a *must* at least not yet
18:34:45 <henrynash> ayoung: otherwise I don't see how our dependencies will work, we'll break extensions at the drop of a hat
18:35:31 <ayoung> henrynash, so, the rule is "no new extension that requires a new sql schema goes into the common repo"
18:35:33 <bknudson> henrynash: we should have unit tests to ensure extensions work
18:35:55 <gyee> bknudson, at the minimal
18:35:59 <ayoung> bknudson, and those will be part of the sql upgrade test with that extensions patch
18:36:24 <bknudson> and we need a real sql in the gate
18:36:28 <henrynash> ayoung: so I'm not arguing that should not be able to have a repo….I'm just skeptical it is the right solution for all extension (in the future) to be wholly contained within their repo
18:36:47 <morganfainberg> yes, real SQL in gate (or something that emulates it cleanly) is important.
18:37:30 <ayoung> henrynash, it is a code standard, but one that we can address when the time comes.  For example, the ec2 extensions are currently based on code in the common repo.  THat won't be broken by this
18:37:37 <topol> do we expect to have enough extensions in the future to merit supporting multiple repos?
18:37:42 <ayoung> henrynash, it just provides a missing mechanism
18:37:44 <ayoung> topol, yes
18:37:49 <ayoung> topol, 3 have 3 right now
18:37:51 <ayoung> kds
18:37:53 <ayoung> mapping
18:38:03 <ayoung> oauth
18:38:11 <topol> everybody loves adding to our database...
18:38:20 <gyee> ayoung, don't forget endpoint filtering
18:38:26 <henrynash> ayoung: and that's my point, I don't see where we have planned out how different types of extensions will work….I really want to see it described how the dependencies will work, be obvious to those working on core etc.
18:38:27 <bknudson> so today an extension can't really count on the identity sql, since identity could be ldap.
18:38:29 <ayoung> gyee, make that four
18:38:34 <ayoung> bknudson, right
18:38:36 <gyee> pho for pho!
18:39:08 <henrynash> ayoung: you probably have it all worked out….I just need to be able read it and think through how it would work in practice
18:39:17 <ayoung> henrynash, fair enough.
18:39:38 <ayoung> #action ayoung to properly document split repos as part of the patch
18:39:43 <henrynash> ayoung: if you could do that, it would be great
18:39:49 <henrynash> thx
18:39:56 <henrynash> Ok, other high priority code reviews
18:40:08 <bknudson> one thing we might need is a more extensible way to notify extensions of events.
18:40:22 <bknudson> more comprehensive might be a better word
18:40:47 <gyee> bknudson, can you translate that in plain english?
18:40:49 <henrynash> bknudson:  do we ahem any way implemented today?  I didn't think so?
18:41:11 <ayoung> bknudson, that statement scares me
18:41:35 <bknudson> more of a thought, but you use foreign keys for example to delete rows from a table when the user goes away.
18:41:37 * topol plz be thinkijng of something lightweight :-)
18:41:43 <bknudson> and now we don't have foreign keys for that.
18:41:59 <bknudson> so some way to tell an extension that the user has gone away and it should clean up.
18:42:04 <ayoung> bknudson, LDAP does not notify anyway
18:42:10 <ayoung> users never "go away"
18:42:23 <ayoung> now, projects, OTOH,
18:42:27 <bknudson> users was an example... not sure if there's another one.
18:42:36 <ayoung> roles get removed, and tokens get revoked
18:42:51 <ayoung> integration happens at the component to component level
18:43:21 <topol> does openstack have a common event listening mechanism?
18:43:36 <bknudson> we've got a discussion of notifications later on the agenda already.
18:43:38 <gyee> bknudson, you thinking of an internal message queue or something?
18:43:41 <ayoung> wirth extensions, we should try to keep integration to a minimum.  Ideally, different extensjhions should be able to run on different servers, and Keystone can then just act as a n incubatoer for new services with them all living in a single server
18:44:10 <bknudson> gyee: yes, it could be through an internal mechanism to register for events.
18:44:40 <henrynash> bknudson: Ok, think we need to table that topic, to make sure we get through the agent - maybe add it to next week?
18:44:45 <topol> anyway we can avoid not invented here and rolling our own for this???
18:44:57 <henrynash> any other high priority reviews?
18:45:16 <henrynash> probably a bit early in the cycle
18:45:16 <ayoung> Implement apiclient library
18:45:21 <henrynash> ayoung: ahh!
18:45:26 <ayoung> https://review.openstack.org/#/c/28043/
18:45:30 <henrynash> ayoung: indeed
18:45:38 <ayoung> we need to solve the common authentication mechanism problem
18:45:48 <bknudson> it's only 3000 lines
18:45:57 <ayoung> heh
18:46:03 <bknudson> seems like common authentication mech wouldn't take 3k loc
18:46:04 <topol> with lots of -1s to boot
18:46:21 <ayoung> agreed, so what do we do about moving this ahead?
18:46:26 <ayoung> I think we need to work with him
18:46:42 <ayoung> but scope down this into multiple, independent blueprints
18:46:50 <ayoung> with auth being the highest priority
18:46:54 <morganfainberg> ayoung: +1
18:46:57 <bknudson> ayoung: +1
18:46:58 <gyee> ayoung +1
18:47:07 <henrynash> ayoung: are any clients "signed up" to use such a think…or is it that if build (we hope) they shall come?
18:47:18 <topol> does ti have stakeholders lined up? Will folks jump to this once its avail or say, what I have works... leave me alone?
18:47:27 <bknudson> so novaclient already has this plugin mechanism
18:47:28 <ayoung> henrynash, I think cinder already pullins the keystone client
18:47:35 <ayoung> I know at least one client does,
18:47:45 <henrynash> ayoung:I think that is true, yes
18:48:40 <ayoung> henrynash, it is in cinder's pip-requires but not in python-cinderclient
18:49:09 <ayoung> glance has it , though
18:49:13 <henrynash> ayoung: ahh. that might be just that it wants the middleware
18:49:36 <ayoung> https://github.com/openstack/python-glanceclient/blob/master/requirements.txt#L6
18:50:14 <bknudson> all the clients will need keystoneclient to get a token
18:50:26 <ayoung> bknudson, they do direct calls right now
18:50:57 <topol> the safe thing to do would be to confirm what the stakeholders really need in this space, that they are willing to move to the new code base and to make sure the 3000 lines are trimmed down to deliver only what the stakeholders need.  could waste a lot of time if not real agile dvelopment is used on this one
18:51:03 <bknudson> ayoung: oh, so we've got some work ahead of us!
18:51:09 <ayoung> bknudson, so we want them to consume the python-keystoneclient in order to manage how the authenticate both when they get a token and when they pass that token to aremote service, assuming the remote services can handle SPNEGO or CLient certs.  Down the road of course
18:51:52 <henrynash> #action cores (at least) to take some the to work on this issue this week…..
18:52:00 <ayoung> bknudson, yeah, I would say so, and it is going to take some joint engagement.  Thus, the first challenge to the core devs is to get comfortable with the client code, and get a common vision of how it should look and work.
18:52:19 <henrynash> we need to make progress or we still won't have a v3 nova client by Havana ship
18:52:25 <henrynash> v3 auth
18:52:49 <gyee> henrynash, who's working on this?
18:52:50 <ayoung> We need to work with the other projects to up the minimum version, too
18:53:04 <gyee> ayoung, what kind of help you need from on this front?
18:53:06 <ayoung> we should be able to use the latest keystone client in all projects
18:53:27 <topol> ayoung, +1 and if not to understand why not
18:53:28 <ayoung> gyee, jamielennox has been working on it
18:53:37 <henrynash> young, guee: so I raised this at the project meetinga few weeks ago (when deputising for Dolphm) and the reaction was…use the mailing list!
18:53:57 <ayoung> henrynash, or submit patches
18:54:02 <gyee> henrynash, yup
18:54:02 <henrynash> ayoung: always better
18:54:07 <gyee> just do it
18:54:32 <henrynash> young, gyee: ..and I coming round to thinking that this is what we must do
18:54:48 <gyee> henrynash, yes, we'll have to write the code
18:55:16 <henrynash> gyee, ayoung, bknudson: let's chat after the meeting on this one
18:55:24 <bknudson> henrynash: ok
18:55:34 <henrynash> #topic Oslo unified logging patch landing soon? (https://review.openstack.org/#/c/34834/)
18:55:41 <lbragstad> #link https://review.openstack.org/#/c/34834/
18:55:48 <topol> gyee, plz find a stakeholder from each project that needs to adopt.  My rule of thumb would be if you cant get a stakeholder its a recipe for a waste of time..
18:56:00 <ayoung> henrynash, I'll OK the approach once we are certain it doens't mess up apache
18:56:15 <lbragstad> hoping that this lands soon, and this change was purposed for keystone a while ago to implement a unified logging solution but concerns were raised about eventlet
18:56:34 <gyee> topol, sure, make sense
18:56:44 <lbragstad> just wanted to give everyone a heads up on this, and once it lands in Oslo I'll plan to implement the unified logging solution to keystone
18:56:52 <bknudson> so do we want to wait for the oslo change before we get notifications or stick with where we were before?
18:57:11 <ayoung> bknudson, does it require changes to the config file?
18:57:27 <henrynash> lbragstad: and the question of apache?
18:57:36 <ayoung> If so, that breaks the feature freeze rule.  Otherwise, I am OK with it going in to H3.
18:57:37 <lbragstad> jsut about to test it in apache.
18:57:41 <lbragstad> henrynash: ^
18:57:49 <bknudson> ayoung: do notifications require changes to the config file? I'm sure there's config options to tell it what notifier to use.
18:57:57 <lbragstad> yes
18:58:01 <ayoung> lbragstad, can you file that as an Agenda item for next week, then, to make sure we close it on out?
18:58:02 <lbragstad> ayoung: bknudson^
18:58:11 <ayoung> bknudson, optional changes are OK
18:58:11 <lbragstad> #link http://docs.openstack.org/trunk/openstack-network/admin/content/ch_adv_notification_overview.html
18:58:18 <ayoung> bknudson, required changes are not
18:58:19 <henrynash> ayoung: I didn't think changes to config file where verboten…just that we can't break anything that is in there already
18:58:36 <bknudson> right, it has to have a sensible default.
18:59:05 <ayoung> henrynash, think of it as an integration problem.  API's are fixed to keep from breaking iother apps.  Config files are fixed to keep from breaking the puppet modules and installers
18:59:44 <bknudson> people are going to think we're on vaca in Hawaii if we don't make work by breaking other apps.
18:59:50 <ayoung> 1 minute remaining
18:59:54 <fabiog> henrynash, endpoint filter is ready for review
19:00:04 <ayoung> fabiog, add me to the review, please
19:00:04 <henrynash> ayoung: hmm, agree we can't change existing values…take offline
19:00:08 <fabiog> #link https://review.openstack.org/#/c/33118/
19:00:20 <henrynash> #topoc open discussion !
19:00:31 <fabiog> ayoung, added
19:00:34 <henrynash> but we are out of time!
19:00:36 <topol> fabiog, dolph has a red x on it. why would we review???
19:00:47 <henrynash> #stopmeeting
19:00:54 <henrynash> #endmeeting