20:03:06 <ttx> #startmeeting tc
20:03:07 <openstack> Meeting started Tue Mar 29 20:03:06 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:10 <openstack> The meeting name has been set to 'tc'
20:03:13 * edleafe lurks in the back
20:03:20 <mriedem> o/
20:03:20 <ttx> Hi everyone
20:03:22 <annegentle> here
20:03:24 * cdent sits next to edleafe
20:03:26 <ttx> agenda for today:
20:03:30 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:03:30 <dhellmann> o/
20:03:36 <ttx> #topic Appointed PTLs for Newton
20:03:39 * amrith finds a seat in the last row
20:03:40 <ttx> #link https://review.openstack.org/296360
20:03:45 <ttx> Last time I looked this was still missing one vote
20:03:54 <ttx> Looks like I can +A it now
20:04:02 <ttx> Oh, and you can pile up +1s on the PTL names update @ https://review.openstack.org/298228
20:04:12 <ttx> I'll approve that one once it gets the election officials +1 and TC majority
20:04:40 <ttx> #topic Remove rolling-upgrade tag from ceilometer
20:04:46 <ttx> #link https://review.openstack.org/292334
20:04:59 <ttx> So the original change was removing for swift and ceilometer but swift is pretty close to add the missing test harness
20:05:13 <ttx> So the change was updated to only affect ceilometer, which is unlikely to fix the missing tests in the coming week.
20:05:28 <notmyname> yes, thank you to those who are helping get the framework set up for swift's testing
20:05:28 <sdague> swift definitely supports the functionality, there was a testing gap, that the team is working actively to close
20:05:37 <notmyname> especially sdague
20:06:04 <ttx> could use one more vote on the tag removal
20:06:16 * Rockyg lurks on the side
20:06:27 <jaypipes> hey, I'm here too...
20:06:34 * dims peeks
20:06:37 * devananda lurks on the other side
20:06:55 * dims says we have a full peanut gallery!
20:06:57 <jeblair> cool, i'm glad this is working out!
20:07:09 <markmcclain> ttx: looks like we have 7 on the tag removal
20:07:13 <ttx> alrighty
20:07:20 * ttx clicks blue button
20:07:36 <ttx> Live news from the board meeting I hear our reporter Monty is on the scene
20:07:45 <annegentle> ha
20:08:05 <mordred> hey all!
20:08:20 <mordred> jeblair: would you like to comment?
20:08:24 * russellb looks at jeblair
20:08:45 <jeblair> hey, so the board likes the mission statement
20:08:50 <jeblair> there was some commentary on it
20:08:53 <jeblair> but no objections
20:09:13 <jeblair> (the update to the mission statement, to be clear) :)
20:09:16 <annegentle> oh, good
20:09:20 <ttx> Alright, we'll pick that up at next meeting
20:09:20 <jbryce> Unanimous approval in fact
20:09:33 <flaper87> nnnnnnnnniiiiiiiiceeee
20:09:34 <ttx> for the last meeting of the Mitaka membership
20:09:45 <ttx> #topic Update Kuryr mission statement
20:09:48 <ttx> moving on
20:09:49 <anteaya> jbryce: yay!
20:09:52 <ttx> #link https://review.openstack.org/289993
20:10:12 <ttx> OK, so making that discussion a bit more public on the ML beared(bore?) the expected fruits of drawing attention to it
20:10:28 <ttx> The fear of dilution of the Kuryr team limited membership was raised
20:10:47 <ttx> Though I suspect that with additional scope additional members would be interested in joining
20:10:59 <ttx> (resources are not really finite, they clearly depend on the scope addressed)
20:11:18 <ttx> The key question here is: is it two different teams or the exact same team working on those two aspects
20:11:48 <ttx> So I'm still fine with the Kuryr team exploring that space, in close contact with the Magnum team
20:11:59 <ttx> we can split that team later if needed ?
20:12:05 <lifeless> Well
20:12:11 <lifeless> its not really a top down call is it ?
20:12:31 <flaper87> TBH, I'd just let them explore for now and then deal with the results
20:12:35 <lifeless> the teams going to do what they think best
20:12:42 * dtroyer looks for a scorecard to keep up with this afternoon's comments in the review…
20:12:46 <dhellmann> yeah, the main question in my mind is does this alter their mission in a way that adds things "not openstack", and I don't think it does that.
20:12:59 <sdake> nothing in the governance rpeo is goign to stop either magnum or kuryr from proceeding
20:13:05 <flaper87> I don't think the current change is crazy and they've cleared that
20:13:06 <ttx> lifeless: if those are two differetn teams frankensteined together into a single project team in governance, we can ask that they form two separate teams
20:13:30 <ttx> but that is about it, yes
20:13:31 <lifeless> ttx: sure, but I've no real visibility on that
20:13:32 <dtroyer> I think the main question isn't the kind of work, it is the organization and who should be doing it
20:13:43 <dhellmann> ttx: we can, if issues come up that make it seem like that would be a solution. I don't think we need to start out by worrying about that.
20:13:58 <ttx> lifeless: right, at this stage this is pretty much an acknowledgment of the turn they want to take
20:14:30 <dhellmann> dtroyer : presumably the kuryr team wants to do it, if they're changing their mission statement?
20:14:44 <lifeless> ...moving on :)
20:14:46 <ttx> Looks like the TC is vastly supporting the mission update, unless a massive number of TC members want to change their vote now
20:14:54 * dhellmann hopes to hear someone say "kuryr" at the summit so he knows how to pronounce it
20:14:58 <dtroyer> dhellmann: right, the objections indicate disagreement in other teams…
20:15:06 <sdake> dhellmann like shipping something via courier :)
20:15:09 <lifeless> it has 11 +A's
20:15:09 <dhellmann> dtroyer : right
20:15:19 <lifeless> erm +RC? whatever we call it
20:15:20 <ttx> approving now
20:15:22 <dhellmann> sdake : aha!
20:15:50 <ttx> done!
20:15:59 <ttx> #topic Changes to clarify project election requirements
20:16:14 <ttx> So those are changes aiming to clarify the need to participate in the election process, proposed by thingee
20:16:18 <ttx> especially for recently-added projects
20:16:19 <thingee> o/
20:16:26 <ttx> * Mention in project requirements about ptl election (https://review.openstack.org/295609)
20:16:33 <ttx> I think this one is a worthwhile clarification
20:16:59 <ttx> further improvements or precision could be proposed as subsequent patches, I guess
20:17:24 <sdague> dhellmann's clarifications seem a little crisper
20:17:28 <ttx> I like dhellmann version, too
20:17:29 <dtroyer> I like dhellmann's comment, now or later works
20:17:29 <markmcclain> ++
20:17:36 <edleafe> seems like some of the new teams were surprised. This should help.
20:17:38 <flaper87> let's update this patch
20:17:43 <thingee> can do another revision and we can circle back?
20:17:47 <ttx> thingee: can you update patch ?
20:17:51 <thingee> yes
20:17:54 <flaper87> and vote again,  we can do that as we go on with the meeting
20:18:06 <ttx> * Add leaderless programs amendment for inactivity (https://review.openstack.org/295581)
20:18:20 <ttx> So I'm less convinced we need this one. It just adds that the TC may decide to demote leaderless project teams
20:18:31 <ttx> But we may (and will) demote project teams for other violations of the OpenStack Way, not just for being leaderless or abandoned
20:18:44 <ttx> So I think this sets wrong expectations, that as long as you're active and participating in elections the TC can't remove you
20:18:51 <dhellmann> I don't think we want to start enumerating reasons for demoting teams unless they seem exceptional or not covered elsewhere.
20:19:03 <lifeless> yeah, I don't see why we need it
20:19:11 <dhellmann> If the team doesn't hold an election and ends up leadersless, that's covered by one of our existing 4 opens
20:19:22 <ttx> I think the mention in requirements (and the project team guide) are enough.
20:19:39 <dhellmann> yeah, I think clarifying over in the PTG will be good
20:20:04 <ttx> ok, maybe pile up a few -1s and I'll abandon it
20:20:05 <dhellmann> we may also want to remind new teams to review that when we approve them, and ask questions if they have them
20:20:18 <flaper87> I actually didn't see too much of an issue with this one
20:20:26 <flaper87> I mean
20:20:48 <flaper87> It mentions that leaderless project teams may be removed
20:20:53 <thingee> https://review.openstack.org/#/c/295609/5
20:20:56 <flaper87> and the model is based on teams having a leader
20:21:04 <flaper87> the project governance model, that is
20:21:11 <ttx> flaper87: it's not wrong, it's useless
20:21:20 <lifeless> its adding procedure where none is required
20:21:20 <dhellmann> flaper87 : as soon as we start making a list of reasons, we have to keep extending it to cover every case.
20:21:34 <lifeless> being clear about what happens to e.g. Nova when noone stands for election is pretty important
20:21:35 <thingee> dhellmann: makes sense
20:21:35 <flaper87> mmh, I'll take your word on that
20:21:45 <dtroyer> It also updated program to project in the older doc…should we be looking at those to see if they need more than s/program/project/ updates?
20:21:59 <dtroyer> ie, if/where meaning changes
20:22:03 <ttx> dtroyer: it's not a doc, it's a resolution
20:22:10 <ttx> dtroyer: so it's a bit dated
20:22:19 <thingee> dtroyer: can do another patch to catch those
20:22:30 <ttx> s/program/project team/ actually
20:22:33 <anteaya> if folks feel strongly about team/project/progam changes in the resolution I can fix it
20:22:43 <anteaya> but honestly the meaning is the same
20:22:52 <anteaya> and we keep changing the wording
20:23:00 <dtroyer> that's really my question, are there places where the meaning is actually different with the different word?
20:23:06 <ttx> please review https://review.openstack.org/#/c/295609/5, will approve if it passes the bar
20:23:20 <dtroyer> I don't want to do replacement just to replace
20:23:20 <anteaya> dtroyer: I haven't seen any difference in how the resolution is used, no
20:23:27 <ttx> dtroyer: not that I can think of
20:23:30 <dtroyer> kk, thanks anteaya
20:23:33 <anteaya> welcome
20:23:49 <anteaya> I have seen the resolution used successfuly for how it was intended
20:23:54 <ttx> #topic Stale cross-project specs (thingee)
20:24:03 <thingee> o/
20:24:04 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/089115.html
20:24:10 <ttx> thingee: floor is yours
20:24:34 <thingee> We have some still cross-project specs. I have reached out to some of the owners in their individual reviews
20:25:22 <thingee> in the previous cross-project meeting we discussed how we'd like to manage these. some people agreed it was fine for myself to be able to abandon these if there has been enough notice with the owners. I'm also fine with the TC doing this if there is enough reason, but someone needs to :)
20:25:45 <thingee> /still/stale/
20:26:05 <ttx> I'm fine with the cross-project group abandoning them. If there is opposition they can escalate to TC
20:26:08 <dhellmann> this seems like a good time to clear out the backlog if they're truly stale
20:26:12 <flaper87> I'm fine with abandoning those!
20:26:23 <fungi> yeah, if the tc wants to grant some group (e.g. thingee) abandon power on that repo, it's a simple acl addition in gerrit
20:26:27 <flaper87> "with the x-prj team"
20:26:32 <thingee> ttx: I will note jeblair is still waiting for my to make a resolution on the cross-project team having more rights in this repo
20:26:46 <dtroyer> I don't think the TC needs to be involved here unless there is a dispute
20:26:53 * mordred thinks the tc should grant thingee broad-reaching powers
20:26:55 <ttx> dtroyer: exactly
20:27:00 <sdague> dtroyer: well the TC *is* the approval team at this point
20:27:05 * dhellmann hands thingee Powers whiskey
20:27:06 <sdague> that's how it was set up originally
20:27:12 <ttx> thingee: how about you fix the ACL and then go on an abandonment rampage ?
20:27:17 <sdague> so that can be changed, which is cool
20:27:23 <anteaya> the cross project team doesn't have a ptl, unless the tc would like to create one
20:27:31 <fungi> the acl comes with big, stompy boots suitable for abandonment rage
20:28:00 <jeblair> who is the cross-project group?
20:28:08 <jeblair> i assume thingee is in it :)
20:28:10 <ttx> sdague: I would delegate to the cross-project meeting chair
20:28:13 <mordred> jeblair: you are
20:28:16 <annegentle> jeblair: tc?
20:28:20 <jeblair> right
20:28:27 <thingee> jeblair: I guess it's cross-project spec liaisons to be exact and correcting myself https://wiki.openstack.org/wiki/CrossProjectLiaisons#Cross-Project_Spec_Liaisons
20:28:32 <ttx> and then handle disputes at TC level if any
20:28:45 <jeblair> so i'm specifically asking about "I'm fine with the cross-project group abandoning them. If there is opposition they can escalate to TC" :)
20:28:48 <flaper87> We can probably take care of the cleanup this time around and set up the ACLs for x-prj specs correctly
20:28:56 <thingee> and our project team guide http://docs.openstack.org/project-team-guide/cross-project.html
20:29:09 <gordc> it seems strange tc holds approval/abandon powers if they are only handling it at a dispute level
20:29:10 * dtroyer hears delegation gears grinding away
20:29:23 <ttx> jeblair: the cross-project meeting chair, representing the cross-project spec liaisons ?
20:29:27 <dhellmann> if we just want someone to do the work, I already have a pair of those big stompy boots fungi mentioned
20:29:35 <thingee> ttx: how about I finish my resolution and the TC can review that.
20:29:43 <ttx> gordc: right we should fix the ACL to match how we proceed nowadays
20:29:43 <flaper87> Feels like we all want thingee to take care of that but there's no actual 'title' for him to take that on except he being the chair.
20:29:44 <jeblair> yeah, it sounds like we have some general support for delegation
20:29:58 <lifeless> +1
20:30:01 <jeblair> i just want to recognize that i think we're catching up to a new (good) reality here
20:30:10 <gordc> ttx: cool cool. yeah, it'd make more sense to just give it to CPL and chair since they're the ones reviewing
20:30:42 <jeblair> i'd be most comfortable with a tc resolution acknowledging this delegation
20:30:47 <jeblair> (i'd vote for it)
20:31:05 <dhellmann> jeblair : but will you write it?
20:31:33 <ttx> ok, let's propose a resolution describing the cross-project new ACL, then implement that ACL and let thingee abandon things
20:31:39 <jeblair> dhellmann: i may not be best positioned too since i'm not as involved as thingee but would be happy to help
20:31:49 <dhellmann> :-)
20:32:00 <ttx> would that work ?
20:32:03 <dhellmann> formally delegating this seems like a good plan
20:32:05 <jeblair> dhellmann: i am the person who just asked "who is the cross projcet group?" :)
20:32:08 <thingee> works for me!
20:32:13 <flaper87> ttx: yeah, that's what I intended to suggest above but I fail to mention "lets put this in a resolution"
20:32:21 <jeblair> dhellmann: but at least i'm asking the right questions.  i think.  :)
20:32:39 <anteaya> jeblair: I like your questions
20:32:46 <thingee> jeblair: you also asked a resolution a while back for acl and cp group http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-01-19-20.02.log.html#l-29
20:32:58 <ttx> #info let's propose a resolution describing the cross-project new ACL, then implement that ACL and let thingee abandon things
20:32:59 <jeblair> i am also consistent :)
20:33:02 * thingee had that sitting in a tab since he already started writing this
20:33:06 <dtroyer> ++ for consistency
20:33:13 <ttx> thingee: anything else on this ?
20:33:20 <thingee> ttx: nope, thanks everyone
20:33:27 <jeblair> thingee: thank you!
20:33:41 <ttx> Thank you, I know by experience herding the cross-project spec cats is no fun
20:34:10 <ttx> #topic Tags to describe deployment and packaging deliverables
20:34:19 <sdake> o/
20:34:22 <ttx> So these propose to add type:deployment and type:packaging tags to describe deployment/packaging deliverables
20:34:27 * jaypipes perks up...
20:34:33 <ttx> * Introduce type:deployment tag (https://review.openstack.org/295528)
20:34:40 <ttx> I commented on this one -- I think the requirements are unclear.
20:34:52 <ttx> Should every Puppet module get this tag ? Or would they get type:packaging instead ?
20:34:52 <edleafe> sorry to wake you, jaypipes
20:35:09 <dhellmann> I think they're overly prescriptive, too, talking about producing fully integrated deployments
20:35:20 * ttx reads recent comments
20:35:29 <dhellmann> "is useful for deployments" and "produces a full deployment" are two different things
20:35:44 <dhellmann> the former tag is useful for the release team, the latter is less so
20:35:50 <dhellmann> but may be more useful for some users
20:35:53 <ttx> sdake: In my understanding type:packaging applies to main service (or tool) that ends up deploying OpenStack services using packages/recipes/whatever (which may get the type:packaging tag)
20:36:04 <sdake> deploys-working-cloud seems reasonable dhellmann
20:36:05 <ttx> So type:packaging applies to Fuel, and it does not apply to debian/rpm packages
20:36:20 <ttx> Kolla, Ansible, Chef and Puppet are less clear-cut though -- those seem to do packaging for Docker, Ansible, Chef and Puppet to deploy
20:36:30 <dhellmann> ttx: do you mean type:deployment?
20:36:35 <sdake> no type:deployment applies to fuel
20:36:40 <ttx> so I'd like the requirements to have clear answers for all of those
20:36:53 <ttx> type:deployment sorry
20:36:54 <sdake> ttx agreed I think these need more work
20:36:59 <sdake> the reason i bring them up
20:37:19 <ttx> * Introduce a type:packaging tag (https://review.openstack.org/295971)
20:37:24 <sdake> ttx is because other tags (the assert classification in paritcular_) asserts on them
20:37:36 <ttx> type:packaging as proposed has another type of issue -- the requirements as worded apply to the whole packaging system rather than specific deliverables
20:37:39 <jaypipes> edleafe: I was awake. just this particular topic is of special interest to me given sdake's TC candidacy email.
20:37:41 <sdake> ttx which locks out deployment projects from asserting anything
20:37:48 <ttx> For example to assess if deb-trove should get type:packaging, I have to look into Debian to see if RabbitMQ is packaged there
20:37:51 <annegentle> sdake: this is good stuff, is the end goal clear? Is it to group all deployments or rank within the deployments grouping?
20:37:52 <jaypipes> edleafe: where he bemoans the RED TAPE.
20:38:03 <ttx> I'd rather drop those requirements and just give type:packaging to anything that is a package of an openstack thing
20:38:22 <dhellmann> yeah, let's keep the tag definitions simple
20:38:24 <sdake> annegentle you got it
20:38:28 <ttx> same way we give type:library to anything that quacks like a library
20:38:29 <edleafe> jaypipes: just funnin' ya. But yeah, lotsa tape...
20:38:32 <annegentle> sdake: heh it can't be both :)
20:38:38 <sdague> sdake: the one place that I saw you throw up some asserts was on upgrade, but to the best of my knowledge none of the deployments do gate testing for upgrade
20:38:46 <annegentle> sdake: I mean, it can I spose, but isn't clear yet.
20:38:54 <sdake> annegentle sorry misread your or as an and
20:39:12 <dhellmann> sdague : there is also a mention somewhere in one of the release model tags that allows deployment repos to be out of phase with the rest of the projects
20:39:13 <annegentle> sdake: no worries
20:39:19 <sdague> dhellmann: ah, right
20:39:29 <annegentle> one q I had on first read through was "where's the ops tags?"
20:39:32 <sdake> ttx may I have a moment to explain the why of these tags
20:39:43 <dhellmann> I can't remember if it was milestone or intermediary, but it would probably apply to both, assuming we don't just define a different release model for that case
20:39:51 <annegentle> since that effort might be relevant and I don't know where it left off
20:39:51 <lifeless> sdague: doesn't devstack do that ?
20:39:54 <sdague> dhellmann: which makes total sense to me, deployment projects having a phase delay with server projects
20:39:56 <jaypipes> sdake: please do tell. I'm very interested in the answer to that question.
20:39:59 <ttx> sdake: sure
20:40:01 <lifeless> sdague: (and it clearly is a type:deployment...)
20:40:13 <sdague> devstack doesn't upgrade
20:40:16 <ttx> please let sdake explain
20:40:19 <dhellmann> sdague : right, it's just not clear which solution is best, a new model or an exceptions to the existing model
20:40:23 <dtroyer> lifeless: please don't let DevStack get a tag that encourages any use outside development or testing
20:40:29 <sdague> dtroyer: ++
20:40:30 * dhellmann waits for sdake
20:40:31 <sdake> jaypipes the reason i introduced these tags is I think it is unfair to deployment projects to be excluded from tagging with assertions
20:40:51 <sdake> jaypipes the project tag came out of a discussion in the review with ttx that we should also have a packaging tag
20:41:00 <sdake> i know life is unfair, but we shoudl be a fair organization ;)
20:41:06 <jaypipes> :)
20:41:21 <ttx> well, you have to think about the goal of that assertion. It's not a badge
20:41:22 <sdake> i am less hot on the packaging tag
20:41:31 <ttx> It's about communicating some information to our users
20:41:49 <sdake> ttx I agree its not a badge, but for example kolla upgrades
20:41:50 <sdake> yet we can't assert it
20:41:54 <ttx> That assertion communicates which service projects support cold and rolling upgrades
20:41:54 <jroll> is there a specific assertion at hand here, or is it about all of them?
20:41:57 <jroll> ah, upgrades
20:42:03 <sdague> sdake: in the gate?
20:42:03 <sdake> so if someone looks at he automated tooling release produces, we can't indicate it
20:42:11 <lifeless> sdake: kolla itself can be upgraded
20:42:13 <dhellmann> sdake, why can't kolla assert upgrades?
20:42:17 <lifeless> sdake: or kolla can upgrade other things?
20:42:19 <sdake> sdague not yet, but we can do that triviallly
20:42:38 <ttx> dhellmann: because the assert tag calls type:service specifically
20:42:39 <sdake> dhellmann because the upgrade tag specifically says it only appliees to type:service
20:42:46 <annegentle> ah, ok
20:42:57 <dhellmann> ah, ok, so that'll be easy to fix with this change
20:42:59 <sdake> i'm just trying to fix the tags so they make sense :)
20:43:10 <EmilienM> sdake: ++
20:43:10 <lifeless> sdake: and kolla doesn't have any service?
20:43:11 <sdague> sdake: ok, the current upgrade asserts were definitely written with servers in mind. I think it would be cool to do the right thing for deployment tools there as well, but it might be a different description of what it means
20:43:12 <ttx> I'd rather fix the assertion (or create another one) than create extra type tags just to support that assertion
20:43:18 <sdake> maybe i wentabout it the wrong way, but I think I shave a right to submit changes to hte governance repo ;)
20:43:26 <dhellmann> sure, I suspect the type:service was there to avoid worrying about type:library, not to exclude deployment things
20:43:32 <EmilienM> lifeless: no, it's a deployment tool
20:43:40 <dhellmann> sdake : the approach is fine, the details need work
20:43:41 <jroll> sdake: ++, feels like a separate tag to me for can-upgrade-openstack vs supports-being-upgraded
20:43:45 <jroll> sdague: ^^
20:43:48 <lifeless> EmilienM: I know what it is, but your answer doesn't help\
20:43:50 <ttx> jroll: ++
20:43:50 <annegentle> dhellmann: yeah and does it need REST API info, that sort of thing
20:43:58 <sdague> jroll: yeh, that seems like a good idea
20:44:02 <lifeless> EmilienM: fuel is a deployment tool, and it has a service
20:44:02 <sdake> dhellmann wfm i am willing to finish the job ;)
20:44:07 <edleafe> sdake: is there any part of kolla that is long-running that would need a rolling upgrade?
20:44:08 <ttx> annegentle: and a service catalog entry
20:44:22 <annegentle> ttx: yeah
20:44:54 <ttx> Again, not saying that the type:deployment and type:packaging are bad ideas... I could see some use for them. But I think the motivation is a bit wrong
20:45:00 <sdake> edleafe not at htis time
20:45:10 <sdake> everthing in kolla itself is stateless
20:45:10 <ttx> if the goal is that you can assert tags
20:45:10 <edleafe> sdake: thx
20:45:12 <lifeless> sdake: where is kolla's state stored?
20:45:18 <jaypipes> ttx: I think the type:deployment serves a useful taxonomical purpose above and beyond any relation to assertion tags.
20:45:24 <annegentle> sdake: so to me sounds like a grouping that would then enable further tagging
20:45:27 <ttx> jaypipes: right
20:45:39 <annegentle> jaypipes: agree
20:45:39 <sdake> lifeless that is a long complciated discussion better left for a different forum :) come join us on #kolla to find out
20:45:41 <sdague> yeh, deployment tools aren't always obvious by their name
20:45:42 <jaypipes> jroll: ++
20:45:43 <lifeless> sdake: (excuse my ignorange :))
20:45:49 <edleafe> jaypipes: that sounds correct
20:45:52 <sdake> annegentle you got it
20:45:59 <sdague> so putting that into the mix seems like a good iea
20:46:00 <sdague> idea
20:46:02 <dhellmann> jaypipes : yeah, I just worry because we do have some release tools that use the type tags now, so we may have holes if we add a bunch of new ones. That said, these seem reasonable.
20:46:19 <sdake> lifeless its ok - I barely understand it myself ;)
20:46:23 <annegentle> dhellmann: these seem like an okay starting point
20:46:30 <dhellmann> annegentle : yep
20:46:31 <EmilienM> lifeless: excuse my ignorance too
20:46:37 <dhellmann> annegentle : with some refinement
20:46:39 <sdake> dhellmann i will help fix the release tools if i can
20:46:40 <lifeless> I'm +1 on  adding deployment, it seems like a no-brainer. The packaging one I am still confused by
20:46:49 <sdake> dhellmann i assume you are tlakingabout the release repo?
20:46:59 <ttx> dhellmann: right, I like type:deployment to describe tools that end up deploying openstack, and type:packaging to describe recipes/packages/cookbooks/playbooks thingies
20:47:01 <dhellmann> sdake : release and release-tools, yes
20:47:13 <sdake> dhellmann ok i'll hve to read up on release-tools
20:47:16 <sdake> -etoomanyrepos
20:47:34 <sdake> ttx that is exactly what i was ater
20:47:42 <sdake> perhaps it was worded poorly
20:47:46 <ttx> I just feel like those two definitions are off the mark and need some work. Happy to go through iterations with sdake
20:47:49 <sdake> i am open to suggetstions on language in the review
20:47:56 <jroll> IMO puppet/ansible/etc things are deployment tools, not packaging
20:48:00 <dhellmann> yeah, I think we can do that offline
20:48:02 <jroll> they don't produce an output
20:48:08 * jroll will comment in review
20:48:26 <ttx> jroll: yeah, but they are recipes that another tool will use to deploy a specific service, no ?
20:48:31 <EmilienM> jroll: right, and we actually consume packaging.
20:48:47 <fungi> and also can _be_ packaged
20:48:49 <jroll> ttx: yes, but they are not packages, they are essentially plugins
20:48:56 <fungi> (e.g., debian's packages of puppet modules)
20:48:59 <jroll> or rather, they are not packaging tools
20:49:29 <jroll> they don't produce a package, they are directives for a deployment system to read and execute
20:49:40 <ttx> jroll: right they don't contain the source code, but that's about the only difference
20:49:49 <sdake> i dont have expereince with pupept or chef so have hard time clarifyign their requriements
20:49:52 <lifeless> everyone openstack is packaged upstream anyway ...
20:49:58 <sdake> EmilienM if you do could you clarify what you would expect out of them in the review?
20:50:02 <sdague> yeh, I think it's worth just punting on the packaging thing because it's confusing, and no one really seems to need it right now
20:50:09 <sdague> the deployment tag seems useful
20:50:10 <ttx> a package is just source code bundled with metadata that a deployment system uses to install them
20:50:13 <EmilienM> sdake: sure thing.
20:50:25 <sdake> sdague wfm, i was just following through on ttx's implied request
20:50:44 <ttx> a plugin/recipe/cookbook/playbook is just that packaging metadata
20:50:49 <lifeless> ttx: well, install system to install... deployment systems are (IMO) really a abstraction layer up again..
20:51:09 <sdague> sdake: yep, no worries. Lets just on-demand solve problems we need to solve, and leave the philosophy of packaging to bars in austin :)
20:51:19 <ttx> lifeless: sure. But puppet-trove should imho get type:packaging, not type:deployment
20:51:26 <sdake> sdague wfm ;)
20:51:34 <ttx> it's metadata that Puppet uses to deploy trove.
20:51:42 <annegentle> sdake: sdague: heh
20:52:13 <sdague> ttx: by that regard devstack is packaging. I think there are so many grey areas here we can go in circles for ever.
20:52:19 <jroll> ttx: I guess it depends if the packaging tag is about tools to produce a package or packages themselves :)
20:52:28 <annegentle> sdague: eeeeek
20:52:32 <lifeless> ttx: Lets defer packaging for now :). Life is too short.
20:52:33 <ttx> My head hurts now
20:52:35 <jroll> but yeah, agree on punting on packaging
20:52:38 <sdake> jroll in the case of kolla, we hve a script which abstracts ansible
20:52:38 <sdague> lifeless: ++
20:52:39 <EmilienM> ttx: I don't understand why, puppet-trove deploy trove using packaging provided by ubuntu/rdo/whatever, isn't?
20:52:41 <sdake> shell script
20:52:49 <sdake> ansible deploys containers
20:52:55 <sdake> containers contain packaging metadata
20:53:01 <sdake> ansible contains deployment tooling
20:53:01 <sdague> turtles all the way down
20:53:02 <ttx> EmilienM: too many ways to slice it I guess
20:53:10 <ttx> sdague: yep
20:53:18 <ttx> Oh well, let's iterate on the review
20:53:30 <sdake> please, i think we cant solve it in this meeting ;)
20:53:32 <ttx> #topic Open discussion
20:53:33 <edleafe> the important thing, IMO, is how a user would view the tool
20:53:36 <sdake> that is why gerrit rocks ;)
20:53:42 <jaypipes> heh
20:53:47 <sdague> edleafe: agreed
20:53:48 <jaypipes> that's a first.
20:53:54 <sdague> this information is for end users
20:53:54 <dims> sdake : is the idea that a version of kolla can deploy multiple versions of openstack? that's one way to differentiate between packaging and deployment?
20:53:55 <ttx> edleafe: yes, you should focus on the information you want to convey
20:53:56 * jeblair high fives gerrit
20:54:05 <ttx> Cross-project track planning still going at:
20:54:08 <sdague> gerrit gives jeblair back a 502
20:54:08 <sdake> dims only one version but we can also upgrade to the next
20:54:09 <ttx> #link https://etherpad.openstack.org/p/newton-cross-project-sessions
20:54:14 <annegentle> we need more proposals there right?
20:54:16 <jaypipes> jeblair: :)
20:54:18 <edleafe> sdague: heh
20:54:21 <ttx> we need more proposals indeed
20:54:24 <jeblair> sdague: HIGH-502
20:54:29 <sdague> jeblair: ++
20:54:34 <ttx> only 9 entries so far
20:54:40 <sdague> it's early, and was a holiday weekend
20:54:43 <annegentle> ok
20:54:43 * amrith wonders if we'll get to open discussion today
20:54:45 <sdague> I just sent out another reminder to folks
20:54:52 <anteaya> amrith: we are in it
20:54:52 <ttx> amrith: we are in open discussion
20:54:53 <annegentle> amrith: lucky you we're there!
20:54:53 <lifeless> I had a q for the TC as a whole - how did you perceive me during these last two cycles; would you like having me on the TC again, or not?
20:55:11 <amrith> that's odd, my status line didn't update.
20:55:11 <amrith> A shameless plug for feedback (lazy consensus reviews) on https://review.openstack.org/295887.
20:55:11 <amrith> Also a request for review on https://review.openstack.org/295733 and https://review.openstack.org/296489
20:55:27 <ttx> lifeless: my stats show you on the "active" quadrant. Your call :)
20:55:38 <anteaya> amrith: you have to tell folks why you are asking folks for reviews in the tc meeting
20:55:45 <ttx> I started the etherpad on the video pieces of advice for Design Summit session moderators:
20:55:49 <ttx> #link https://etherpad.openstack.org/p/austin-summit-video
20:55:49 * sdake wtb ttx's stats tooling
20:55:53 <ttx> If you have original points you want to make, please add to that ^
20:56:08 <dhellmann> amrith : if there are no negative reviews on those after a week they'll be approved
20:56:14 <jeblair> ttx: what i saw on the etherpad yesterday looked good
20:56:17 <amrith> dhellmann, thanks.
20:56:28 <ttx> So to complement lifeless point, TC nominations this week -- we are renewing the 7 seats currently held by jeblair, lifeless, flaper87, markmcclain, jaypipes, dtroyer, and myself
20:56:32 <amrith> anteaya, because I didn't know how 'lazy consensus' works.
20:56:36 <ttx> If you plan to run, don't forget to send your nomination before the deadline
20:56:37 <amrith> dhellmann, just clarified.
20:56:39 <amrith> so I'm all set.
20:56:43 <dhellmann> lifeless : ++ if you have the time an energy, run again
20:56:45 <ttx> If you plan not to run for reelection, announce that early so that it encourages others to run
20:56:52 <EmilienM> talking about tags: Puppet OpenStack group is currently applying for release:cycle-with-intermediary tag - please look https://review.openstack.org/#/c/297382/
20:57:02 <sdague> on the cross project session scheduling, who would like to be involved in that? I'll organize together folks next week. Typically it's anyone in the TC that's up for taking a few hours and weighing in.
20:57:29 <ttx> sdague: I'm fine helping
20:57:29 <fungi> also reminder, though you probably all know, nominations go to gerrit now. those who were last elected a year ago, that wasn't the case
20:57:39 <dtroyer> sdague: o/
20:57:42 <edleafe> lifeless: although it means more competition for me, I think you've done an excellent job and should run again if you're so inclined
20:57:47 <lifeless> fungi: is there a docs page on that ?
20:58:01 <ttx> lifeless: see email to -dev announcing election
20:58:02 <markmcclain> sdague: I can help out
20:58:06 <lifeless> ttx: thanks
20:58:32 <fungi> lifeless: good question. for the ptl elections it was documented at https://wiki.openstack.org/wiki/PTL_Elections_March_2016
20:58:48 <fungi> tristanC or tonyb should have a proper url somewhere
20:59:01 <anteaya> lifeless: on the wiki home page click governance
20:59:01 <fungi> was probably in the announcement about opening the nominations period
20:59:05 <ttx> I think it's TC and April for the TC one
20:59:12 <anteaya> lifeless: it lists all the election wikipages
20:59:15 <sdague> ok, I'll send out a general email get feedback from folks for a round of voting on things, then I'll sort out a good time to do synchronous block to actually slot things
20:59:16 <anteaya> current and past
20:59:23 <ttx> https://wiki.openstack.org/wiki/TC_Elections_April_2016
20:59:26 <lifeless> fungi: https://wiki.openstack.org/wiki/TC_Elections_April_2016#How_to_submit_your_candidacy
20:59:33 <tristanC> are you looking for https://wiki.openstack.org/wiki/TC_Elections_April_2016 ?
20:59:33 <fungi> yep, that looks like it
20:59:50 <lifeless> sdague: I'll happily contribute time
21:00:00 <lifeless> sdague: if the meeting is vague asiapac sensible; if its not thats ok
21:00:05 <ttx> sdague: do you have a closing date for cross-project suggestions ?
21:00:11 <lifeless> sdague: I'm sure the outcome will be an epic compromise as always :)
21:00:11 <sdague> ttx: yes, end of the week
21:00:23 <sdague> per initial post
21:00:37 <flaper87> (time)
21:00:47 <sdague> http://lists.openstack.org/pipermail/openstack-dev/2016-March/090201.html
21:00:50 <ttx> time indeed
21:01:02 <ttx> Thanks everyone
21:01:10 <ttx> #endmeeting