20:03:07 <ttx> #startmeeting tc
20:03:09 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:10 <ttx> Here is our agenda for today:
20:03:13 <openstack> The meeting name has been set to 'tc'
20:03:17 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:27 <ttx> #topic Glance Program Mission Statement and the Catalog
20:03:31 <ttx> markwash: o/
20:03:37 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/036767.html
20:03:38 <markwash> hi hi
20:03:46 <ttx> Overdue original mission is proposed at:
20:03:50 <ttx> #link https://review.openstack.org/98001
20:03:57 <ttx> I think we should approve that one now and then discuss the real proposed change:
20:04:02 <ttx> #link https://review.openstack.org/98002
20:04:19 <ttx> Unless there is strong objection on the 98001 "original" wording
20:04:22 <annegentle> 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 <annegentle> but I can wait for the second
20:05:11 <markwash> annegentle: ugh I missed that! I love the oxford comma
20:05:12 <ttx> 7 YES, I can approve now unless someone objects
20:05:18 <russellb> <3 oxford comma
20:05:33 <mikal> I like cheese
20:05:35 <fungi> i've commented a vote in favor on jeblair's behalf, since it lgtm
20:05:50 <markwash> (commas matter. "Let's eat, grampa!")
20:06:07 <ttx> Ok let's approve it
20:06:08 <dhellmann> mmm, delicious
20:06:11 <annegentle> markwash: mikal: snort
20:06:16 <mordred> yummy salty human flesh...
20:06:26 <ttx> That should facilitate discussion on 98002
20:06:33 <sdague> ttx here now
20:06:49 <ttx> ok, 98001 merged
20:06:55 <ttx> Now on to 98002
20:07:02 <ttx> 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 <markwash> so part of it is breaking up the idea of image so that it is more usable and interoperable for example
20:07:33 <markmc> 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 <markwash> so instead of just "image"
20:07:59 <markwash> we could have an artifact for disk images and artifacts for the full arrangement of device mappings
20:08:09 <markwash> another popular example is pretty much anything that can go in a heat template
20:08:15 <zaneb> heat and murano templates are another obvious one
20:08:22 <gokrokve> Solum LP
20:08:26 <markwash> and the examples that seemed to push this to the fore were murano packages and something something solum
20:08:31 <mikal> markwash: why be an artifact store at all?
20:08:32 <markwash> :-)
20:08:39 <ttx> markwash: ok
20:08:40 <mikal> markwash: couldn't you just be a catalog of artifacts stored elsewhere?
20:08:42 <dhellmann> why do those things need to go in glance, though? why shouldn't they go in the heat database?
20:08:48 <ttx> mikal: it's what it is actually
20:08:56 <markwash> mikal: actually that's what we want to be
20:09:07 <dhellmann> ah, ok, we should take out "store" then :-)
20:09:08 <markwash> mikal except glance has to own stuff in order to guarantee integrity
20:09:15 <zaneb> dhellmann: because we don't want to implement a catalog service in heat
20:09:18 <mikal> markwash: sure
20:09:18 <russellb> a registry of things, their type, and location, right?
20:09:22 <markwash> so if we can't own it without storing it, we'll store it
20:09:24 <fungi> should glance become the heat database? ;)
20:09:25 <devananda> markwash: so the artefacts may be stored, essentially, anywhere - and glance would just provide the browsability?
20:09:30 <mikal> So... does that mean that a key store is just a special case of glance now?
20:09:34 <jaypipes> glance stores the archetypes, other projects store the artifacts themselves?
20:09:40 <russellb> mikal: i think keys are one exception
20:09:48 <mikal> russellb: why?
20:09:52 <devananda> russellb: why?
20:09:57 <markwash> again, we *own* it so we will continue to store everything we have to in order to completely control access
20:09:58 <russellb> mikal: since we said keys justify special handling (around security, compliance)
20:10:05 <russellb> that's why we allowed a special program for key handling
20:10:07 <dhellmann> 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 <zaneb> dhellmann: basically for the same reason we need one for images
20:10:45 <devananda> 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 <markmc> dhellmann, to allow users to browse available templates
20:11:02 <devananda> russellb: don't snapshots have similar security requriements?
20:11:04 <russellb> security compliance rules around storing key material
20:11:04 <mikal> russellb: I am ok with that, as long as there's a good reason
20:11:09 <zaneb> they're a pain to store outside the cloud and still be able to access from Heat
20:11:11 <markwash> mikal: we don't do fancy crypto so we shouldn't store keys
20:11:15 <markwash> its not that we couldn't
20:11:15 <zaneb> you could just use swift
20:11:18 <russellb> devananda: haven't heard that requirement
20:11:24 <markwash> its just that no one would choose to use glance for keys :-)
20:11:30 <markmc> zaneb, but you wouldn't have browsing
20:11:37 <zaneb> but glance provides a lot of nice things (e.g. artifacts are immutable)
20:11:46 <russellb> right, and typing
20:12:13 <dhellmann> 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 <russellb> and i guess some additional access controls
20:12:15 <markmc> typing facilitates browsing
20:12:21 * markmc getting silly now
20:12:23 <russellb> :)
20:12:38 <jaypipes> dhellmann: I think that's a good question.
20:12:39 <ttx> 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 <markmc> immutability is there for browsing experience too?
20:13:00 <zaneb> russellb: yeah, typing is essential for Murano, at least
20:13:01 <jaypipes> dhellmann: is mutability a requirement for being a versioned archetype? I think it is.
20:13:07 <dhellmann> 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 <markwash> immutability is just part the expected user experience of a repository
20:13:13 <jaypipes> dhellmann: sorry, meant *immutability* :)
20:13:33 <markwash> think sonatype nexus for an example of another "repository" as I mean it today
20:13:37 <fungi> jaypipes: i think strict versioning at least enables immutability
20:13:37 <ttx> dhellmann: agree reason could be provided in the commit message
20:13:41 <zaneb> I actually don't like the wording w.r.t immutability
20:13:44 <jaypipes> fungi: agreed.
20:14:13 <jaypipes> 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 <dhellmann> 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 <zaneb> the repository should be versioned and you should only be able to reference fixed versions
20:14:38 <devananda> markwash: if glance may be configured as a broker that does not store objects locally, how does it guarantee immutability?
20:14:43 <zaneb> not 100% sure that 'immutable' is the right way to describe that
20:14:47 <fungi> "what problems this solves in an openstack environment"?
20:14:51 <dhellmann> zaneb: those are product requirements, not a program mission description
20:14:54 <jaypipes> 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 <markwash> devananda: we strive to own the account things are stored under elsewhere
20:15:16 <dhellmann> "a service to store and find application-specific BLOBs" is a mission
20:15:21 <mordred> dhellmann: ++
20:15:29 <ttx> 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 <zaneb> dhellmann: swift does that. glance is something more specific
20:15:46 <dhellmann> ttx: ok, I was being brief for irc
20:15:55 <dhellmann> zaneb: does swift have search?
20:15:56 <devananda> zaneb: that's my confusion
20:16:07 <dhellmann> zaneb: are swift objects application-specific? maybe "strongly typed" instead?
20:16:10 <mordred> it's an artifact registry
20:16:13 <mikal> dhellmann: it has search for prefix in a container
20:16:13 <markmc> wow, BLOB is actually an acronym
20:16:16 <mordred> that you can stick something in swift is irrelvant
20:16:24 <mordred> markmc: yup. Binary Large OBject
20:16:27 <dhellmann> markmc: yeah
20:16:37 <mordred> you can also just have  LOB
20:16:40 <fungi> markmc: if it's in the jargon file, it's *got* to be true
20:16:43 <fungi> gospel
20:16:43 <markwash> 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 <mordred> markwash: ++
20:16:50 <markmc> fungi, wikipedia too
20:16:52 <markwash> which includes rich type-specific metadata
20:17:02 <dhellmann> markwash: +1
20:17:13 <markmc> metadata is a feature, why is it useful? browsing?
20:17:19 <gokrokve> References is one of the key features of the artifact repository
20:17:19 <zaneb> 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 <dhellmann> 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 <ttx> OK, looks like we'll have to timebox this
20:17:25 <markwash> dhellmann: yes
20:17:26 <jaypipes> 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 <devananda> a service which brokers access to application-specific data objects which, once stored, are versioned.
20:17:31 <markwash> metadata is such a terrible word
20:17:38 <dhellmann> markwash: ok, thanks for clarifying
20:17:50 <gokrokve> It should be able to download a bulk of artifacts tied by references
20:17:53 <markwash> 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 <mordred> jaypipes: new rule, anyone who mentions starkey loses ;)
20:18:06 <jaypipes> mordred: :)
20:18:08 <markwash> since user-metadata is not very discoverable, understandable, portable, etc
20:18:10 <devananda> mordred: lol
20:18:14 <annegentle> jaypipes: pedant!
20:18:29 <ttx> Let's try to iterate on the review itself. If it stalls we can raise a ML thread
20:18:31 <sdague> ok, so here's where I like doing mission statements in folksy language. :)
20:18:34 <ttx> BUT
20:18:39 <markmc> "document" doesn't resonate with me as data which is attributes describing the BLOB
20:18:49 <markwash> markmc: fair
20:18:59 <ttx> 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 <dhellmann> markmc: +1
20:19:05 <ttx> 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 <markwash> 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 <ttx> 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 <ttx> (once we converge onto a new mission/name)
20:19:29 <jaypipes> markwash: schema? archetype?
20:19:29 <markmc> yeah, I think there's consensus here on the general idea
20:19:36 <markmc> just nitpicking now, really
20:19:37 <russellb> yeah, definitely like the general idea
20:19:38 <mordred> ++
20:19:38 <russellb> wording is hard
20:19:41 <markmc> collaborative editing
20:19:41 <mordred> general idea rocks
20:19:44 <mordred> words suck
20:19:47 <zaneb> markwash: I'm also curious about the Graffiti blueprint, and how that ties in with this mission
20:19:51 <ttx> OK, and gerrit helps with that
20:19:59 <ttx> Lets' move on to next topi, shall we
20:20:01 <ttx> +c
20:20:03 <mordred> zaneb: I think that's to expand on the metadata side of the coin
20:20:08 <markwash> so, my feeling on Graffiti is that it helps us with the user-metadata we will keep
20:20:14 <russellb> how many sides does the coin have
20:20:17 <markwash> and the fact that it helps other openstack projects too is just gravy
20:20:21 <mordred> russellb: 1000000000000000
20:20:33 <dhellmann> russellb: that depends on the coin's type, right?
20:20:40 <mordred> dhellmann: I need some coin metadata
20:20:47 <russellb> :)
20:20:48 <dhellmann> mordred: ask markwash
20:20:53 <russellb> ok, i think we can move to the next topic
20:20:55 <markmc> ok, moving on from glance ...
20:20:55 <devananda> ttx: ++
20:20:56 <markmc> to more glance?
20:20:57 <ttx> #agreed let's iterate on wording on the gerrit review
20:21:01 <zaneb> 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 <markwash> zaneb: good point
20:21:11 <ttx> #topic Glance Functional API and Cross-project API Consistency
20:21:19 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-May/036416.html
20:21:22 <markwash> lets be sure of that in the notes on the vote if we can
20:21:35 <ttx> So this is more of an advice question, touching API convergence
20:21:36 <markwash> oh yeah this one
20:21:53 <markwash> 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 <markwash> did you do that?
20:21:58 <markwash> should we talk to them?
20:22:00 <russellb> i like the way you propose better than nova's way
20:22:07 <ttx> err
20:22:20 <markmc> #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/thread.html#36701
20:22:27 <ttx> /action with type passed in payload, or /actions/action
20:22:29 <markmc> damn threads crossing month boundaries
20:22:36 <dhellmann> 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 <sdague> russellb: agreed, the proposed glance way for actions is much nice
20:22:56 <sdague> nicer
20:22:59 <russellb> anyone disagree?
20:23:02 <sdague> dhellmann: that was me :)
20:23:12 <markmc> I just wish we were gradually converging on API consistency
20:23:12 <ttx> so I don't think we should block them from implementing it at all :)
20:23:18 <dhellmann> sdague: that was a good point
20:23:23 <markmc> that consensus meant all projects would adopt this pattern in future
20:23:37 <markmc> rather than another project to iterate further on this
20:23:46 <annegentle> 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 <russellb> markmc: yes, agreed... how can we communicate this widely?
20:23:52 <sdague> dhellmann: I stare at logs a lot... the action urls are painful today
20:23:53 <markmc> russellb, dunno
20:23:59 <russellb> should it be something we document as a best practice recommended by this group?
20:24:04 <russellb> and then blog about it in our new TC update series?  :)
20:24:12 <dhellmann> should we start an API style guide in the wiki? or an all-projects spec repo?
20:24:16 <anteaya> cyeoh had a summit session on apis
20:24:20 * markmc had a document called "ReST standards" before; geddit?
20:24:24 <markwash> there were volunteers for this in a summit session
20:24:28 <markwash> you could just delegate
20:24:32 <ttx> russellb: at one point in history we wanted to have some API czar, but that died quickly
20:24:33 <markmc> (for another project)
20:24:34 <anteaya> jaypipes you said you would do a thing out of that session
20:24:36 <sdague> right, didn't we discuss an all-projects spec repo
20:24:48 <sdague> and even ttx agreed on it :)
20:24:48 <russellb> this is all i know of ... https://wiki.openstack.org/wiki/APIChangeGuidelines
20:24:52 <dhellmann> markwash: by "we" I meant "openstack" rather than "the tc"
20:24:52 <russellb> and it's not really about API design at all
20:24:58 <markwash> dhellmann: ah kk
20:25:08 <markmc> we've had some etherpads from design summit sessions too
20:25:09 <russellb> ttx: a nice idea if the right person stepped up and was motivated
20:25:13 <markmc> but they were proposals I guess
20:25:26 <devananda> 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 <dhellmann> devananda: sure
20:26:00 <ttx> OK, so agreement on letting Glance go in that direction, and wish we had clearer guidelines set to encourage future convergence ?
20:26:11 <sdague> ttx: +1
20:26:16 <anteaya> I can cobble together the cyeoh's session notes and do a ml post so it gets a tc agenda item
20:26:16 <markmcclain> +1
20:26:21 <fungi> sounds reasonable
20:26:25 <devananda> +1
20:26:26 <markmc> we would fully support anyone wanting to take on the task of document style guidelines
20:26:31 <ttx> #agreed Glance can definitely go in that direction for API
20:26:33 <dhellmann> markwash: how about if you *start* a style guide?
20:26:41 <dhellmann> markwash: see what I did there?
20:26:48 <markwash> if I start it, it will never be finished
20:26:49 <markwash> or started
20:26:52 <dhellmann> haha
20:26:53 <markwash> :-)
20:26:59 <devananda> tossing this out there as possibly helpful for folks
20:26:59 <ttx> #info TC would like to have "good API design" guidelines to encourage convergence, looking for volunteers to document and propose that
20:27:00 <devananda> https://restful-api-design.readthedocs.org/en/latest/methods.html
20:27:22 <annegentle> 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 <dhellmann> markwash: seriously, you could just start with this one issue
20:27:38 <annegentle> she'd have the most cross-project knowledge from all the API doc work
20:27:46 <markwash> dhellmann: I'll give it some thought but I'm in too dangerous a location to commit to anything right now
20:27:53 <dhellmann> markwash: ok
20:28:00 * markmc throws http://fedoraproject.org/wiki/Cloud_APIs_REST_Style_Guide out there as an example
20:28:37 <ttx> ok, moving on to next topic ?
20:28:44 <markwash> moar glance!
20:28:46 <annegentle> honestly this looks like something Diane could do, would you like it?
20:28:48 <ttx> #link http://fedoraproject.org/wiki/Cloud_APIs_REST_Style_Guide
20:29:12 <ttx> annegentle: if she wants to propose something, i don't think we should prevent her
20:29:21 <annegentle> ttx: got it
20:29:40 <ttx> but she should expect the "convergence guideliens" to be nitpicked over to death
20:29:48 <ttx> so albestos suit recommended
20:29:56 <annegentle> heh
20:29:59 <jaypipes> dang it, I really wish I had the time to respond to that Glance functional API thread :(
20:30:05 <annegentle> flame-proof but cancer-causing. Check
20:30:08 <jaypipes> too many darn emails.
20:30:08 <russellb> or some asbestos-replacement that won't ruin your lungs
20:30:25 <ttx> jaypipes is the closest we have in the TC to an APi integrist
20:30:45 <fungi> he is also flameproof, from what i hear
20:30:45 <markwash> I'm a bit afraid that some rest purism might argue against our approach
20:31:12 <markmc> ttx, integrist needs translation - I only learned it from nijaba in atlanta :)
20:31:21 <ttx> oh.
20:31:39 <ttx> frenchism probably
20:31:44 <markmc> markwash, rest purism? never!
20:31:50 <ttx> ok, moving on
20:31:58 <ttx> #topic Integrated projects and new requirements: Gap analysis for Glance
20:32:05 <ttx> mOAR Glance
20:32:10 <ttx> markwash: hi!
20:32:17 * markwash just made it in time
20:32:17 <ttx> #link https://etherpad.openstack.org/p/glance-integration-gaps
20:32:21 * russellb glances over the etherpad
20:32:31 <markwash> the formatting there is probably not so good
20:32:36 <ttx> I figured we should expedite this one, since we have markwash around
20:32:49 <markwash> bottom line is that I couldn't really find much of a problem, except pace of bug triage and docs maybe
20:33:19 <russellb> i have no complaints
20:33:21 <russellb> nice work :)
20:33:21 <sdague> 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 <vishy> its ok REST fails when using lists + acls
20:33:43 <ttx> 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 <markwash> sdague: eek
20:33:55 <sdague> And I'm pretty sure much of the v2 api is not covered
20:33:57 <markwash> glance core has been a bit of an alumni association, yes
20:34:18 <russellb> would be nice to get nova updated to using latest glance API
20:34:21 <russellb> could use help there
20:34:28 <sdague> markwash: yeh, mtreinish wrote all the glance tests a year ago when they largely didn't exist
20:34:35 <sdague> but there are definitely holes
20:34:40 <annegentle> 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 <ttx> mordred: could you add markwash as admin to https://launchpad.net/~glance-coresec/+members ?
20:35:03 <markwash> ttx: OH! core-sec
20:35:09 <ttx> mordred: and maybe remove yourself (you retain access through openstack-admins)
20:36:06 <fungi> or i can take care of it if mordred is busy mordreding
20:36:15 <annegentle> markwash: bit of docs analytics trivia
20:36:21 <markwash> 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 <ttx> fungi: we have to elevate ourselves to admin, while he is admin already. But yes, you can do it :)
20:36:38 <annegentle> 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 <annegentle> markwash: sounds like your brain needs a mudroom for docs
20:37:07 <markwash> indeed
20:37:28 <annegentle> markwash: but it's also the most exited page
20:38:15 <mordred> ttx: on it
20:38:40 <sdague> 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 <ttx> markwash: I don't see any gaps. Only suggestions for improevments (like moar coverage)
20:39:00 <markwash> sdague: yes, honestly we're struggling in that capacity :-(
20:39:09 <sdague> that pattern in glance was actually one of the key reasons we implemented clean check
20:39:12 <jaypipes> russellb: I've been working towards glance v2 api support in nova.
20:39:14 <fungi> ttx: markwash: mordred: updated glance-coresec
20:39:18 <russellb> jaypipes: awesome
20:39:23 <mordred> fungi: oh - you got it. great
20:39:27 <sdague> because lots of glance patches with really old test results would get sent into the queue
20:39:29 <jaypipes> russellb: all the blueprints are marked low priority and retargeted to j-2
20:39:30 <markwash> I've been very time conflicted and haven't figured out the right way to motivate folks
20:39:40 <fungi> ttx: markwash: mordred: admins are now brian waldon and mark washenberger
20:39:56 <sdague> markwash: so I guess that raises an interesting question. Is the core review team healthy enough to take on more mission?
20:40:01 <ttx> 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 <ttx> (interested in security issues)
20:40:08 <markwash> probably want to remove bcwaldon fungi
20:40:13 <fungi> markwash: will do
20:40:15 <markmcclain> sdague: was wondering the same thing
20:40:30 <fungi> markwash: done
20:40:38 <mikal> jaypipes: they will have been retargetted because we're so close to j-1 now
20:40:40 <jaypipes> 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 <markwash> sdague: actually i think the extra interest from murano and graffiti folks is something we could catalyze into better review practices
20:40:54 <jaypipes> mikal: oh, I know. wasn't complaining. just as an FYI
20:40:56 <markwash> b/c the problem is that glance's old mission is kind of stale and uninteresting
20:41:02 <markwash> so it doesn't really draw people into the project as much
20:41:09 <ttx> #info recommendation: more coverage (API v2, binary content...)
20:41:25 <ttx> #info recommendation: saner review pattern
20:41:26 <markwash> murano, graffiti, solumn, heat, etc.
20:41:36 <markwash> s/solumn/solum/ of course
20:41:42 <devananda> markwash: being stable isn't a bad thing ... :)
20:41:45 <sdague> 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 <markwash> sdague: +1
20:42:14 <sdague> devananda: um... you should have seen some of those patches. :)
20:42:21 <markwash> checkpointing is great b/c honestly we need help and you guys can point us in the right direction
20:42:24 <ttx> sdague: I expect the new mission will inject new blood, fwiw
20:42:37 <sdague> ttx: yep, that's fair. I just want to raise it as a concern.
20:42:43 <ttx> concern noted
20:42:43 <sdague> so we can be mindful of it
20:42:49 <ttx> anything else ?
20:43:01 <ttx> Do we agree tat there is no gap, only a set of recommendations ?
20:43:15 <dhellman_> I thought testing was a gap?
20:43:25 <ttx> #info recommendation: fix glance-coresec to only include 2-4 active core members interested in security issues
20:43:44 <markwash> is there an api coverage report generated from tempest?
20:43:56 <sdague> markwash: I haven't dug into it deeply
20:44:04 <navid> Hi
20:44:05 <ttx> 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 <ttx> A gap means we want to have a gap coverage plan in place ASAP
20:44:25 <sdague> ttx: the lack of testing a binary image is probably a gap :)
20:44:41 <sdague> but I'll let markwash pound that out in a week, and it should be fine
20:44:51 <ttx> OK
20:44:52 <dhellmann_> ttx: what sdague said :-)
20:44:52 <navid> since you are discussing tests. is there a solid document about unit tests in keystone
20:44:53 <markwash> ascii is a subset of binary
20:44:54 <markwash> bam
20:45:06 <fungi> heh
20:45:15 <ttx> #info gap: intgeration tests -- lack of testing a binary image
20:45:23 <anteaya> navid: this is a meeting, try #openstack-dev
20:45:26 <sdague> markwash: :)
20:45:43 <ttx> OK, anything else ?
20:45:47 <fungi> i suppose the pedants can say high-bit rather than binary
20:45:58 <markwash> fungi: you got me
20:46:07 <ttx> markwash: so you should come up with a plan to address the identified gap, ideally within the Juno cycle
20:46:13 <ttx> should be short :)
20:46:33 <markwash> I'll see if the plan can be a gerrit review
20:46:46 <ttx> You can file the plan in a doc like https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage
20:47:02 <ttx> just ping me when you have it up
20:47:09 <markwash> kk
20:47:24 <ttx> let's move on
20:47:28 <ttx> #topic Defcore status update
20:47:49 <mikal> Oh hai
20:47:49 <markwash> (thanks everybody!)
20:47:55 <ttx> no zehicle today, maybe mikal can expose how last meetings went ?
20:48:04 <ttx> markwash: Thanks for everything
20:48:17 <mikal> 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 <mikal> Its started, but stalled
20:48:34 <mikal> I'll pick that up again this week, so expect something soon
20:48:46 <ttx> mikal: and mordred was supposed to file a scoring proposal as a governance change
20:48:50 <mordred> yes. I'm behidn. sorry
20:49:03 <ttx> mikal: is tat still needed ?
20:49:05 <mikal> ttx: cool
20:49:06 <ttx> +h?
20:49:26 <mikal> 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 <ttx> (I think it is, just checking)
20:49:50 <mikal> 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 <mikal> Based on the principles we agreed to a while ago
20:50:24 <ttx> mikal: do you think we need a resolution for that ?
20:50:47 <mikal> ttx: probably not, but it seemed the easiest way to get something into the repo
20:51:12 <mikal> 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 <mikal> ttx: if you have a different process, I'm all ears
20:51:42 <ttx> mikal: was thinking an email with cc:openstack-tc should be sufficient, but i'm fine with the resolution route
20:51:52 <ttx> it will just take more time
20:52:01 <mikal> Yeah, I liked that just because it ties everything together with a documented history
20:52:15 <ttx> mikal: your call, really.
20:52:25 <ttx> mikal: anything else ?
20:52:27 <mikal> Well, let me finish writing it first and then people can comment on the process
20:53:07 <ttx> Questions on defcore ?
20:53:41 <ttx> #topic Governance changes in review
20:53:48 <ttx> * Propose Designate for Incubation (https://review.openstack.org/97609)
20:53:56 <Kiall> Heya
20:54:31 <ttx> -1s from mikal and markmc still standing
20:54:41 * mikal looks again
20:54:41 <russellb> appears to be general support, just for some requests to add/change wording
20:54:47 <Kiall> markmc just proposed we reword one of the sections, we're happy to. mugsie was preparing an alternative
20:54:58 <mikal> Oh yeah
20:54:58 <markmc> cool
20:55:02 <Kiall> and I believe we have addressed mikal's concers
20:55:06 <mugsie> yeah - what we have now is "Enable operators to provide scalable, on demand self service access for customers to authoritative DNS services."
20:55:06 <mikal> I just wanted the nova proxy work
20:55:15 <mikal> Kiall: I don't see a new patchset?
20:55:15 <markmcclain> have we solved the issue of where to house the application?
20:55:30 <Kiall> mikal: Oh - We've included that in the wiki page
20:55:43 <Kiall> an action item seems inappropriate for merging into the repo?
20:55:43 <mugsie> mikal: https://wiki.openstack.org/wiki/Designate/Incubation_Application#Why_a_new_project.3F
20:55:54 <mikal> Oh, I see
20:55:58 <ttx> markmcclain: orthogonal discussion ?
20:56:00 <Kiall> markmcclain: no, not that I saw.
20:56:06 <Kiall> ttx: ++
20:56:28 <dhellman_> markmcclain: do you mean which program?
20:56:33 <Kiall> markmc: does mugsie's alternative wording make sense for you?
20:56:37 <ttx> mordred: asked you a question there: "@Monty: Obviously the application should not live in the projects.yaml. Would you have the application details in the commit message ? Or in some new file under the "resolutions" directory ? Or in a file in a new "applications" directory ?"
20:56:47 <markmc> Kiall, sounds a lot better, yes
20:57:00 <ttx> OK, let's iterate one more time and get it approved soon
20:57:03 <markmc> but then again ... "scalable, on deman" ... true of all OpenStack
20:57:12 <Kiall> markmc: Okay, we're happy to make that change - but don't want to change the document mid voting without telling people ;)
20:57:14 <ttx> * Adds a resolution addressing expected election behaviour (https://review.openstack.org/98675)
20:57:19 <anteaya> o/
20:57:23 <markmcclain> ttx: yes orthogonal but in the comments of this review
20:57:32 <ttx> Not as much time to discuss that as I'd like to
20:57:45 <ttx> Let's comment on te Gerrit review
20:57:50 <anteaya> comments so far range from none of the tc can be included in the process to all of the tc must be included
20:58:02 <mikal> anteaya: yeah, do both of those
20:58:02 <anteaya> so patchset 2 will be a challenge for me
20:58:07 <anteaya> you got it
20:58:23 <anteaya> additional comments welcome
20:58:26 <mugsie> anteaya: if you have any questions about what I meant in my comments, ping me
20:58:33 <eglynn> anteaya: ... well to be fair, it was more that it must be spelled out which it is
20:58:34 <ttx> yeah, I think everyone agrees with the general intent, but the escalation process in case of violation may still need a bit of refinement
20:58:57 <anteaya> which needs to take into account our voting process
20:59:06 <anteaya> the timing around it and how it currently works
20:59:27 <eglynn> ... and who does the investigating
20:59:49 <eglynn> ... and the finding of guilt, and deciding the penalty
20:59:54 <anteaya> who has time to do the investigating
21:00:01 <anteaya> not guilt, violation
21:00:03 <ttx> OK, let's continue on the review. I know a lot of people haven't reviewed it yet ( includeing me)
21:00:05 <anteaya> different words
21:00:11 <ttx> * Add translation support requirement (https://review.openstack.org/97872)
21:00:40 <ttx> same here, needs a bit more reviews
21:00:44 <ttx> #topic Housekeeping items
21:00:48 <ttx> * Sync infra projects list (https://review.openstack.org/98239)
21:00:58 <ttx> That one I shall approve after meeting, unless someone complains NOW
21:01:11 <ttx> #topic Open discussion
21:01:16 <ttx> Famous last words, anyone ?
21:01:35 <russellb> we talked about blogging our activities, i'll take a stab at covering this week
21:01:40 <anteaya> yay
21:01:52 <dhellmann> thanks, russellb!
21:01:54 <mikal> russellb: thanks
21:01:55 <ttx> russellb: still working out the details of the o.o/blog accounts
21:01:55 <jaypipes> russellb: ty
21:02:09 <russellb> ttx: will just post to mine for now
21:02:11 <zaneb> russellb: ++
21:02:14 <russellb> tomorrow morning
21:02:15 <ttx> russellb: ok
21:02:45 <ttx> Maybe we should just post to personal blogs nd keep some common title
21:02:57 <ttx> #endmeeting