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