18:02:33 <morganfainberg> #startmeeting keystone
18:02:34 <openstack> Meeting started Tue Feb 24 18:02:33 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:38 <openstack> The meeting name has been set to 'keystone'
18:02:52 <morganfainberg> Morning all!
18:03:04 <marekd> yeah..morning :-)
18:03:29 <morganfainberg> Going to get started wth the agenda and then move on to things like what bps we need to push to liberty.
18:03:56 <morganfainberg> #topic Using short lived feature branchs
18:04:02 <morganfainberg> jogo: o/
18:04:29 <jogo> morganfainberg: you want to explain it? most of the notes are in the agenda
18:05:01 <morganfainberg> I'm going to let you present it. You did a great job summarizing it yesterday.
18:05:16 <jogo> sure
18:05:18 <morganfainberg> The notes are there. But just a quick summary and then open for discussion.
18:05:28 * morganfainberg drinks coffee.
18:06:02 <jogo> quick summary: a keystone-core can sponsor the creation of a feature branch for a blueprint
18:06:34 <jogo> the big difference with what happened previously with HMT is, the keystone core sponsor can nominate anyone they want to be core on the feature branch
18:06:36 <morganfainberg> This is a new concept to try, btw. So, open comments on it as well.
18:07:06 <morganfainberg> Before we try it that is.
18:07:16 <jogo> so the standard 2 +2 applies to the feature branch, except one of the +2s can come from a feature-branch core
18:07:27 <ayoung> Once the feature branch is "complete"  it takes standard core to merge as per normal
18:07:38 <rodrigods> I have one question: how the branch rebase against master will work? In a regular feature branch we'd need to ask a specific group to perform it
18:07:42 <dstanek> interesting - so a +2 from a core and a +2 from someone else?
18:07:46 <jogo> ayoung: yup, although the merge review should not be a full code review
18:08:06 <lbragstad> the other +2 has to be a core on the feature branch though, right?
18:08:17 <marekd> jogo: one +2 who can be a master in tat particular topic, but no necessaarilly is a Keystone core, right?
18:08:19 <jogo> lbragstad: or a regular keystone core
18:08:44 <ayoung> and then we do a merge of the feature branch, not just a rebase
18:08:53 <jogo> marekd: yes, so instead of requiring two keystone core +2s, the feature branch patches require one keystone-core +2 and another +2
18:08:56 <morganfainberg> rodrigods: any feature branch core or keystone core can do the merge from master to the topic branch , but that is a documentation / training thing to help make that easy
18:08:59 <lbragstad> so are we intending that this process takes place of our experimental phase?
18:09:01 <amakarov> interesting concept, so we want branch-owners to compete for core'ship in the future :)
18:09:07 <morganfainberg> lbragstad: no.
18:09:20 <morganfainberg> lbragstad: this would be to land the code initially. Nothing else changes.
18:10:06 <dstanek> i think this is probably a good idea, but we need to be careful at first
18:10:07 <jogo> the motivation here, is to empower people who keystone-core considers domain experts and trusts them, but who don't have enough bandwidth general keystone knowledge to be a full keystone-core at the moment
18:10:12 <lbragstad> does every spec have to follow this criteria?
18:10:19 <morganfainberg> ayoung: merge (final) to master is keystone-core only.
18:10:39 <jogo> lbragstad: no, this is a new idea and I am looking for a guinea pig
18:10:45 <lbragstad> jogo: ok
18:10:49 <marekd> jogo: makes sense.
18:11:00 <raildo_away> jogo I dont like this term :( haha
18:11:01 <stevemar> what the kind of work that would be proposed to a feature branch?
18:11:02 <rodrigods> jogo, makes sense. [2]
18:11:07 <jogo> feature branches don't make sense for things that: touch a lot of code all over the place (rebase hell) etc
18:11:17 <ayoung> jogo, you just ruled out Keystone
18:11:21 <lbragstad> I think that work flow worked well with the HTM stuff because the people maintaining it stayed on top of it
18:11:43 <marekd> stevemar: HTM for instance I think
18:11:43 <jogo> ayoung: so morganfainberg had a blueprint in mind
18:11:45 <rodrigods> the problem with the HMT feature branch was mainly the lack of reviews
18:11:51 <morganfainberg> The ae token work would be a great target (if we had this concept earlier). Ae token will not use this though.
18:11:54 <rodrigods> so it took too long to start merging
18:12:24 <rodrigods> so this short term feature branch seems a nice approach to try to improve this
18:12:24 <amakarov> rodrigods, ++
18:12:46 <raildo> rodrigods, ++
18:12:53 <morganfainberg> But the kind of work that ae token is, relatively isolated is the type of work that this makes sense for. The hmt reseller stuff might be a good one as well.
18:13:30 <rodrigods> who are the keystone-cores interested in working in it?
18:13:32 <amakarov> we need criteria how not to drown in a heap of branches
18:13:33 <rodrigods> (reseller)
18:13:47 <lbragstad> amakarov: ++
18:13:55 <jogo> amakarov: well for now the idea is to just try this once and see how it goes
18:14:23 <dstanek> jogo: so just pick one new feature branch for the initial process?
18:14:30 <marekd> like hmt
18:14:42 <jogo> dstanek: yup
18:15:00 <amakarov> jogo, I think we need at least 2, better 3 branches to see how it'll go and, more important - merge
18:15:01 <ayoung> Keystone client policy work
18:15:16 <dstanek> i don't see any reason not to try this then; we can just be extra careful on the merge for those that would be worried
18:15:17 <morganfainberg> ayoung: ++
18:15:25 <ayoung> access info
18:15:37 <jogo> amakarov: well just because one works doesn't mean its a good idea. but figure starting with 1 branch and take it slow
18:15:37 <ayoung> lets do this in the client
18:15:57 <rodrigods> this would worked with assignments split too
18:16:05 <ayoung> yep...would have
18:16:09 <lbragstad> jogo: have some other projects started this workflow?
18:16:13 <morganfainberg> rodrigods: unfortunately no. Touched too much stuff.
18:16:15 <jogo> lbragstad: no, your the first :)
18:16:21 <lbragstad> \o/
18:16:22 <amakarov> jogo, ++ for step-by-step approach
18:16:56 <morganfainberg> So the biggest concern with using a keystone server bp is we are 10 days from milestone. So I think we can't do it with server this cycle.
18:17:08 <marekd> morganfainberg: ++
18:17:12 <rodrigods> :(
18:17:13 <ayoung> Client makes more sense anyway
18:17:22 <amakarov> jogo, I just want to remind that 1 branch is not enough to approve entire concept - it's just 1st step
18:17:26 <morganfainberg> jogo: but we can do client/middleware easily.
18:17:38 <jogo> morganfainberg: good idea
18:17:48 <rodrigods> policy stuff
18:17:49 <rodrigods> ^
18:18:12 <ayoung> jamielennox, anything you can think of that would make a good topic branch in client?
18:18:53 <jamielennox> ayoung: i have a whole bunch of splitting up auth_token middleware that is isolated and in queue - it's fairly trivial though
18:19:13 <lbragstad> that sounds like a good candidate...
18:19:19 <rodrigods> k2k support?
18:19:30 <dstanek> we would need something that is being worked on my a non-core. do we have anything like that in the client?
18:19:44 <morganfainberg> dstanek: ++
18:20:00 <jamielennox> there is some HMT stuff that i need to get back to reviewing
18:20:04 <breton> Alembic ;)
18:20:17 <lbragstad> ayoung: was there anyone else driving the access info stuff?
18:20:26 <breton> I think there will be 4-5 patches regarding it
18:20:40 <ayoung> lbragstad, it was under pressure from morganfainberg , but he hasn't been actively coding it
18:20:43 <morganfainberg> Also if someone wants to do the sql migration collapse this cycle besides me, that can land post k3 and might be a good candidate for this.
18:21:09 <breton> o/
18:21:22 * breton wants
18:21:23 <ayoung> I'd be willing to hand over +2 on the access info to at least one non core
18:21:24 <morganfainberg> ayoung: yes. We still need it but we are addressing the klwt first.
18:21:39 <morganfainberg> ayoung: but that is still really important.
18:21:57 <lbragstad> ayoung: I thought david8hu was waiting on that stuff for the token provider cleanup stuff
18:22:04 <ayoung> yes, he is
18:23:16 <morganfainberg> So it doesn't make sense unless there is more than 1 non-core interested as well. If 1-non core is coding it and no one else is interested, we are limited back to core reviewers only.
18:23:28 <morganfainberg> But I think we have some candidates to work from.
18:24:03 <rodrigods> ++
18:24:06 <lbragstad> is there going to be a rebase criteria or is it just as the committer sees fit?
18:24:57 <morganfainberg> It will need to be in sync with master before t can be merged back in. Frequent rebase/ / syncs make that easier, but it would be up to the branch core team to determine.
18:25:10 <morganfainberg> Since merge commits still need review.
18:25:34 <morganfainberg> Remember ff-only does not work to sync things.
18:25:41 <rodrigods> morganfainberg, having it in the reseller stuff would somehow ease our internal process here, but we have the milestone concern
18:26:00 <marekd> rodrigods: you are a big team.
18:26:08 <marekd> and could more work face2face
18:26:09 <rodrigods> marekd, ++
18:26:26 <morganfainberg> rodrigods: correct and that is why I don't want to push it for server topics. 10 days is very limited. But I'd be willing to let it be used if you guys feel confident about it.
18:26:52 <morganfainberg> But I want to be clear we aren't jeapordiIng that code for this cycle based on trying this out.
18:27:03 <ayoung> lets stick to client for now
18:27:14 <ayoung> and use it for the server in LizardLove
18:27:35 <amakarov> ayoung, ++
18:27:37 <morganfainberg> ayoung: sure. We should have a lot more lead time on features with an earlier spec proposal time.
18:27:51 <rodrigods> morganfainberg, yes, I'm just not that confident that it would merge if stayed in master as well :)
18:28:02 <rodrigods> anyway...
18:28:05 <morganfainberg> We could do this for the hmt pieces of client as well (if any are still needed)
18:28:28 <morganfainberg> Which still puts a larger team in the driver seat for tying this out.
18:28:47 <marekd> client is mostly about auth, and big parts we move to separate repos (like kerberos, federation etc)
18:28:55 <rodrigods> morganfainberg, there is a couple of changes under review from the first HMT steps
18:29:08 <morganfainberg> marekd: yeah I'm fighting pypi on that atm. Something is broken.
18:29:11 <rodrigods> marekd, I think k2k auth support would be nice
18:29:28 <rodrigods> and could be a nice candidate for the feature branch
18:29:29 <marekd> rodrigods: we have keystoneclient_federation repo and this would very likely go there.
18:29:36 <rodrigods> marekd, ahh, true
18:29:40 <morganfainberg> marekd: ++
18:29:55 <marekd> well...we could add a feature branch in ksc_fdr but...
18:29:56 <stevemar> rodrigods, yeah we are missing a few bits for k2k support for ksc(-fed)
18:30:49 <morganfainberg> jogo: sorry this is hard to figure out the best starting one ;). Since we have to eliminate keystone server. Unless we pick something like the testing spec.
18:30:56 <morganfainberg> That can land post k3
18:31:53 <jogo> morganfainberg: no worries, the timing for trying this idea is not ideal
18:32:01 <ayoung> morganfainberg, I'll volunteer the access info for the client.  Can we accept that and move on?
18:32:16 <jamielennox> the problem is there are generally not that many long running branches on client or middleware
18:32:19 <ayoung> especially if it means I get more eyes
18:32:21 <lbragstad> we need another non core who is interested in it thought, right?
18:32:26 <morganfainberg> ayoung: find some non-cores interested and we can use that
18:33:02 <rodrigods> ayoung, morganfainberg you can add me
18:33:11 <morganfainberg> Anyway I think we will need to look over some options and get back to you jogo   For sure in liberty we will look at this for server.
18:33:24 <ayoung> david8hu, you here?
18:33:31 <jogo> morganfainberg: sounds like a solid plan
18:33:31 <ayoung> rodrigods, thanks
18:33:32 <david8hu> I am here
18:33:34 <morganfainberg> Provided we don't have anything craaaaazy happen before that that makes this an awful idea.
18:33:48 <ayoung> david8hu, we want to do a topic branch for access info.  Interested in being able to review it
18:33:54 <ayoung> ?
18:34:10 <david8hu> Yes, I can help review it.
18:34:18 <ayoung> morganfainberg, there you go
18:34:29 <ayoung> make those two core, and I can post code, too
18:34:36 <ayoung> or...topic-core?
18:34:36 <morganfainberg> Ok so moving on (will circle up with jogo after the meeting on this)
18:34:43 <ayoung> whatever the term is
18:34:53 <ayoung> topicore
18:35:01 <ayoung> Manticore
18:35:07 <morganfainberg> #topic pushing bps / specs to liberty and beyond
18:35:16 <morganfainberg> #link https://launchpad.net/keystone/+milestone/kilo-3
18:35:23 <ayoung> backlog all the specs
18:35:45 <morganfainberg> So we have things that are really unlikely to land.
18:35:52 <ayoung> I think we should drop the juno. kilo subdirs
18:36:07 <morganfainberg> ayoung: no.
18:36:09 <ayoung> and ju8st have all specs submitted to keystone.  It will keep the urls consistent
18:36:12 <ayoung> morganfainberg, yes
18:36:16 <morganfainberg> ayoung: no
18:36:17 <ayoung> let me finish
18:36:18 <marekd> there are some specs moved to backlog, is it desired to simply +2 em so they get merged there?
18:36:27 <lbragstad> I like the subdirs because they help keep track of what happened and when
18:36:29 <ayoung> the BP process tracks where they land.  we are confusing things
18:36:32 <morganfainberg> I need to have an idea what is targeted for the specs for a cycle
18:36:39 <ayoung> having them in one dfir means:  there are approved...
18:36:47 <morganfainberg> Bps are broken. Still do not make me deal with LP more.
18:36:55 <ayoung> we do that for KC and middleware anyway
18:36:59 <morganfainberg> Seriously LP is a reason enough to keep the dirs.
18:37:00 <dstanek> i was planning on putting any of my open specs in the backlog - would that be a good idea?
18:37:06 <morganfainberg> dstanek: yes.
18:37:22 <ayoung> make a file that says which specs are in which release and put it in the specs repo then
18:37:29 <ayoung> seriously, make it simpler
18:37:29 <morganfainberg> ayoung: when we can ditch LP we can look at other workflows.
18:37:40 <ayoung> for now...everytiing goes in backlog
18:38:00 <morganfainberg> ayoung: are you dealing with release management? Please let's not make this worse right now.
18:38:13 <ayoung> morganfainberg, I thought the K3 page linked to the BPs, not the specs?
18:38:22 <ayoung> Didn;'t thinkm you were capable of ignoring BPs yet
18:38:42 <morganfainberg> A little more work on the specs is easier for me for now.
18:38:43 <ayoung> https://launchpad.net/keystone/+milestone/kilo-3
18:38:55 <morganfainberg> If the next ptl wants to change this they can.
18:38:56 <ayoung> anyway...it is not for Kilo
18:39:05 <ayoung> it is for Limabean and beyond
18:39:34 <morganfainberg> This is enough of a headache that please leave this bit of it to the ptl to manage how that workflow looks. Seriously the directories help.
18:39:53 <morganfainberg> At least me
18:39:58 <morganfainberg> For now.
18:40:06 * gyee is here to write code only
18:40:20 <ayoung> It means that we get a slew of -2s that mean nothing.   I'm all for letting Kilo go throuigh, just that all  bumped specs go to backlog, right?
18:41:02 <ayoung> can git do symlinks....?
18:41:11 <morganfainberg> Back to the topic at hand. Anything that is not likely to land in k, abfab ldap filtering. Sql extra attrs etc will be bumped
18:41:24 <morganfainberg> This also likely means the provider cleanup will be pushed.
18:41:45 <henrynash> morganfainberg: ldap filtering is done (just marked it so)
18:41:49 <morganfainberg> We need that cleanup, but it can land first thing in liberty. The klwt will land first in either case.
18:41:52 <gyee> wait, AE have a dependency on provider cleanup
18:41:55 <morganfainberg> henrynash: thanks.
18:41:57 <gyee> isn't it?
18:42:22 <morganfainberg> gyee: no we broke that because klwt has a higher priority. We really need it now.
18:42:42 <morganfainberg> The provider cleanup needs to happen. We can make that hard dep and land klwt
18:43:06 <gyee> morganfainberg, that means both needs to land or none at all for kilo
18:43:08 <morganfainberg> So inverting the order. The added overhead for cleaning up a new provider is relatively low. :(
18:43:12 <morganfainberg> No.
18:43:35 <morganfainberg> Klwt will land. Provider cleanup could land next cycle first off. As soon as rc is cut.
18:43:48 <gyee> k, I need to re-read that code then
18:43:58 <morganfainberg> This is because we are at a hard ff deadline in 10 days.
18:44:27 <morganfainberg> If provider lands (blocking on client stuff) we can land both. But j expect provider to land 1st thing in l
18:44:39 <gyee> that's fine, less moving part is better
18:44:50 <morganfainberg> david8hu: we will get you working with Adam to help unblocking the provider cleanup as well.
18:45:23 <morganfainberg> So please review the bps on the kilo-3 milestone. If they are complete mark them as such.
18:45:26 <stevemar> morganfainberg, so we're going to bump 1) token provider cleanup, 2) remove extra attrs, 3) abfab
18:45:37 <morganfainberg> Yep for sure the last two stevemar
18:45:43 <david8hu> sure.  I am able to make progress without the new access info so far.
18:45:55 <breton> it'd be great to hide non-kilo specs somehow
18:45:57 <gyee> reviews, reviews, and mo reviews
18:46:02 <stevemar> henrynash, ^ bumping 2 is all you, you good with that?
18:46:04 <breton> or make a list of really-high-priority changesets
18:46:08 <marekd> breton: from keystone-specs repo ?
18:46:09 <morganfainberg> david8hu: and that work will still be super important.
18:46:22 <henrynash> stevemar:
18:46:30 <breton> marekd: from everywhere on keystone-related review.openstack.org
18:46:31 <morganfainberg> david8hu: it likely won't be too bad to rebase pose rc
18:46:39 <henrynash> yes, remove extra attrs can be bumped (I think I already did!)
18:46:49 <morganfainberg> breton: there is a link in the topic of the keystone channel for high prio reviews.
18:46:57 <marekd> ++
18:47:00 <david8hu> morganfainberg:  ok
18:47:10 <breton> morganfainberg: yes, and we are going to move some of them to L, right?
18:47:37 <bknudson> http://status.openstack.org/reviews/ sorts reviews by a score if that helps to prioritize reviews.
18:47:40 <marekd> morganfainberg: so,  shall we +1/+2 specs that were moved to backlog, or -2 them for until L cycle is open?
18:47:44 <morganfainberg> All -2 specs proposed (gerrit only ) will be either abandoned or need to be reproposed against backlog.
18:48:15 <morganfainberg> marekd: I'll take care of -2s for non backlog specs. Any that are backlog should already have -2 cleared
18:48:35 <morganfainberg> But please propose them to backlog. It is lower cost to
18:48:43 <breton> there are almost 30 high-priority reviews. Are they all really-really high priority for the next 10 days?
18:48:46 <morganfainberg> Rename a file than deal with massive lists.
18:49:02 <morganfainberg> breton: that will be cleaned up as I push specs beyond to l.
18:49:13 <marekd> aha, cause i did a bunch of +1 of keystone-specs/backlog specs cause it was polluting my next-review list.
18:49:15 <morganfainberg> That is the current list slated for k.
18:49:23 <lbragstad> those reviews will have to be unstarred too,
18:49:30 <lbragstad> morganfainberg: I can help with that one your clean up is done
18:49:35 <morganfainberg> marekd: perfectly fine to +1/+2 backlog specs.
18:49:44 <lbragstad> once*
18:49:48 <marekd> morganfainberg: will change.
18:49:55 <morganfainberg> If they are good we should approve them for backlog :)
18:50:06 <rodrigods> ++
18:50:20 <morganfainberg> It means anyone can grab them and know we like the idea.
18:50:40 <morganfainberg> It lowers the barrier to entry for new developers / contributors to work on features.
18:50:48 <ayoung> according to https://launchpad.net/keystone/+milestone/kilo-3  the only thing marked essentila is marekd 's  	Keystone to Keystone Service Providers
18:50:55 <ayoung> then 3 high
18:51:00 <morganfainberg> ayoung: and that is still essential.
18:51:01 <ayoung> Allow for mapping to existing user in federated workflow
18:51:07 <ayoung> also marekd
18:51:13 <ayoung> Improve list role assignments filtering performance
18:51:14 <ayoung> and
18:51:21 <ayoung> raildo, Implementing Reseller Use Case with the Hierarchical Multitenancy.
18:51:28 <morganfainberg> Yep.
18:51:34 <ayoung> so.. I would say priority goes to reviews for those features
18:51:51 <ayoung> kindof hard to tell from the BP page which are still  outstanding
18:51:53 <morganfainberg> Anyway. I'll have the high priority review list cleaned up today.
18:52:04 <breton> k, great
18:52:06 <morganfainberg> Last item and the. We are done.
18:52:07 <ayoung> K2k  has several reviews, most of which are merged
18:52:08 <raildo> ayoung, ++
18:52:23 <rodrigods> we need k2k in kc
18:52:28 <marekd> ayoung: service provider in service catalog was problematic
18:52:36 <ayoung> rodrigods, not a Keystone server/M3 deadline though
18:52:40 <marekd> and that's why it is stalled
18:52:43 <rodrigods> ayoung, ++
18:52:55 <morganfainberg> So moving on
18:52:55 <ayoung> marekd, as I said, we had considered that years ago and discarded it
18:53:10 <ayoung> lets talk in #openstack-keystone afterwards...move on morganfainberg
18:53:16 <morganfainberg> #topic bps that do not need specs
18:53:22 <morganfainberg> #link https://blueprints.launchpad.net/keystone/+spec/assignment-manager-cleanup
18:53:30 <lbragstad> ~ 7 minutes left
18:53:44 <samueldmq> morganfainberg, was from last week ... sorry
18:53:52 <morganfainberg> Did we decide?
18:53:57 <morganfainberg> I don't remember.
18:54:00 <samueldmq> no ...
18:54:12 <morganfainberg> So then this week is when we talk it through :)
18:54:19 <morganfainberg> If it wasn't talked about.
18:54:24 <samueldmq> stevemar told me to work and see what happens ... to change it to wip :p
18:54:32 <samueldmq> anyway ..
18:54:50 <samueldmq> the idea is to have several methods that honor inheritance and grouping in role assignments
18:55:05 <morganfainberg> So we can take a look. Does that need a spec? Please look it over quickly. If it isn't quick/ we have concerns it can require a spec
18:55:08 <samueldmq> using the new list_role_assignments ... that correctly honor everything needed
18:55:14 <morganfainberg> A spec requires liberty cycle though.
18:56:04 <samueldmq> it's quite simple ... for each method which honor inheritance and grouping membership, re-use list_role_assignments instead of implementing it by itself
18:56:08 <samueldmq> and that's done
18:56:18 <samueldmq> no changing in the behavior
18:56:23 <morganfainberg> At a glance it looks like something that doesn't need a spec and doesn't change behavior n
18:56:34 <samueldmq> exactly
18:56:42 <rodrigods> ++ reuse code :)
18:56:47 <morganfainberg> So I'd be ok with this landing anytime. But anyone else have thoughts / concerns?
18:57:19 <gyee> ++ for improving the role assignment stuff
18:57:36 <henrynash> samueldmq: my only concern is we have a long line of patches queued up….so this has to go on the end., no?
18:57:37 <samueldmq> in addition, this is strictly related to removing the old style metadata ... that re-uses list_role-assignments as well :)
18:58:07 <henrynash> samueldmq: but as you kno, I’ve been puching this re-use, so conceptually I’m all for it
18:58:21 <morganfainberg> henrynash: yes. But it looks to be more tech debt pay down than anything else and probably could land even post k3
18:58:21 <bknudson> I think a bp is adequate for this.
18:58:23 <samueldmq> henrynash, well, we have the list role assignments improvement as priority
18:58:26 <samueldmq> and that should land
18:58:34 <samueldmq> we just need more reviews on it ...
18:58:35 <henrynash> fine
18:58:49 <gyee> but that role-assignment test code was pretty tough to read though
18:58:58 <gyee> took awhile to review that stuff
18:59:01 <morganfainberg> Ok so we're out of time.
18:59:15 <morganfainberg> Any reasons not to say this can go w/o a spec.
18:59:21 <morganfainberg> Going in 2....
18:59:33 <henrynash> nope
18:59:43 <samueldmq> #https://review.openstack.org/#/c/137202/
18:59:46 <henrynash> (i mean nope, no reason it needs a spec)
18:59:48 <morganfainberg> Ok call it no spec needed.
18:59:49 <samueldmq> please review the top of the chain
18:59:53 <samueldmq> #link https://review.openstack.org/#/c/137202/
19:00:02 <samueldmq> morganfainberg, k thanks
19:00:10 <morganfainberg> henrynash: can you update the bp to reflect this info and reference this meeting?
19:00:22 <morganfainberg> #endmeeting