17:59:16 <ayoung> #startmeeting keystone
17:59:17 <openstack> Meeting started Tue Jun 18 17:59:16 2013 UTC.  The chair is ayoung. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:59:20 <openstack> The meeting name has been set to 'keystone'
17:59:30 <ayoung> KEYSTONE!
17:59:33 <henrynash> hey
17:59:34 <dolphm_> o/
17:59:35 <spzala> Hi!
17:59:37 <bknudson> hi
17:59:39 <gyee> \o
17:59:45 <dolphm_> ayoung: lol i'm around today, btw
17:59:48 <ayoung> dolphm_, thought you were not going to be here this week
17:59:48 <mrutkows> o/
17:59:52 <lbragstad> hey
17:59:54 <dolphm_> ayoung: next two weeks
18:00:03 <dolphm_> ayoung: don't let me stop you :)
18:00:15 <dolphm_> ayoung: in fact, want to run next week's meeting as well? henrynash can do july 2
18:00:20 <ayoung> I'll keep the home fires burning
18:00:23 <topol> Hello
18:00:30 <ayoung> We'll make it work.  Henry and I can work together
18:00:34 <dolphm_> you'll also have to attend the release status meeting 3 hours after this
18:00:48 <henrynash> ayoung: indeed
18:00:50 <topol> dolph gets a vacation????  I dont remember that in the brochure...
18:00:58 <dolphm_> :(
18:01:08 <topol> not a vacation?
18:01:30 <ayoung> So looking at the agenda
18:01:32 <dolphm_> mini vacation i suppose
18:01:33 <ayoung> Reminder: Havana milestone 2 cut & API-level feature freeze July 16th
18:01:52 <ayoung> dolphm_, care to spell out exactly what we will not allow after the 16th?
18:02:13 <dolphm_> changes to the identity-api or anything that doc describes need to wait until icehouse after the 16th
18:02:29 <ayoung> dolphm_, how about configuration file changes?
18:02:45 <dolphm_> changes can still land in identity-api during milestone 3, but they should be marked as "New in version 3.2" (to go with icehouse, rather than havana)
18:02:56 <dolphm_> ayoung: config is fine
18:03:03 <dolphm_> ayoung: just a light feature freeze
18:03:28 <ayoung> OK, so just changes that would force other services or the CLI to modify how they talk to Keystone, but changes that would affect installers etc are Ok.
18:03:31 <dolphm_> non-api impacting features are still fair game in milestone 3
18:03:50 <dolphm_> ayoung: as long as they're backwards compatible changes that would affect installers :)
18:04:20 <gyee> how about API changes that are backward compatible? :)
18:04:22 <dolphm_> blueprints are targeted accordingly -- there's no blueprints targeted at m3 that affect api
18:04:23 <ayoung> dolphm_, split identity is going to have some impact there.  We can discuss if it looks like it is going to slip past H2, but right now it is looking likely to get in
18:04:28 <dolphm_> gyee: no
18:04:35 <gyee> figures
18:04:45 <ayoung> gyee, those can be 3.2, just not 3.1
18:04:55 <gyee> gotcha
18:04:57 <ayoung> I think that makes it easier on everyone
18:04:58 <dolphm_> gyee: catalog-option is milestone 2 or icehouse, for example
18:05:01 <dolphm_> optional*
18:05:02 <ayoung> Cool.  Next item
18:05:12 <ayoung> High priority bugs or immediate issues?
18:05:14 <dolphm_> ayoung: use #topic
18:05:38 <ayoung> #topic High priority bugs or immediate issues
18:05:45 <dolphm_> i'm not aware of anything new
18:05:53 <ayoung> All critical bugs have fix committed
18:06:02 <ayoung> 27 Bugs marked "High"
18:06:29 <ayoung> 5 with fix committed
18:06:47 <ayoung> 6 with "In Progress"
18:06:58 <ayoung> The rest Triaged or confirmed
18:07:08 <ayoung> keystone-manage db_sync fails updating from migrate_version 5 is incomplete
18:07:41 <bknudson1> I've done a lot of keystone-manage db_sync lately and haven't had problems
18:08:04 <ayoung> bknudson1, ISAM MySql?
18:08:10 <dolphm_> ayoung: i think that's another innodb vs myisam failure
18:08:17 <bknudson1> well, MyISAM is not working
18:08:45 <bknudson1> migration 26 fails because it tries to drop FKs that aren't there.
18:08:59 <ayoung> Right.  I have a fix for that, but need to clean it up to pass code review.
18:09:01 <bknudson1> because MyISAM doesn't suport FKs?
18:09:11 <ayoung> Need to straighten out my Postgres setup to retest
18:09:23 <dolphm_> bknudson1: ayoung: who wrote the fix to explicitly set innodb on all migrations?
18:09:25 <bknudson1> ayoung: I put a similar change into my fix for switching all tables to InnoDB
18:09:26 <dolphm_> did that merge?
18:09:34 <ayoung> https://review.openstack.org/#/c/32510/
18:09:42 <ayoung> dolphm_, no, abandoned, I need to fix
18:09:59 <ayoung> restored and rebased
18:10:00 <bknudson1> dolphm_: it's not done yet... I'm working on changing it so that the change is only in a new migration
18:10:14 <ayoung> looks like just a Pep 8 fix...
18:10:33 <bknudson1> dolphm_: and then I ran into some weird problem where migration 7 downgrade failed.
18:10:56 <dolphm_> bknudson1: do we not need both parts? fix unspecific migrations and migrate broken schemas properly in 23?
18:11:25 <bknudson1> dolphm_: but I figured that out and now it's a matter of creating the FKs that should have been there in the new migration 27
18:11:37 <dolphm_> bknudson1: ah
18:12:12 <bknudson1> dolphm_: I should have this ready by end of day.
18:12:53 <ayoung> dolphm_, the appraoch we should go with for, say, DB2 support is that we are willing to make changes to support it, but they should be changes that run for all (almost all) RDBMSs
18:13:02 <ayoung> so that the DB2 code doesn't bitrot.
18:13:14 <bknudson1> ayoung: I made that update to the DB2 migrations
18:13:33 <ayoung> bknudson1, thanks.
18:13:59 <bknudson1> ayoung: made extensive use of the constraints helper, so that's been handy
18:14:22 <ayoung> Good
18:14:45 <ayoung> Yeah, in general we should be moving duplicated code in the migrations into helpers
18:14:57 <ayoung> #topic Unified Client authentication
18:15:12 <ayoung> And yes, that is also How do we encourage the other CLI clients to use our v3 auth client class
18:15:26 <henrynash> i guessed as much
18:15:27 <nachi> i am working on a code update for broken credential schema in sqlite which is no-op in 23
18:15:29 <dolphm_> ayoung: make keystoneclient good and contribute back to other clients :)
18:15:48 <ayoung> So, jamielennox has been battling the Kerberos and X509 type auth, and what has become obvious is that each of the clients reimplement it
18:15:56 <ayoung> this is code duplication, and we should fix
18:16:08 <ayoung> one solution is to have the other clients consume the keystone client for auth
18:16:20 <ayoung> dolphm_, yes, we will do Keystoneclient first
18:16:26 <bknudson1> our users around here are also interested in having all the clis be able to do v3 auth
18:16:30 <henrynash> ayoung: so i though nova and glane use our client class?
18:16:43 <ayoung> henrynash, not in the CLI
18:16:45 <bknudson1> (i.e., use domains)
18:16:52 <ayoung> henrynash, you are thinkg middleware, and yes they do
18:17:02 <ayoung> auth_token middleware is in the client library.
18:17:25 <henrynash> ayoung: I'd swear we had a discussion on this on the mailing list and it was implied the cli's do as well
18:17:35 <gyee> keystoneclient or openstackclient?
18:17:42 <bknudson1> nova , glance, etc.
18:17:45 <henrynash> gyee: novaclient
18:18:00 <ayoung> henrynash, I had two different engineers look at it.  Let me see if I can get one of them here
18:18:11 <gyee> I thought keystoneclient is on its way to retirement no?
18:18:17 <gyee> in favor of openstackclient?
18:18:21 <bknudson1> the keystone command line utility is
18:18:29 <bknudson1> keystoneclient python lib will remain
18:18:39 <dolphm_> gyee: just the CLI
18:18:40 <bknudson1> openstack client is just the CLI
18:19:03 <gyee> i c
18:19:15 <ayoung> rcrit, you looked at the clients.  None of the other clients are useing keystoneclient that you saw, right?
18:19:41 <rcrit> I didn't look at all of them, just nova and glance
18:20:30 <martitia_> I believe cinder users keystoneclient
18:20:35 <ayoung> rcrit, and they do their own auth, right?
18:20:35 <martitia_> uses*
18:20:48 <ayoung> martitia_, thanks, good to know there is a precedent
18:21:00 <henrynash> so chmouel and joeH seems to think they use the keystone auth class
18:21:24 <rcrit> IIRC they do a lot of their own username/password handling, for example
18:21:37 <rcrit> I was looking into how to add another auth protocol and it would have required updating each client separately
18:21:39 <bknudson1> how do you pass --user-domain-id, --project-domain-id to the other clis?
18:22:16 <ayoung> bknudson1, do they even support those fields?
18:22:29 <bknudson1> ayoung: not yet, but they'll have to to do v3 auth, right?
18:22:42 <ayoung> We need to bring this up at the Overall meeting later on tonight
18:22:49 <ayoung> dolphm_, is that OK?
18:23:00 <henrynash> bknudson1, young: so I assume what has to happen is that they DO need change the command lines to get the new bits of auth info
18:23:19 <dolphm_> ayoung: bring up what, exactly?
18:23:28 <rcrit> or one passes the parser to keystone, it adds the available auth options, and returns it
18:23:34 <henrynash> …but that they should be using the v2/client or access objects from keystone client….and they need to upgrade to using v3
18:23:35 <bknudson1> henrynash: they need to change, but should they be re-architected so that they get the options from keystoneclient
18:23:53 <ayoung> dolphm_, in order to do Kerberos or X509 client auth as part of, say, nova, we need to modify their CLIs.  They should be consuming Keystone client to do that.
18:24:04 <ayoung> It will take a cross-project effort
18:24:27 <henrynash> bknudson1: oh, you want them to reuse keystone client to get the cli parameters as well (not just pass them to a keystone auth class)?
18:24:35 <dolphm_> ayoung: until keystoneclient has a way to *allow* other clients to consume options and stuff from us, there's nothing to bring up
18:24:42 <ayoung> You can always do an explicit keystone token-get and pass that to the other CLIs.
18:24:56 <dolphm_> henrynash: yeah, that's been on the community wishlist for a long time
18:25:18 <bknudson1> ayoung: good suggestion
18:25:22 <ayoung> Is there a blueprint?
18:25:38 <bknudson1> ayoung: I think Jamie Lennox recently started a bp
18:26:01 <ayoung> bknudson1, heh, I meant for the common command line stuff
18:26:02 <dolphm_> https://blueprints.launchpad.net/python-keystoneclient/+spec/consolidate-cli-auth
18:26:22 <dolphm_> openstackclient might have something documented
18:26:44 <bknudson1> dolphm_: ayoung: yes, that one.
18:26:58 <henrynash> I'm concerned if we need to wait for parameter re-use before we get Grizzly features into the other cli clients
18:27:07 <ayoung> dolphm_, so, if we do this, it is not going to be released on the Havana schedule anyway.  Is there any specific time gate to hit, or is it just "done when it is done"?
18:27:30 <dolphm_> ayoung: clients are not held to the 6 month schedule
18:27:48 <ayoung> dolphm_, right, and they don't have their own schedule, either, right?
18:27:56 <dolphm_> ayoung: we've done at least two releases since grizzly shipped, for example, and i'd like to do another in the next week or two
18:28:00 <dolphm_> ayoung: no
18:28:31 <ayoung> OK, so once we get something reasonable into Keystone, we can start working with one project at a time to get them up to speed on it
18:28:37 <dolphm_> ayoung: ++
18:28:52 <henrynash> dolphm_, ayoung: you mean, once we have v3 auth in keystone client….?
18:29:03 <ayoung> henrynash, that, too
18:29:11 <bknudson1> some of this could be done in parallel.
18:29:17 <dolphm_> henrynash: yeah, i'd like to release keystoneclient 0.3.0 when that happens
18:29:27 <henrynash> dolphm_: ++
18:29:30 <bknudson1> keystoneclient could provide the cli options and we add v3 when ready
18:29:31 <ayoung> #link https://review.openstack.org/#/c/21942/
18:29:37 <ayoung> Is that sufficient?
18:30:15 <dolphm_> ayoung: i haven't done a full review, but yes.. when that merges and no one screams, i'll tag v0.3.0
18:30:16 <henrynash> dolphm_,a young: then I would suggest novaclient and glanceclient in that order
18:30:26 <bknudson1> I'm thinking we can merge 21942... I haven't looked at it since my last comment.
18:30:46 <ayoung> So if we make this work for Keystone client, we probably should do the work for Glance and Nova in parallel, to make sure that the code is organized to support them for Kerberso, etc.
18:31:11 <ayoung> Ready to move on, then?
18:31:32 <dolphm_> bknudson1: to review that change, i'm just going to write something like sample_data.sh in python based on the v3 api
18:31:43 <ayoung> dolphm_, +1
18:32:17 <topol> yay v3 samples
18:32:26 <ayoung> #topic Using CADF for notification framework
18:32:30 <dolphm_> ayoung: i'd pick a single client to pick on integrating with first, and then once that merges, you can point all the other client contributors back to it and say "we want to do this to your client next"
18:32:32 <bknudson1> dolphm_: I'll take a quick look at it again, too.
18:32:39 <ayoung> dolphm_, sounds good
18:32:55 <topol> +1 on CADF
18:33:00 <lbragstad> #link https://wiki.openstack.org/wiki/Ceilometer/blueprints/support-standard-audit-formats#Provide_support_for_auditing_events_in_standardized_formats
18:33:14 <mrutkows> Hi, Matt Rutkowski here as bp submitter if there are any questions
18:33:35 <ayoung> mrutkows, what will the impact be on Keystone?
18:33:48 <bknudson1> so since we're looking at implementing notifications, seemed useful to have a standard format for the messages (e.g., CADF)
18:34:05 <ayoung> The wonderful thing about standards...
18:34:16 <mrutkows> in the ref. blueprint, our Havana goal was to establish a notification path thru Ceilometer that would allow us to audit any openstack component's APIs, starting with Nova, but after connecting with Henry, Brant and Lance we see that our work could be used beyond just the Nova component...
18:34:50 <lbragstad> whcih would mean more oslo-incubator work
18:35:00 <mrutkows> We understand that our filter would have to work with keystone as it has other things that may need to be logged
18:35:23 <ayoung> mrutkows, so the primary thing I can think of that should be common is audit logging the policy layer
18:35:31 <ayoung> I assume that would be done in common
18:35:59 <mrutkows> ayoung, yes our goal would be to take the audit filter to common
18:36:03 <ayoung> for notifications like we are talking about in Keystone, where we want to tell other services that a project has been deactivated, does it apply?
18:36:09 <mrutkows> as soon as we veryf it works with keystone APIs
18:36:47 <ayoung> mrutkows, so, what would have to change in Keystone?
18:36:49 <mrutkows> ayoung, yes, in fact it was our hope to log/audit keystone / security events
18:37:18 <henrynash> ayoung, mrutkows: think you are talking at cross purposes on "common", I think young meant you modify the openstack/common/policy engine to log those events
18:37:41 <topol> mrutkows, CADF just provides a common fomat. What does the actual notifying? ceilometer?
18:37:52 <dolphm_> topol: +1
18:37:55 <mrutkows> ayoung, I need to work with Brant and Lance, but as long as we can remain a common middleware filter/notifier, hopefully nothing will need to change
18:38:13 <ayoung> topol, I would think it would be "put a message in this format onto a specific queue" from Keystone's perspectiv
18:38:21 <lbragstad> wouldn't the notifier have to be implemented in each project from oslo-incubator?
18:38:35 <mrutkows> the CADF format is coded under Ceilometer and the audit middleware filter uses it and has an established "audit" message type
18:38:36 <dolphm_> i'm confused on if this is a solution to supersede bp notifications or not
18:38:48 <ayoung> mrutkows, please come up with a non-eventlet based approach.
18:38:51 <dolphm_> https://blueprints.launchpad.net/keystone/+spec/notifications
18:39:02 <bknudson1> dolphm_: I don't think it's superceding, it's picking the format for the notifications
18:39:04 <dolphm_> or if this is just a desired format for notifications
18:39:25 <mrutkows> dolph, it is a normative standard format
18:39:38 <bknudson1> because the blueprint doesn't specify a format
18:39:46 <mrutkows> that other cloud providers or companies can also use
18:40:08 <dolphm_> fair enough, but bp notifications currently blocked and won't land in havana, so what's the goal for discussion today?
18:40:13 <ayoung> I think what I am concerned about is populating the fields of the log message.  If all of that can be deduced from a simple LOG.error, fine.  Need to parse that spec to see if the places we need to log will need  to provide additional info and where that info comes from
18:40:29 <ayoung> mrutkows, in your experience, how hard is it to come up with the data for a log point?
18:40:35 <ayoung> notification point
18:40:40 <topol> mrutkows, so what folks are trying to figure out is do they still have to use some queue capability and all you provide is a std format or do they leverare ceilometer to get the queue capability
18:40:56 <mrutkows> ayoung, happy to have a side call to review what CADF has in it
18:41:10 <mrutkows> it is extensible
18:41:14 <topol> comes down to what can celilomter provide us infrastrcuture wise
18:41:16 <ayoung> mrutkows, is is simple
18:41:23 <ayoung> topol, look at the link
18:41:47 <ayoung> What, when, Who, OnWhat, Where, FromWhere, ToWhere.
18:41:58 <gyee> there
18:42:10 <ayoung> I'm less worried about extending it as making is simple to fill out that data
18:42:27 <mrutkows> it was designed by security architects from many companies to be ISO/NIST audit compliant
18:42:36 <ayoung> mrutkows, so a simple "how to guide" for that will be helpful.
18:42:37 <mrutkows> along with other audit frameworks
18:42:46 <dolphm_> topol: ++
18:42:53 <mrutkows> ayoung, +100, need time...
18:42:54 <topol> ayoung, just did. It mentions leveraging CADF. +1 on that. I was curious if ceilometer plays a role here or not. looks like no
18:43:14 <mrutkows> my daughter gets married this weekend so am out for a week or so
18:43:28 <ayoung> topol, more likely Keystone produce events, and ceilometer plays middleman.
18:43:34 <ayoung> Mazel Tov
18:43:36 <topol> mrutkows, congrats
18:43:55 <mrutkows> ayoung, agree, the api path can be a good start
18:43:59 <gordc> ayoung, yep, ceilometer will just listen for the event notifications similar to how it does with other projects.
18:44:01 <topol> ayoung, agreed!
18:44:03 <mrutkows> and the notifier can be called apart from the filter
18:44:06 <ayoung> Ok...good stuff.  Moving on
18:44:17 <topol> do we have a BP thats shows how everything fits together?
18:44:20 <ayoung> #topic Gyee's patch
18:44:28 <ayoung> yes, I am taking liberties, but we are running out of time
18:44:45 <ayoung> #link https://review.openstack.org/#/c/29021/
18:45:06 <gyee> ayoung, the pluggable token one? sure I can break it up if you guys can't review that much code
18:45:07 <ayoung> This is, I think, pretty important to get in, but I have concerns about its, let say "reviewability"
18:45:15 <gyee> just have had the time the last few days
18:45:18 <gyee> haven't
18:45:19 <ayoung> of course
18:45:48 <gyee> whatever make you happy boss :)
18:46:07 <bknudson1> gyee: I started looking at it but it's hard to get enough time to get through it all.
18:46:19 <ayoung> gyee, so aside from any bug fixes that slipped in there, like the JSON policy one that can be split out stand alone
18:46:28 <gyee> bknudson1, I can break it up into chunks as ayoung suggested
18:46:40 <ayoung> I'd like to see the reordering that does no functionality change as a stand alone
18:46:57 <ayoung> Does't really matter the size so long as we can say "It should behave the same before as after"
18:47:17 <gyee> ayoung, yeah, I will have to get the dependencies correct
18:47:30 <gyee> like v2 changes depends on v3 changes, etc
18:48:23 <ayoung> gyee, sounds good.
18:48:39 <gyee> ayoung, thanks for bring it up
18:48:48 <ayoung> gyee, I know jamielennox looked at it, in the context again of the Kerberos stuff, trying to make sure we only have to get it "right" at one point
18:49:03 <ayoung> #topic Get /catalog behaviour in opt-out of service catalog blueprint
18:49:19 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/catalog-optional
18:49:27 <dolphm_> (i think i answered this one in the bp?)
18:49:27 <gyee> is everybody OK with requiring token for GET /catalog?
18:49:35 <gyee> sounds like an easy decision
18:49:44 <ayoung> assigned to guang yee, but I suspect you do not have bandwith for it
18:49:51 <ayoung> can someone else p[ick it up?  topol?
18:50:06 <[1]fabio> I am already working on it
18:50:06 <gyee> I know simo was having some concern last week about requiring token for GET /catalog
18:50:20 <topol> ayoung, what needs picked up?
18:50:27 <ayoung> topol, you too slow
18:50:31 <gyee> ayoung, fabio is working on it
18:50:33 <ayoung> [1]fabio, status?
18:50:42 <topol> indeed
18:50:45 <gyee> I think he should have a review ready this week
18:50:56 <[1]fabio> I have implemented the part that removes the catalog from the token request
18:51:13 <[1]fabio> and I asked clarifications for the get /catalog part
18:51:29 <[1]fabio> so now that we have consensus I will continue
18:51:35 <ayoung> what is your launchpad id [1]fabio ?
18:51:39 <[1]fabio> hopefully get something by next meeting
18:52:03 <dolphm_> cool
18:52:22 <ayoung> I'll update the BP
18:52:33 <ayoung> #topic High priority code reviews
18:52:41 <ayoung> Role assignment API w/ inheritance
18:52:48 <henrynash> OK
18:52:51 <ayoung> #link https://review.openstack.org/#/c/29781/
18:52:59 <dolphm_> (i'd like to make this a permanent feature on the meeting agenda, btw)
18:53:20 <gyee> +1
18:53:42 <atiwari> not a bad idea
18:53:53 <[1]fabio> ayoung: my full name in launch pad is Fabio Giannetti
18:53:55 <bknudson1> is this just a list of reviews to look at?
18:53:56 <ayoung> OK, so this one is getting attention. Anything more need to be said?
18:54:00 <henrynash> so as everyone (should) know, this bp is the "stepping stone" one…assuming we can't get the whole "role assignment as a 1st class entity)_ in in time
18:54:00 <gyee> henrynash, I am fine with implementing the proposed APIs as extension for now and revisit role-assignment in icehouse
18:54:20 <atiwari> gyee +1
18:54:43 <[1]fabio> gyee +1
18:54:49 <henrynash> however, while this one might be ok as an extension, the other one probably should be core
18:54:51 <ayoung> [1]fabio, you are officialy on the hook!
18:55:01 <ayoung> henrynash, the other one being...
18:55:13 <[1]fabio> ayoung: Ok, thanks :-)
18:55:14 <atiwari> yes, I think that one is aling with role-assignment
18:55:26 <henrynash> https://review.openstack.org/#/c/32394/
18:55:36 <henrynash> #link https://review.openstack.org/#/c/32394/
18:55:50 <henrynash> this is a replacement api for the two broken ones
18:56:10 <henrynash> …to find out what role assignments a user/project/domain has
18:56:25 <gyee> henrynash, +1 on https://review.openstack.org/#/c/32394/
18:56:35 <ayoung> OK,  will look at both of them.  4 minutes remainint
18:56:36 <henrynash> This should be core, I think, (agreed the inheritance bit would only be active with the extesinsion)
18:56:48 <gyee> that one is very useful
18:57:14 <atiwari> henrynash +1
18:57:18 <ayoung> #topic Open discussion
18:57:46 <bknudson1> Does the keystone server advertise its version?
18:57:46 <gyee> henrynash, role-assignment or role_assignment?
18:57:52 <ayoung> bknudson1, yes
18:57:55 <gyee> dash or underscore
18:57:58 <bknudson1> so that a user knows that /role-assignments is available?
18:57:59 <ayoung> you can get the versions from the / url
18:58:06 <henrynash> gyee: hmm, good point
18:58:12 <ayoung> well, the version of the APIs that it supports
18:58:15 <bknudson1> so it'll say 3.1 in H?
18:58:17 <mordred> so - weird 'bug' for you guys that I haven't really been able to sort out
18:58:35 <dolphm_> bknudson1: yes, GET /
18:58:43 <mordred> apparently, attempting to run keystone unittests via tox on a  devstack node fails
18:58:43 <henrynash> gyeeL your view?
18:58:47 <mordred> that makes NO SENSE of course
18:58:48 <dolphm_> gyee: dashes
18:58:59 <henrynash> dolphm_, gyee: ok
18:59:01 <mordred> but I figured I'd toss it you guys' way in case anyone gets bored
18:59:01 <ayoung> mordred, I'll look after the meeting
18:59:10 <gyee> dolphm_, ok that's fine, just want to make sure
18:59:16 <mordred> ayoung: I can come up with zero reasons why it should matter
18:59:33 <bknudson1> mordred: what fails?
18:59:36 <ayoung> mordred, its code, not magic.  Much as they may appear similar
18:59:38 <gyee> mordred, which bug?
18:59:53 <dolphm_> mordred: details?
18:59:56 <henrynash> gyee, dolphm_: ok, i;ll redraft both of those bps with the extension in mind for inheritance and the GEt role-assignments in core
19:00:05 <bknudson1> fetching the old clients? that's a weird thing keystone does.
19:00:07 <ayoung> BTW, I need a re-review of the LDAP Shim b gone patch, as I had to reduce it a little in scope upon rebase
19:00:10 <mordred> dolphm_, bknudson1, ayoung, gyee: anteaya ran in to it
19:00:14 <gyee> henrynash, sounds good
19:00:18 <atiwari> how about /roleAssignment
19:00:20 <mordred> and I dont think it fails anywhere obviously like fetchin gthings
19:00:21 <ayoung> henrynash, bknudson1 gyee dolphm_, can you take a look
19:00:28 <atiwari> no dash no underscore
19:00:28 <dolphm_> https://bugs.launchpad.net/keystone/+bug/1191999 ?
19:00:29 <anteaya> o/
19:00:30 <uvirtbot> Launchpad bug 1191999 in keystone "unittests should not require internet access" [Undecided,New]
19:00:33 <mordred> anteaya: have you filed a keystone bug about the test failures?
19:00:39 <ayoung> ah, henrynash alread -1ed.  Cool
19:00:41 <ayoung> OK,  times up
19:00:44 <dolphm_> atiwari: no
19:00:47 <ayoung> #endmeeting