20:03:07 #startmeeting tc 20:03:09 Meeting started Tue Jun 10 20:03:07 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:10 Here is our agenda for today: 20:03:13 The meeting name has been set to 'tc' 20:03:17 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:03:27 #topic Glance Program Mission Statement and the Catalog 20:03:31 markwash: o/ 20:03:37 #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/036767.html 20:03:38 hi hi 20:03:46 Overdue original mission is proposed at: 20:03:50 #link https://review.openstack.org/98001 20:03:57 I think we should approve that one now and then discuss the real proposed change: 20:04:02 #link https://review.openstack.org/98002 20:04:19 Unless there is strong objection on the 98001 "original" wording 20:04:22 heh I wasn't gonna nitpick 98001 but I like the serial comma in 98002's list 20:04:32 * devananda adds +1 to the first review 20:04:34 but I can wait for the second 20:05:11 annegentle: ugh I missed that! I love the oxford comma 20:05:12 7 YES, I can approve now unless someone objects 20:05:18 <3 oxford comma 20:05:33 I like cheese 20:05:35 i've commented a vote in favor on jeblair's behalf, since it lgtm 20:05:50 (commas matter. "Let's eat, grampa!") 20:06:07 Ok let's approve it 20:06:08 mmm, delicious 20:06:11 markwash: mikal: snort 20:06:16 yummy salty human flesh... 20:06:26 That should facilitate discussion on 98002 20:06:33 ttx here now 20:06:49 ok, 98001 merged 20:06:55 Now on to 98002 20:07:02 markwash: could you provide examples of other artifact types that would make sense for storage into the new Glance ? 20:07:07 * devananda notes the lengthy discussions on rev2 of 98002, starts catching up 20:07:27 so part of it is breaking up the idea of image so that it is more usable and interoperable for example 20:07:33 yes, maybe start with concrete example of why the mission needs expanding 20:07:33 * dhellmann went a little too far stripping out implementation details in his proposed revision 20:07:41 so instead of just "image" 20:07:59 we could have an artifact for disk images and artifacts for the full arrangement of device mappings 20:08:09 another popular example is pretty much anything that can go in a heat template 20:08:15 heat and murano templates are another obvious one 20:08:22 Solum LP 20:08:26 and the examples that seemed to push this to the fore were murano packages and something something solum 20:08:31 markwash: why be an artifact store at all? 20:08:32 :-) 20:08:39 markwash: ok 20:08:40 markwash: couldn't you just be a catalog of artifacts stored elsewhere? 20:08:42 why do those things need to go in glance, though? why shouldn't they go in the heat database? 20:08:48 mikal: it's what it is actually 20:08:56 mikal: actually that's what we want to be 20:09:07 ah, ok, we should take out "store" then :-) 20:09:08 mikal except glance has to own stuff in order to guarantee integrity 20:09:15 dhellmann: because we don't want to implement a catalog service in heat 20:09:18 markwash: sure 20:09:18 a registry of things, their type, and location, right? 20:09:22 so if we can't own it without storing it, we'll store it 20:09:24 should glance become the heat database? ;) 20:09:25 markwash: so the artefacts may be stored, essentially, anywhere - and glance would just provide the browsability? 20:09:30 So... does that mean that a key store is just a special case of glance now? 20:09:34 glance stores the archetypes, other projects store the artifacts themselves? 20:09:40 mikal: i think keys are one exception 20:09:48 russellb: why? 20:09:52 russellb: why? 20:09:57 again, we *own* it so we will continue to store everything we have to in order to completely control access 20:09:58 mikal: since we said keys justify special handling (around security, compliance) 20:10:05 that's why we allowed a special program for key handling 20:10:07 zaneb: why do you need a catalog service to store templates? we don't need one to store most of the rest of the stuff we store? (serious question about the difference) 20:10:38 dhellmann: basically for the same reason we need one for images 20:10:45 what makes a pub key different from a heat template different from an image -- from the perspective of publishing & browsing opaque content? 20:10:55 dhellmann, to allow users to browse available templates 20:11:02 russellb: don't snapshots have similar security requriements? 20:11:04 security compliance rules around storing key material 20:11:04 russellb: I am ok with that, as long as there's a good reason 20:11:09 they're a pain to store outside the cloud and still be able to access from Heat 20:11:11 mikal: we don't do fancy crypto so we shouldn't store keys 20:11:15 its not that we couldn't 20:11:15 you could just use swift 20:11:18 devananda: haven't heard that requirement 20:11:24 its just that no one would choose to use glance for keys :-) 20:11:30 zaneb, but you wouldn't have browsing 20:11:37 but glance provides a lot of nice things (e.g. artifacts are immutable) 20:11:46 right, and typing 20:12:13 is immutability a strong enough feature to be mentioned in the mission, preventing any type of artifact from being mutable without TC approval later? 20:12:14 and i guess some additional access controls 20:12:15 typing facilitates browsing 20:12:21 * markmc getting silly now 20:12:23 :) 20:12:38 dhellmann: I think that's a good question. 20:12:39 I think it makes sense to use a more generic name than "images" since we are about to use glance to store more than just disk images 20:12:41 * markwash is not sure he can follow the pace of all this :-) 20:12:51 immutability is there for browsing experience too? 20:13:00 russellb: yeah, typing is essential for Murano, at least 20:13:01 dhellmann: is mutability a requirement for being a versioned archetype? I think it is. 20:13:07 markwash: what I read in draft 3 was a lot of features of glance, but not the *reason* for having those features 20:13:11 immutability is just part the expected user experience of a repository 20:13:13 dhellmann: sorry, meant *immutability* :) 20:13:33 think sonatype nexus for an example of another "repository" as I mean it today 20:13:37 jaypipes: i think strict versioning at least enables immutability 20:13:37 dhellmann: agree reason could be provided in the commit message 20:13:41 I actually don't like the wording w.r.t immutability 20:13:44 fungi: agreed. 20:14:13 and frankly, the prospect of having a service that provides these schemas/archetypes in a consistent, versioned manner is really appealing to me. 20:14:17 ttx: no, I mean the mission is supposed to describe what is being built in terms of what benefit it brings, not in terms of a product manager's view of features 20:14:23 the repository should be versioned and you should only be able to reference fixed versions 20:14:38 markwash: if glance may be configured as a broker that does not store objects locally, how does it guarantee immutability? 20:14:43 not 100% sure that 'immutable' is the right way to describe that 20:14:47 "what problems this solves in an openstack environment"? 20:14:51 zaneb: those are product requirements, not a program mission description 20:14:54 I envision things like images, block device mappings, even things like capabilities that are currently randomly plopped into nova's compute node and flavor extra_specs stuff, 20:14:59 devananda: we strive to own the account things are stored under elsewhere 20:15:16 "a service to store and find application-specific BLOBs" is a mission 20:15:21 dhellmann: ++ 20:15:29 dhellmann: glance first consumer are other openstack services though, and I think taht's covered in "artifacts consumable by OpenStack services in a unified manner" wording 20:15:45 dhellmann: swift does that. glance is something more specific 20:15:46 ttx: ok, I was being brief for irc 20:15:55 zaneb: does swift have search? 20:15:56 zaneb: that's my confusion 20:16:07 zaneb: are swift objects application-specific? maybe "strongly typed" instead? 20:16:10 it's an artifact registry 20:16:13 dhellmann: it has search for prefix in a container 20:16:13 wow, BLOB is actually an acronym 20:16:16 that you can stick something in swift is irrelvant 20:16:24 markmc: yup. Binary Large OBject 20:16:27 markmc: yeah 20:16:37 you can also just have LOB 20:16:40 markmc: if it's in the jargon file, it's *got* to be true 20:16:43 gospel 20:16:43 keeping in mind that we actualy use swift for storage in many deployments. . we're focusing on the value add over-top of swift 20:16:49 markwash: ++ 20:16:50 fungi, wikipedia too 20:16:52 which includes rich type-specific metadata 20:17:02 markwash: +1 20:17:13 metadata is a feature, why is it useful? browsing? 20:17:19 References is one of the key features of the artifact repository 20:17:19 dhellmann: I think you'll end up with a different product if your mission doesn't include the fact that artifacts are versioned 20:17:21 markwash: is that what "documents" means in the current draft? I wasn't sure what the distinction between documents and BLOB was 20:17:23 OK, looks like we'll have to timebox this 20:17:25 dhellmann: yes 20:17:26 markmc: technically, when Jim Starkey invented the term back in the 70s, Blob was not an acronym.. he just meant to reference a thing without structure. 20:17:27 a service which brokers access to application-specific data objects which, once stored, are versioned. 20:17:31 metadata is such a terrible word 20:17:38 markwash: ok, thanks for clarifying 20:17:50 It should be able to download a bulk of artifacts tied by references 20:17:53 the goal is to take as much semantic user metadata and make it actually schematic document data 20:18:01 * jaypipes goes back into pedantry cave. 20:18:01 jaypipes: new rule, anyone who mentions starkey loses ;) 20:18:06 mordred: :) 20:18:08 since user-metadata is not very discoverable, understandable, portable, etc 20:18:10 mordred: lol 20:18:14 jaypipes: pedant! 20:18:29 Let's try to iterate on the review itself. If it stalls we can raise a ML thread 20:18:31 ok, so here's where I like doing mission statements in folksy language. :) 20:18:34 BUT 20:18:39 "document" doesn't resonate with me as data which is attributes describing the BLOB 20:18:49 markmc: fair 20:18:59 I kinda like that we are expanding Glance role to cover not just disk images but other BLOBs of the same type of usage 20:19:02 markmc: +1 20:19:05 One potential issue we need to check is the change in the "official name" from "OpenStack Image Service" to "OpenStack Artifact Repository" 20:19:06 actually I struggled to get that term, I don't know what the right one is, just metadata is so so overloaded :-) 20:19:18 Personally I think the new name makes way more sense, but I feel like we need to warn more than just the developers about it 20:19:28 (once we converge onto a new mission/name) 20:19:29 markwash: schema? archetype? 20:19:29 yeah, I think there's consensus here on the general idea 20:19:36 just nitpicking now, really 20:19:37 yeah, definitely like the general idea 20:19:38 ++ 20:19:38 wording is hard 20:19:41 collaborative editing 20:19:41 general idea rocks 20:19:44 words suck 20:19:47 markwash: I'm also curious about the Graffiti blueprint, and how that ties in with this mission 20:19:51 OK, and gerrit helps with that 20:19:59 Lets' move on to next topi, shall we 20:20:01 +c 20:20:03 zaneb: I think that's to expand on the metadata side of the coin 20:20:08 so, my feeling on Graffiti is that it helps us with the user-metadata we will keep 20:20:14 how many sides does the coin have 20:20:17 and the fact that it helps other openstack projects too is just gravy 20:20:21 russellb: 1000000000000000 20:20:33 russellb: that depends on the coin's type, right? 20:20:40 dhellmann: I need some coin metadata 20:20:47 :) 20:20:48 mordred: ask markwash 20:20:53 ok, i think we can move to the next topic 20:20:55 ok, moving on from glance ... 20:20:55 ttx: ++ 20:20:56 to more glance? 20:20:57 #agreed let's iterate on wording on the gerrit review 20:21:01 markwash: ok, I just want to make sure the Glance team has freedom of action in that area without coming back to the TC 20:21:11 zaneb: good point 20:21:11 #topic Glance Functional API and Cross-project API Consistency 20:21:19 #link http://lists.openstack.org/pipermail/openstack-dev/2014-May/036416.html 20:21:22 lets be sure of that in the notes on the vote if we can 20:21:35 So this is more of an advice question, touching API convergence 20:21:36 oh yeah this one 20:21:53 mostly some folks elected you guys to appoint an api consistency committee 20:21:55 * ttx with type passed in payload, or actions/action 20:21:55 did you do that? 20:21:58 should we talk to them? 20:22:00 i like the way you propose better than nova's way 20:22:07 err 20:22:20 #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/thread.html#36701 20:22:27 /action with type passed in payload, or /actions/action 20:22:29 damn threads crossing month boundaries 20:22:36 yeah, I forget who mentioned logging but between that and making request routing easier I like the action in the url, too 20:22:54 russellb: agreed, the proposed glance way for actions is much nice 20:22:56 nicer 20:22:59 anyone disagree? 20:23:02 dhellmann: that was me :) 20:23:12 I just wish we were gradually converging on API consistency 20:23:12 so I don't think we should block them from implementing it at all :) 20:23:18 sdague: that was a good point 20:23:23 that consensus meant all projects would adopt this pattern in future 20:23:37 rather than another project to iterate further on this 20:23:46 ttx: I'm in agreement, I'd like to see one project do the work and others follow and it doesn't always have to be nova as pattern-setter 20:23:46 markmc: yes, agreed... how can we communicate this widely? 20:23:52 dhellmann: I stare at logs a lot... the action urls are painful today 20:23:53 russellb, dunno 20:23:59 should it be something we document as a best practice recommended by this group? 20:24:04 and then blog about it in our new TC update series? :) 20:24:12 should we start an API style guide in the wiki? or an all-projects spec repo? 20:24:16 cyeoh had a summit session on apis 20:24:20 * markmc had a document called "ReST standards" before; geddit? 20:24:24 there were volunteers for this in a summit session 20:24:28 you could just delegate 20:24:32 russellb: at one point in history we wanted to have some API czar, but that died quickly 20:24:33 (for another project) 20:24:34 jaypipes you said you would do a thing out of that session 20:24:36 right, didn't we discuss an all-projects spec repo 20:24:48 and even ttx agreed on it :) 20:24:48 this is all i know of ... https://wiki.openstack.org/wiki/APIChangeGuidelines 20:24:52 markwash: by "we" I meant "openstack" rather than "the tc" 20:24:52 and it's not really about API design at all 20:24:58 dhellmann: ah kk 20:25:08 we've had some etherpads from design summit sessions too 20:25:09 ttx: a nice idea if the right person stepped up and was motivated 20:25:13 but they were proposals I guess 20:25:26 dhellmann: api style guide could be helpful, but shouldn't be too rigid or may get abused/ignored, depending on how things go 20:25:31 * markmc put links in https://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis 20:25:36 devananda: sure 20:26:00 OK, so agreement on letting Glance go in that direction, and wish we had clearer guidelines set to encourage future convergence ? 20:26:11 ttx: +1 20:26:16 I can cobble together the cyeoh's session notes and do a ml post so it gets a tc agenda item 20:26:16 +1 20:26:21 sounds reasonable 20:26:25 +1 20:26:26 we would fully support anyone wanting to take on the task of document style guidelines 20:26:31 #agreed Glance can definitely go in that direction for API 20:26:33 markwash: how about if you *start* a style guide? 20:26:41 markwash: see what I did there? 20:26:48 if I start it, it will never be finished 20:26:49 or started 20:26:52 haha 20:26:53 :-) 20:26:59 tossing this out there as possibly helpful for folks 20:26:59 #info TC would like to have "good API design" guidelines to encourage convergence, looking for volunteers to document and propose that 20:27:00 https://restful-api-design.readthedocs.org/en/latest/methods.html 20:27:22 I can ask Diane Fleming if she's interested in picking up an API style guide but we'd need to define what you want. 20:27:24 markwash: seriously, you could just start with this one issue 20:27:38 she'd have the most cross-project knowledge from all the API doc work 20:27:46 dhellmann: I'll give it some thought but I'm in too dangerous a location to commit to anything right now 20:27:53 markwash: ok 20:28:00 * markmc throws http://fedoraproject.org/wiki/Cloud_APIs_REST_Style_Guide out there as an example 20:28:37 ok, moving on to next topic ? 20:28:44 moar glance! 20:28:46 honestly this looks like something Diane could do, would you like it? 20:28:48 #link http://fedoraproject.org/wiki/Cloud_APIs_REST_Style_Guide 20:29:12 annegentle: if she wants to propose something, i don't think we should prevent her 20:29:21 ttx: got it 20:29:40 but she should expect the "convergence guideliens" to be nitpicked over to death 20:29:48 so albestos suit recommended 20:29:56 heh 20:29:59 dang it, I really wish I had the time to respond to that Glance functional API thread :( 20:30:05 flame-proof but cancer-causing. Check 20:30:08 too many darn emails. 20:30:08 or some asbestos-replacement that won't ruin your lungs 20:30:25 jaypipes is the closest we have in the TC to an APi integrist 20:30:45 he is also flameproof, from what i hear 20:30:45 I'm a bit afraid that some rest purism might argue against our approach 20:31:12 ttx, integrist needs translation - I only learned it from nijaba in atlanta :) 20:31:21 oh. 20:31:39 frenchism probably 20:31:44 markwash, rest purism? never! 20:31:50 ok, moving on 20:31:58 #topic Integrated projects and new requirements: Gap analysis for Glance 20:32:05 mOAR Glance 20:32:10 markwash: hi! 20:32:17 * markwash just made it in time 20:32:17 #link https://etherpad.openstack.org/p/glance-integration-gaps 20:32:21 * russellb glances over the etherpad 20:32:31 the formatting there is probably not so good 20:32:36 I figured we should expedite this one, since we have markwash around 20:32:49 bottom line is that I couldn't really find much of a problem, except pace of bug triage and docs maybe 20:33:19 i have no complaints 20:33:21 nice work :) 20:33:21 markwash: so I know for a fact the tempest tests for glance don't actually try to store real binary data, because I got bit by it :) 20:33:37 its ok REST fails when using lists + acls 20:33:43 markwash: you might want to refine your https://launchpad.net/~glance-coresec/+members -- looks like an old list of glance-core people 20:33:45 sdague: eek 20:33:55 And I'm pretty sure much of the v2 api is not covered 20:33:57 glance core has been a bit of an alumni association, yes 20:34:18 would be nice to get nova updated to using latest glance API 20:34:21 could use help there 20:34:28 markwash: yeh, mtreinish wrote all the glance tests a year ago when they largely didn't exist 20:34:35 but there are definitely holes 20:34:40 markwash: my input on docs would be that API docs also include the reference listings at http://developer.openstack.org/api-ref-image-v2.html and http://developer.openstack.org/api-ref-image-v1.html 20:34:43 mordred: could you add markwash as admin to https://launchpad.net/~glance-coresec/+members ? 20:35:03 ttx: OH! core-sec 20:35:09 mordred: and maybe remove yourself (you retain access through openstack-admins) 20:36:06 or i can take care of it if mordred is busy mordreding 20:36:15 markwash: bit of docs analytics trivia 20:36:21 annegentle: I personally have had a perilous time trying to keep our docs in mind. its like there's no cubby space for that in my brain somehow 20:36:38 fungi: we have to elevate ourselves to admin, while he is admin already. But yes, you can do it :) 20:36:38 markwash: one of the most visited pages on the docs site is http://docs.openstack.org/image-guide/content/ch_converting.html 20:36:49 markwash: sounds like your brain needs a mudroom for docs 20:37:07 indeed 20:37:28 markwash: but it's also the most exited page 20:38:15 ttx: on it 20:38:40 markwash: I haven't looked recently, but I did have concerns about the review patterns in glance core. Where largely nothing would get looked at for 4 - 6 weeks, then mass approvals near a milestone 20:38:54 markwash: I don't see any gaps. Only suggestions for improevments (like moar coverage) 20:39:00 sdague: yes, honestly we're struggling in that capacity :-( 20:39:09 that pattern in glance was actually one of the key reasons we implemented clean check 20:39:12 russellb: I've been working towards glance v2 api support in nova. 20:39:14 ttx: markwash: mordred: updated glance-coresec 20:39:18 jaypipes: awesome 20:39:23 fungi: oh - you got it. great 20:39:27 because lots of glance patches with really old test results would get sent into the queue 20:39:29 russellb: all the blueprints are marked low priority and retargeted to j-2 20:39:30 I've been very time conflicted and haven't figured out the right way to motivate folks 20:39:40 ttx: markwash: mordred: admins are now brian waldon and mark washenberger 20:39:56 markwash: so I guess that raises an interesting question. Is the core review team healthy enough to take on more mission? 20:40:01 markwash: so now you can clean up https://launchpad.net/~glance-coresec/+members, ideally so that it's only 2-4 active core 20:40:08 (interested in security issues) 20:40:08 probably want to remove bcwaldon fungi 20:40:13 markwash: will do 20:40:15 sdague: was wondering the same thing 20:40:30 markwash: done 20:40:38 jaypipes: they will have been retargetted because we're so close to j-1 now 20:40:40 sdague: I believe the core review team would expand given the new mission...or at least, the opportunity to add some new folks would exist. 20:40:44 sdague: actually i think the extra interest from murano and graffiti folks is something we could catalyze into better review practices 20:40:54 mikal: oh, I know. wasn't complaining. just as an FYI 20:40:56 b/c the problem is that glance's old mission is kind of stale and uninteresting 20:41:02 so it doesn't really draw people into the project as much 20:41:09 #info recommendation: more coverage (API v2, binary content...) 20:41:25 #info recommendation: saner review pattern 20:41:26 murano, graffiti, solumn, heat, etc. 20:41:36 s/solumn/solum/ of course 20:41:42 markwash: being stable isn't a bad thing ... :) 20:41:45 markwash: ok. I think it's something we should checkpoint on though. Because I do get concerned with integrated projects that only review in bursts 20:41:55 sdague: +1 20:42:14 devananda: um... you should have seen some of those patches. :) 20:42:21 checkpointing is great b/c honestly we need help and you guys can point us in the right direction 20:42:24 sdague: I expect the new mission will inject new blood, fwiw 20:42:37 ttx: yep, that's fair. I just want to raise it as a concern. 20:42:43 concern noted 20:42:43 so we can be mindful of it 20:42:49 anything else ? 20:43:01 Do we agree tat there is no gap, only a set of recommendations ? 20:43:15 I thought testing was a gap? 20:43:25 #info recommendation: fix glance-coresec to only include 2-4 active core members interested in security issues 20:43:44 is there an api coverage report generated from tempest? 20:43:56 markwash: I haven't dug into it deeply 20:44:04 Hi 20:44:05 dhellman_: A gap would mean, we'd reject Glance in integration if it were proposed now. Do you think testing coverage is a gap ? 20:44:24 A gap means we want to have a gap coverage plan in place ASAP 20:44:25 ttx: the lack of testing a binary image is probably a gap :) 20:44:41 but I'll let markwash pound that out in a week, and it should be fine 20:44:51 OK 20:44:52 ttx: what sdague said :-) 20:44:52 since you are discussing tests. is there a solid document about unit tests in keystone 20:44:53 ascii is a subset of binary 20:44:54 bam 20:45:06 heh 20:45:15 #info gap: intgeration tests -- lack of testing a binary image 20:45:23 navid: this is a meeting, try #openstack-dev 20:45:26 markwash: :) 20:45:43 OK, anything else ? 20:45:47 i suppose the pedants can say high-bit rather than binary 20:45:58 fungi: you got me 20:46:07 markwash: so you should come up with a plan to address the identified gap, ideally within the Juno cycle 20:46:13 should be short :) 20:46:33 I'll see if the plan can be a gerrit review 20:46:46 You can file the plan in a doc like https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage 20:47:02 just ping me when you have it up 20:47:09 kk 20:47:24 let's move on 20:47:28 #topic Defcore status update 20:47:49 Oh hai 20:47:49 (thanks everybody!) 20:47:55 no zehicle today, maybe mikal can expose how last meetings went ? 20:48:04 markwash: Thanks for everything 20:48:17 So... I'm meant to have drafted by now a request for PTLs and TC to help nominate designated sections for their projects 20:48:26 Its started, but stalled 20:48:34 I'll pick that up again this week, so expect something soon 20:48:46 mikal: and mordred was supposed to file a scoring proposal as a governance change 20:48:50 yes. I'm behidn. sorry 20:49:03 mikal: is tat still needed ? 20:49:05 ttx: cool 20:49:06 +h? 20:49:26 ttx: the designated sections thing? I was only asked to do it last week, so I guess that defcore believes it is still needed 20:49:33 (I think it is, just checking) 20:49:50 I was going to draft it in the form of a TC resolution requesting PTLs to provide a response for the TC to rubber stamp / route 20:50:01 Based on the principles we agreed to a while ago 20:50:24 mikal: do you think we need a resolution for that ? 20:50:47 ttx: probably not, but it seemed the easiest way to get something into the repo 20:51:12 ttx: just a really light weight "please consider these principles and then send a gerrit review adding a section for your project below" 20:51:19 ttx: if you have a different process, I'm all ears 20:51:42 mikal: was thinking an email with cc:openstack-tc should be sufficient, but i'm fine with the resolution route 20:51:52 it will just take more time 20:52:01 Yeah, I liked that just because it ties everything together with a documented history 20:52:15 mikal: your call, really. 20:52:25 mikal: anything else ? 20:52:27