20:03:06 #startmeeting tc 20:03:06 Meeting started Tue May 12 20:03:06 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:10 The meeting name has been set to 'tc' 20:03:12 Today's meeting agenda: 20:03:16 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:03:24 #topic Update tags in projects.yaml based on validate_tags 20:03:29 #link https://review.openstack.org/179269 20:03:38 Let's start easy 20:03:42 I think all of those make sense. 20:03:54 We should probably have some bot to propose those regularly, instead of relying on Joe 20:04:09 ttx: ++ 20:04:12 o/ 20:04:26 jogo isn't a bot? 20:04:28 We already have 7 +1s so I'll approve it soon, unless someone objects 20:04:38 jeblair: not yet 20:04:43 jeblair: :) 20:04:43 o/ 20:04:59 jogo: for the commit message, you have for openstack-manuals "Ignored since has stable/juno just not Kilo" meaning, not changing the tag since we intend to have stable/kilo? 20:05:07 o/ 20:05:32 So, waiting 30 more seconds and will approve 20:05:43 annegentle: correct, I said that under the assumption that you will soon have a stable/kilo branch. since my understanding is docs are released after 20:05:52 jogo: yep, sounds good 20:06:25 ok approved 20:06:31 wait! 20:06:36 just kiddin. 20:06:38 #topic Add tc-approved-release tag for trademarkable projects 20:06:52 jaypipes: save you energy for the next topics :) 20:06:56 he 20:07:04 For this topic and the next, I don't expect final resolution this week, and I think we can discuss some of it in-person next week 20:07:10 and your long arm 20:07:17 So I'll aggressively timebox the discussion on those so that we have time to cover other topics 20:07:24 So... tc-approved-release 20:07:31 #link https://review.openstack.org/179799 20:07:44 To summarize the discussion so far, I think the tension here is between two approaches 20:08:01 dhellmann defines a set of rules that may be used as a "TC stamp" filter on top of the natural deliverables of OpenStack project teams 20:08:11 jaypipes fears we'll soon be back into judging projects value, something we've been trying to get out of 20:08:26 Personally I would be fine with the 'tc-approved-release' just designating all the code repositories that are server API stuff produced by OpenStack Project Teams 20:08:40 That said, I think nothing in Doug's text really prevents us from doing that "inclusive" approach 20:08:55 ttx: the upgradeability thing would. 20:08:56 In particular, "the TC considers the project suitable for consideration for trademark use" is definitely compatible with an inclusive approach. 20:09:11 so, the point of this tag is from it the board can pick stuff for trademarking, right? 20:09:17 yes 20:09:20 yes 20:09:25 tc-eligible-trademarks ? 20:09:31 if we want to defer all of that decision to the board, then I'm ok with something like what ttx proposes 20:09:33 it's the superset of projects used when developing commercial trademark programs 20:09:36 sdague: the point of the tag is to replace the defcore use for "integrated release" 20:09:43 lifeless: I chose the name based on the way it is described in the bylaws 20:09:49 lifeless: I hate the name, but consistency 20:09:50 dhellmann: yes, I saw that prose. 20:10:01 they used to pick within the integrated release, they will pick within the tc-approved-release tag instead 20:10:13 does it make sense to let the tail wag the dog a little here and say, "hey board, what do you actually want in this" and we then decide if we're cool with that answer and send it back as such? 20:10:23 dhellmann: I value consistency less than clarity here, since none of the other tags are mapped to the bylaws. 20:10:30 dhellmann: there's nothing to be consistent *with* 20:10:33 sdague: we did try that last year, like three times, remember? :) 20:10:37 I'm wondering if the requirements could be tags rather having a separate set of requirements to judge 20:10:53 because, honestly, I feel like my opinion of "trade markable" seems pretty useless 20:10:57 zaneb: that is *precisely* what I was after. 20:11:01 sdague: indeed, wait for demand ... it'd be nova, glance, keystone, swift, cinder ... something like that 20:11:02 sdague: haven't we tried that already though? 20:11:05 Hmm, taking a step back for a moment 20:11:09 jaypipes: zaneb: +1 from me 20:11:20 so we need to decide how much we care about the trademark decisions, and whether we want our recommendations for trademark use to reflect just community participation or also some level of quality -- I expect defcore to apply the latter filter whether we do or not 20:11:21 sdague: not saying I disagree, just saying historically that hasn't worked so well 20:11:33 jgriffith: no, I don't think we did, I thought we said "we're not culling the list for you" 20:11:34 We are in this situation because we ended up designating the full "integrated release" as trademarkable components rather than a subset of it, if mordred remembers 20:11:44 the decision back then was... 20:11:49 I think we have a set right now - it's what has been the integrated release 20:11:51 lifeless: I am trying to be consistent with the way the board will talk about this list of projects 20:11:52 dhellmann: what if we just have trademarked tag and the board is responsible for assigning it :) 20:11:54 I'd suggest that we don't change it 20:11:54 that we should not pick out a subset 20:12:02 mordred: ++ 20:12:05 mordred: sure 20:12:05 since all of it is "openstack projects" 20:12:07 and that in the future we don't change it until someone makes a request 20:12:14 zaneb: I wondered that too, but I think the tags inform the board's selections, and the point is having a wide base to select from, I believe. 20:12:15 mordred: ++ 20:12:17 really don't think it's worth wasting too much time on this 20:12:19 and at that point, consider that request like people 20:12:20 mordred: right, that's where I was headed, but you got there more clearly 20:12:21 but for now 20:12:27 defcore isn't going to move beyond what was in integrated release *any* time soon 20:12:29 mordred: yes, that's fine. I'm trying to define some set of things we'd evaluate at that point 20:12:32 I doubt any human is going to request new projects be added to the set for a WHILE 20:12:36 dhellmann: totally 20:12:38 mordred: agree 20:12:43 dhellmann: so, I *don't want* a tag that says 'approved' unless thats actually what it means. 20:12:50 mordred: hrm. i would expect it almost immediately. :) 20:12:54 IF we are going to be approving, not just passing-through, fine. 20:13:03 jeblair: what would you expect? 20:13:09 doing otherwise sends entirely confusing messages everywhere. 20:13:13 jeblair: what would you expect the board wants to build a trademark on? 20:13:17 russellb: someone to ask for an expansion of the tc-approved release. 20:13:18 adding to the set is pretty meaningless unless defcore is doing something with it 20:13:21 and education 1000 contributors is harder than educating 20 board members 20:13:43 russellb: true, but if we're the first hurdle expect to be jumped 20:13:43 lifeless: you sure about that? ;) 20:13:49 lifeless: agreed, I cought up with the review earlier this week and if it weren't for dhellmann's note, I'd have been really confused 20:13:51 mordred: then how about a simplified tag definition that says "this tag describes the a superset of trademarkable projects as requested in the bylaws" ? 20:13:51 i would expect the big-tent projects to ask for that, and then for us to be in the position that we were previously if we set ourselves up as gatekeepers. 20:13:54 jaypipes: well, they did vote me in. So no. 20:13:58 heeh 20:14:13 ttx: like it 20:14:35 jeblair: sorry - by "people" 20:14:40 I want to remove any other cumulative meaning, otherwise we are back at square one 20:14:40 jeblair: so, being in that tag is only useful if there is a trademark program on the horizon. So I believe we limit requests to modify it from the board 20:14:41 I meant the Board or the User Committee 20:14:45 jeblair: that is precisely my worry, as I noted on the patch comments. 20:14:46 mordred: OUCH. 20:14:51 unless the board or the user committee requests of us that we add a new project 20:14:58 I'd suggest taht we not 20:15:31 that way someone like Tim Bell can say to the user committee -"hey, we'd REALLY like it if magnum were considered a reuqired thing" 20:15:36 which is great input for us 20:15:38 yes, that's a good idea 20:15:42 we really don't want to be wasting our time on this 20:15:48 I think removing projects we have now is rife with peril and not worth it 20:15:49 mordred: my lack of personhood aside, that's an interesting approach. so we act with discretion, but only accept input from certain channels. 20:15:50 mordred: ++ (again) 20:15:50 it's not even about being a required thing 20:15:52 Frankly, I don't think that matters that much. 20:15:54 jeblair: ++ 20:15:58 mordred: one caveat 20:16:05 so that we don't become uber gatekeepers again 20:16:10 which is very borin 20:16:10 what if e.g. nova and neutron and cinder factor out their quota stuff to a new service 20:16:16 we'd include that as its a transitive dep? 20:16:25 or we'd consider it plumbing and just dep on it, not trademark it? 20:16:29 mordred: how about if we make that the defcore committee, since we're already discussing these issues with that group? 20:16:37 lifeless: I'd say one of us should personally nudge the user committee to get them to ask us to add it 20:16:41 dhellmann: sure 20:16:47 I'm fine with anywhere 20:16:57 just saying I think the world of projects asking for blessing is a fail 20:16:57 lifeless: I do not believe there will be an OpenStack Quota Service (tm) certification effort 20:16:58 mordred: I just want to be sure we don't setup a blockade to such improvements 20:17:02 lifeless: totally 20:17:07 mordred: and would we just always agree? or are there conditions under which we would not? 20:17:10 sdague: one hopes ;) 20:17:14 dhellmann: no, I think we can TOTALLY say no 20:17:21 this tag means nothing about anything except trademarks 20:17:31 I think saying know is where we add value to the whole process… 20:17:31 it doesn't mean what's required in an installation 20:17:32 dhellmann: I just think someone other than projects looking for validation needs to be the instigator 20:17:39 sdague: ++ 20:17:39 sdague: doesn't even mean trademarks, since it's a superset 20:17:51 so if its a superset 20:17:53 it's just a safety net 20:17:56 and it's also only commercial trademark programs, nothing to do with community use of the trademark 20:17:56 where is the tag that is just trademarks? 20:17:59 mordred: do we want to list any details about those conditions, or just leave it up to the discretion of the tc at the time? 20:18:03 lifeless: not ours 20:18:04 ttx: safety net is a good summary 20:18:06 sanity net 20:18:11 lifeless: that's the board's decision 20:18:20 lifeless: there's a whole repository for the defcore work 20:18:24 I know 20:18:32 jeez leading questions that get literal answers 20:18:59 the tc-approved-release is a safety net so that defcore doesn't require something we would not consider part of openstack 20:19:00 lifeless: we have a responsibility under the new bylaws to produce this list. The other lists are someone else's job, so I didn't tackle them. 20:19:02 dhellmann: I honestly think we should cross the bridge when we get there 20:19:11 the odds that that would happen at this point are pretty nil 20:19:21 but the safety net is still described in the bylwas 20:19:22 dhellmann: we have SO MUCH WORK to do before we run out of defcore-able capabilities that aren't in the thing yet 20:19:32 mordred: yes, let's lazy evaluate here 20:19:36 mordred: I'm ok with some sort of vague "we'll think about it" statement, but I suppose jaypipes wouldn't be 20:19:43 that we can flesh them out for a while before we get to a burning need to accept somethign new 20:19:50 dhellmann: jaypipes loves those statements 20:19:55 russellb: that isn't correct, the bylaws don't distinguish between commercial and non-commercial now 20:19:58 * mordred hands jaypipes a nice warm ham 20:20:01 * jaypipes still struggling to read back... :*( 20:20:04 russellb: but it is implied 20:20:11 I could even phrase it as "We don't know the criteria we would use, yet, so we'll have to figure out what to do at the time." or some such 20:20:15 jogo: yes it is, there's a very nice summary from jonathan in a ML post 20:20:22 dhellmann: just punt entirely. 20:20:33 lifeless: what form would that take? 20:20:41 dhellmann: 'this is the set of projects the board may choose to trademark, as decided by the TC.' 20:20:59 lifeless: that is decent punting 20:21:01 how do things get added? ask the tc. 20:21:04 here's my understanding of the current proposal: Only DefCore can ask that this tag be applied to a project. We will figure out what to do when they do that. 20:21:07 how do things get removed? ask the tc. 20:21:34 * jaypipes believes this particular conversation would be best held in person on Sunday... 20:21:34 we have to work out processes and policies for removal with defcore, so that's already punted 20:21:36 dhellmann: thats setting a policy we havent had previously (because previously we decided what was integrated) 20:21:37 dhellmann: ++ 20:21:38 very difficult to follow the high speed interleaves. 20:21:47 lifeless: that is the policy in the bylaws 20:21:51 jaypipes: yeah. 20:21:55 jaypipes: ++ 20:21:59 Yep, and I don't think we'll finalize that discussion in meeting 20:22:02 jaypipes: i've kinda given up 20:22:04 sorry, jaypipes, I'm trying to reply to everyone 20:22:06 I'd like us to move to next topic 20:22:08 dhellmann: last I read it the TC decides on the integrated release 20:22:08 * flaper87 will be a bit late on Sunday but there's dinner after, right? :D 20:22:08 k 20:22:12 we can finalize next week 20:22:18 dhellmann: unless you switched subject mid-stream. 20:22:19 dhellmann: no need to say sorry whatsoever :) I understand completely. 20:22:20 jaypipes: ++ 20:22:28 or is that object ? :) 20:22:37 lifeless: preposition 20:22:38 lifeless: I haven't ever been talking about the integrated release 20:22:50 speaking of interleaving... let's ditch our threading model! ... discuss! 20:22:56 * mordred interleaves jaypipes 20:23:01 jaypipes: thats much more fun 20:23:01 hehe 20:23:02 * dhellmann deadlocks 20:23:10 dhellmann: ok, I think I need to review on the review. 20:23:11 OK, I suggest we keep the discussion open on that and move to next fun topic 20:23:14 so we can move on 20:23:17 ++ 20:23:20 ++ 20:23:25 * flaper87 kills all the threads and asks the scheduler (ttx) to switch 20:23:36 this meeting is kind of a bloodbath 20:23:38 trampoline time 20:23:43 also aggressively timeboxed so that we get a feel before we discuss more directly next week 20:23:49 #topic Add compute kernel tag 20:23:52 ttx: because the next topic is sure to go better ;) 20:23:56 #link https://review.openstack.org/180112 20:24:01 it's like a ladder or hill :) 20:24:02 On this one there seems to be two areas of tension 20:24:04 yeh, so... vibrant discussion 20:24:09 First one is more around which use case the "kernel" should serve 20:24:13 level up! 20:24:14 ephemeral compute (keystone / nova / glance) 20:24:19 or non-ephemeral-compute (keystone / nova / glance / cinder / designate?) 20:24:29 I don't have a strong opinion on it, but I think I'd prefer if we could have a single one 20:24:44 Also it feels a bit weird to me to include Designate in the strongly-required set, given how few people actually implement it 20:24:45 is anyone really advocating/testing no auth compute still? 20:24:55 I also like sdague's idea that "enhancements" replace function that already exists in the kernel with a more feature rich version 20:24:55 ttx: +1 20:25:04 annegentle: no, plus I broke it last cycle probably 20:25:08 sdague: nice 20:25:09 does no one think that if mordred and sdague can't even agree, then there's no way that one or two use cases can represent the whole community? 20:25:18 Second area of tension is about the usefulness of the tag, but maybe we can come to that in a few 20:25:31 designate is absolutely required for non-ephemeral compute 20:25:34 zaneb: the goal is not to represent the communitgy 20:25:41 jeblair: why? 20:25:42 zaneb: "represent the whole community" is not the point 20:25:55 then maybe it should be 20:26:00 jeblair: so... it's not in any way integrated to nova today from what I can tell 20:26:02 jgriffith: because reverse dns is required to run production systems 20:26:04 the goal is to describe a base set of projects to implement basic compute stuff 20:26:14 zaneb: the community HAS a lot of different use cases. theyre ALL valid. a single tag will never represent them all. 20:26:17 I did go diving looking for code 20:26:27 why does it take the TC to officially designate that? 20:26:31 sdague: i thought it used nova notifications to do its thing 20:26:36 sdague: but it has been ages since i looked honestly ... 20:26:42 russellb: don't know, haven't ever seen it working 20:26:43 jeblair: by who's "requirements", and it doesn't have to be designate as many providers/implementors will atest 20:26:43 devananda: I couldn't agree more 20:26:44 zaneb: it doesn't, but nobody proposed the tag, so sdague did 20:26:48 sdague: same here 20:27:09 ok, so can we discuss background, before we just go full pitchfork? 20:27:15 zaneb: "it's not everything to everyone" does not invalidate taking one measured step in the right direction 20:27:16 ttx: so... because we can? 20:27:20 * jgriffith puts his torch down 20:27:25 sdague: please do proceed. 20:27:26 sdague: go, background 20:27:33 jgriffith: I do not care about what non-openstack services people might want to run 20:27:42 my job is to talk about what a complete openstack might look like 20:27:45 one of the things that is really freaking our user community in the big tent is "where do I start?" 20:27:48 people can also run vmware instead of nova 20:27:57 but that doesn't mean I'm not going to advocate taht we need nova 20:27:58 I think it's good to have inclusiveness 20:28:07 mordred: let sdague talk please 20:28:13 oh. sorry. 20:28:42 however, I do think we need a reasonable starting point that can be built upon, including adding enhancements of other projects over time 20:28:57 sdague: also it was about the only tag the Ops really wanted defined when we discussed tags at the Ops midcycle 20:29:06 ttx: that's good input 20:29:16 that seed corn helps all of the community get a piece of openstack up, and expand and include more of our ecosystem 20:29:34 sdague: I entirely agree with you. I just happen to disagree that this particular tag definition adds that clarity of purpose. 20:29:38 sdague: so I completely agree with your statements thus far, and have had the same feedback from deployers 20:29:55 sdague: but I agree with jaypipes on the naming of the tg 20:29:55 jaypipes ok, so how would you expect to approach this? 20:29:56 tag 20:30:04 sdague: "where do I start problem" is real. long-form full-sentence documentation is a better answer, because not everyone should start at the same point 20:30:07 this was the best idea I had so far 20:30:34 I love sdague's tag 20:30:40 I just think it needs to be either smaller or two tags 20:30:40 zaneb: I think as a community we do need to say "start here" 20:30:42 sdague: thank you for getting through the background on this 20:30:49 does our installation guide not already do that? 20:30:52 and people can be different 20:30:55 FWIW, I'm +1 on having such a tag. I think the name can be tweaked though (and I am happy to bikeshed that in the review) 20:30:59 or at the very least say: "most people start here" 20:31:08 it's open source, you can always be different 20:31:11 dhellmann: apparently not clearly enough, since Ops asked for the base seed corn too. 20:31:26 but providing some base guidance gets more people rolling instead of staring at a blank wall 20:31:32 I was surprised to see such need coming from that experienced population, but it was there 20:31:36 I guess I'm trying to figure out how this is "different" than what we "used" to call core OpenStack 20:31:41 ttx: is that a bug against the installation guide? 20:31:45 sdague: long-form full-sentence documentation is still a better answer, because it contains more than 1bit of information. people can use it to figure out where to go after the starting point 20:31:51 sdague: an excellent question :) I've been pondering it most of the afternoon. I think I'd prefer to go down the route of having super-fine-grained tags for things like production maturity, deployability options, relation to other components, and then maybe have a "deploy:simple-compute" tag that is a "calculated tag" that looks at the existence of other fine-grained tags and groups things together. 20:31:52 I fully agree it's needed, valuable, important etc 20:32:06 jgriffith: the old thing meant far more than an informative starting point 20:32:10 jaypipes: ok, so they need to build a turning complete evaluation system? 20:32:11 dhellmann: I'd argue it's not a bug of the install guide, it's not meant to answer that question at all 20:32:17 jaypipes: hm hadn't thought about calculated tags 20:32:25 jaypipes: I find it very interesting that you want to have subjective tags for things like "maturity" :-) 20:32:30 because... that's not going to be confusing at all :) 20:32:33 russellb: understood, but that's kidna what people want 20:32:36 ttx: fair 20:32:43 russellb: and it doesn't mean we can 'redefine' it either 20:32:49 sdague: no more than what dhellmann and jogo have already put together for the tags like diverse-affiliation 20:33:01 ttx: question to ops was what tags to have, not best way to communicate a starting point. of course a tag was the answer 20:33:06 honestly this tag would help docs scope the install guides 20:33:07 jaypipes: I was thinking minimal, not simple. 20:33:11 jaypipes: because simple is a lie :) 20:33:13 I disagre that long-form full-sentence docs are better-andtherefore-we-dont-need-simple 20:33:13 dhellmann: I don't want *us* to be that subjective body. I would prefer operators be the arbiter of maturity. 20:33:18 lifeless: right, minimal 20:33:22 which is the implication folks seem to be presenting repeatedly 20:33:24 lifeless: ok, sure. :) 20:33:28 I agree full docs are great and necessary 20:33:31 jaypipes: me, too! We should ask them to start a guide with this information somewhere else. :-) 20:33:38 zaneb: not really. Question was "do you want a base set of projects around compute defined" 20:33:43 but folks are looking for a clear and simple signal of what they should go read the docs about 20:33:46 dhellmann: I think that is already underway :) 20:33:49 right, the feedback has been long form docs do not fix this for people, they really do want minimal starting point 20:33:59 jaypipes: wonderful! 20:34:00 sdague: right it's why devstack is oft-used 20:34:05 can we take a step up. We have a request from the operators and broader community to document a thing which is 'minimal starting point'. 20:34:10 which I realize is not your pov zaneb, but it's the community feedback 20:34:29 so part of what we are trying to describe here are the technical relationships, such as to do x (say, minimal compute) you need these things 20:34:31 We should document this clearly, and there is no reason to document it just one way. E.g. docs + tags + $other? 20:34:33 minimal compute projects I believe 20:34:42 dhellmann: http://lists.openstack.org/pipermail/openstack-operators/2015-May/006881.html 20:34:44 does anyone *disagree* with those two lines ?^? 20:34:51 maybe also minimal storage but I wasn't in the session 20:34:57 dhellmann: and http://lists.openstack.org/pipermail/openstack-operators/2015-May/006933.html 20:35:11 annegentle: honestly, the ops feedback is about a compute cloud 20:35:23 sdague: yeah that was my hunch 20:35:24 jaypipes: cool, I saw reed's email but hadn't seen any follow up 20:35:25 because swift is just swift, that's pretty clear, the batteries are all included 20:35:31 sdague: right, and I'm glad that people are looking out for the present. but I think we also need to really look out for the future 20:35:32 sdague: I do think storage is a great entry point 20:35:43 ok, 5 more minutes 20:35:51 sdague: were there OPs not running a compute cloud present? (out of curiosity) 20:36:07 "to do x you need y" is not something you can effectively tag if there are z ways to do x where z>1 20:36:07 (or did we get feedback from them?) 20:36:08 flaper87: in phili, I don't think so 20:36:12 sdague: thnx 20:36:15 I want to quickly come back to the "ephemeral or persistent" question 20:36:27 fungi: but thats not the request. The request is 'whats the onramp' 20:36:44 lifeless: more than just "more than one way" the impression I have is that the community explicitly wants a signal and they want comprehesive docs. these are complementary, not duplicative. 20:36:51 fungi: we can objectively describe that: its the minimum set, and where there are N candidates, the candidates most commonly used by peers. 20:36:54 I plan to go back to the same ops group and ask them which makes the most sense. I bet they will pick the most minimal set 20:37:00 lifeless: i was responding to dtroyer's characterization of the problem 20:37:02 devananda: yes. 20:37:03 how about if we rename this tag use-case:compute-something-something and not "kernel" or "base" or whatever? 20:37:23 ttx: I'd vote for minimal set right now, with something like sdague 's verbiage around "enhancements" for DNS, etc 20:37:24 ttx: i think that sounds like a good way forward. make sure we understand the request clearly and then satisfy it. 20:37:27 yeah, thats why I want to bikeshed on the name 20:37:30 because if we're really just talking about use cases, then we'll have lots of those in parallel 20:37:36 ttx: and then do the same for a storage cloud + enhancements, and so on 20:37:41 sure, the name isn't important to me 20:37:43 ttx: because i think we're doing this for the ops. 20:37:44 dhellmann: indeed 20:37:50 dhellmann: to me a kernel:foo is a use-case:mininam-foo 20:37:51 I think the concept of "start here" 20:37:53 ttx: (and indirectly for the users) 20:37:55 for ops! 20:37:59 minimal* 20:38:05 and then clear paths to upgrade features as you go in that live env 20:38:15 instead of "kernel:compute", how about something like "use-case:ephemeral-compute" or "use-case:test-and-development" or "use-case:enterprise-it"? 20:38:22 ttx: kernel to me implies always-present, and consider nova-network -> neutron, its not. 20:38:26 ttx: but thats perhaps just me 20:38:31 it's like we're writing a thesaurus entry for 'core' 20:38:36 edleafe: ++ 20:38:36 jaypipes: what is "enterprise-it"? :) 20:38:41 can we have more than a starting point? "For a compute based cloud start here" 20:38:45 devananda: heh, touche. 20:38:50 devananda: pets 20:38:52 jaypipes: and what if you are an org that has 2 of those needs 20:38:55 devananda: "to enterprise" is "to make excessively complex" 20:39:02 edleafe: :) 20:39:04 edleafe: bingo 20:39:04 minimal-compute 20:39:04 seems like much of the objection is that these tags will be opinionated and subjective. but that really sounds like the request: "tell us what you want us to install" 20:39:07 ok, you broke me. kernel:pets has my +1. 20:39:15 sdague: then you use the projects that are the union of both tags. 20:39:37 OK, we need to move on. Let's continue that discussion next week and the next meeting too 20:39:39 how about a tutorial for a specific,, three node (ops talks a lot about that) compute cloud? 20:39:44 fungi: which is why I want to describe things that are technical requirements + options, and not try to solve use cases 20:39:48 russellb: we do that 20:39:49 jaypipes: well, I don't think that solves the problem. If you want to run with that approach, so be it 20:39:51 er 20:39:58 how many tags are we up to now? 20:40:02 Rockyg: the Install guides have three basic architectures 20:40:03 2^15 20:40:13 zaneb: http://governance.openstack.org/reference/tags/ 20:40:21 zaneb: http://governance.openstack.org/reference/tags/ 20:40:24 Feel free to engage on the review 20:40:27 gah, russellb 20:40:27 why not have experienced operators tell us where new operators should start, instead of the TC telling them? 20:40:32 * jaypipes shakes fist 20:40:34 annegentle: but a tutorial format? The ops guys want a useful "my first cloud" to test 20:40:45 zaneb: right, which would basically be this list 20:40:46 zaneb: see the 2 email threads jaypipes linked earlier 20:40:48 russellb: I meant proposed in this meeting 20:40:50 ops people perhaps? 20:40:57 it's consolidated down from that feedback 20:40:59 Please -- let's switch to next topic 20:41:03 ++ 20:41:06 We con't finish this one today 20:41:07 ++ 20:41:13 k 20:41:20 #topic Workgroup reports 20:41:25 * Communications workgroup 20:41:32 annegentle, flaper87: how is that going? 20:41:42 ttx: I've put together a draft comm plan 20:42:05 #link https://etherpad.openstack.org/p/TC-communications-plan 20:42:09 some points to discuss: 20:42:23 I think we got a fair feedback from the thread sent to os-dev, at least to help us get started 20:43:00 I need to get with reed to see how to schedule this with the current Community newsletter that goes out Friday 20:43:19 Also, I'm not wanting to maintain a separate twitter account for the tc 20:43:27 annegentle: ok, so still work in progress 20:43:29 sounds like we agree on that 20:43:42 annegentle: agreed, use own twitter handles 20:43:45 folk can follow the new tc each cycle, if they care. 20:43:50 yeah, I think we can leave that one off 20:43:54 annegentle: anything you need urgent input on? 20:44:02 I think the judgement call will be on the cadence of messaging. 20:44:25 I think we've got this, next is implementation. I'd like to write a summary blog post this week and get the tags right. 20:44:31 just wanted to vet the plan here 20:44:35 I thought we already said we would end each meeting with a discussion of what might need to be published? 20:44:55 dhellmann: sounds good 20:45:01 dhellmann: ok, let's try that today 20:45:02 dhellmann: I thought that was more a communication-team thing but it sounds good to me 20:45:04 :P 20:45:05 we had a previous attempt at the blog posts, what can we do differently to ensure it keeps up this time? 20:45:12 Let's speed through the remaining topics then 20:45:16 (by get the tags right I mean Wordpress tags that go to planet.openstack) 20:45:37 russellb: I think it's that flaper87 and I are accountable for a go-no go call on blog post this week? 20:45:52 annegentle: ++ 20:45:52 annegentle: OK, so more clear ownership, makes sense 20:45:55 now that I don't have to write What's Up Doc weekly I feel I can keep up. 20:46:01 * Project Team Guide workgroup 20:46:12 We've started putting together an outline of what we should cover 20:46:17 #link https://etherpad.openstack.org/p/project-team-guide 20:46:26 I think this is pretty solid and shall make an interesting read 20:46:38 Once the outline is ok we shall discuss how to make it happen 20:46:47 I'm tempted to try a two-day online sprint 20:47:09 ttx: can we try something at the summit? Friday? 20:47:18 ttx: we wrote a big chunk of infra-manual that way with considerable success 20:47:27 not sure if it'll work with other folks schedules 20:47:29 flaper87: I already work on fixing the world Friday 20:47:57 * flaper87 will try to fix the universe 20:48:02 virtual sprint worked fine for infra-manual 20:48:07 * jeblair subscribes to both newsletters 20:48:09 Anyway, the outline needs to mature a bit, no uregnt input needed at this point 20:48:16 yeah, I'm already over booked next week so let's try this online 20:48:25 #topic Other potential workgroups 20:48:31 * flaper87 really wants it to be called: "Project's welcome package" 20:48:36 I had a few extra areas to suggest we work on (or improve on) 20:48:43 Architecture! 20:48:46 The first is how we handle cross-project specs and the cross-project meeting 20:48:52 I know jaypipes and I are both interested in that :) 20:48:55 We introduced cross-project specs (and the new format for the cross-project meeting) last cycle 20:48:59 lifeless: ++1000 20:49:12 I wouldn't describe the result as a clear success. The specs don't get a lot of attention, and the meeting is pretty desert 20:49:22 I'd welcome a workgroup to suggest improvements on that front 20:49:35 I'd also like to more aggressively rotate chairs on the cross-project meeting... 20:49:46 When we started we said we would rotate but I ended up doing 82% of them and dhellmann the remaining 18% 20:50:09 Anyone interested in working on that ? 20:50:25 I should have time to take on more of them, this cycle, if we decide we're going to keep having them. 20:50:40 I would put openstack/requirements in the same bag/workgroup, but since we might change what those mean pretty soon, probably better to wait for that 20:51:06 lifeless: Architecture... what would that workgroup do exactly ? 20:51:06 I don't think the ownership will change 20:51:22 ttx: rant and rave about the terrible things that cause us problems? 20:51:37 lifeless: sounds like fun! ++ 20:51:40 I thought that group met regularly 20:51:43 lifeless: you have to be on a committee to do that? 20:51:56 ttx: or more usefully, identify such things and work with projects to get fixing them prioritised, and help them get resources to do it 20:52:05 sdague: I don't know. 20:52:07 lifeless: ++ 20:52:21 sdague: workgroup to me isn't a committe per se, its interested folk working together? 20:52:49 sdague: I'm pushing on this already myself, - it is in part why I'm down in the plumbing of pip atm 20:52:50 yes, by workgroup I mostly mean a defined group of interested people that can own a problem space 20:52:51 lifeless: agreed. the trick is to ensure that the group is productive... 20:53:04 jaypipes: perhaps we should have alcohol in vancouver and come up with a plan. 20:53:09 which brings me to the last point I wanted to make 20:53:13 lifeless: sounds good to me. 20:53:15 3rd-party participation to TC workgroups 20:53:19 lifeless: ++ 20:53:25 I don't think there is anything we will do in those workgroups that prevents non-TC-members from participating 20:53:34 i suppose we could have short term workgroups for key project issues ... like tracking/helping with the nova-network/neutron situation 20:53:36 Only TC members will ultimately vote, but non-members can still work in the workgroup to prepare the decisions 20:53:40 ttx: agreed 20:53:45 Thinking in terms of succession planning, that could be a nice stepping stone for future candidates 20:53:48 we've seen good collab in the API working group 20:53:58 ttx: I personally feel the API WG has been extremely successful in both gathering 3rd party feedback as well as being productive in putting out guidance documentation. 20:54:12 jaypipes: yep 20:54:22 ttx: i like that thinking 20:54:26 ttx: I don't necessarily see working groups as a TC-dominated or controlled thing. 20:54:44 ttx: more that we should ensure that TC members are active participants in working groups. 20:54:50 jaypipes: more like TC-initiated 20:54:54 edleafe: ++ 20:55:01 edleafe: doesn't need to be, but sure :) 20:55:22 jaypipes: well, the thing under discussion is working groups of the TC 20:55:27 so, i think by definition, yes 20:55:42 ok 20:55:42 Right, so let's make it clear those are not TC subteams, just work groups that happen to be spawned by TC members 20:55:58 ok 20:56:03 ttx: ++ 20:56:05 jeblair: so, api-wg just grew up out of need, some TC members involved, but not a TC umbrella thing 20:56:25 I kind of thing that's more successful model long term. We're only 13 people. 20:56:35 The community is large and lots of super smart people in it 20:56:37 jaypipes: ttx: edleafe: +1 on all that 20:56:38 right, we seed those 20:56:45 #topic Open discussion 20:56:45 right, WG's, not SC'. 20:56:51 thoughts on making neutron/nova-network a workgroup? i think that's something important we should be checking in on regularly. 20:56:52 Two things to cover before we end 20:57:03 Did you think of topics we could discuss at the joint Board/TC meeting ? 20:57:11 russellb: looks to me like nova and neutron have their stuff together on it 20:57:11 russellb: we should see if we still have livers left after vancouver :) 20:57:13 In particular, anything we struggle with on the upstream side that the Board could help us solve ? 20:57:19 ttx: none that I can say on a public IRC channel. 20:57:24 jaypipes: !lol 20:57:27 ttx: tags? 20:57:43 devananda: you mean tags the board would find useful ? 20:57:52 or present the current status of tags ? 20:57:58 ttx: and the trademark thing too 20:57:58 tags ++ 20:58:05 ttx: yea. though I'm not sure we have any yet 20:58:11 ttx: here's one topic: "What is the board actually doing to enforce the contribution requirement of Platinum members?" 20:58:13 where's last time's topics? 20:58:16 flaper87: both are already on my list 20:58:21 so, have we all just given up on dropping the CLA? 20:58:21 jaypipes: nice one 20:58:22 ttx: awesome 20:58:30 sdague: ++ 20:58:40 sdague: ++ 20:58:41 #info TC+BoD topic: "What is the board actually doing to enforce the contribution requirement of Platinum members?" 20:58:45 we should probably ask the Board what they need from our comm plan 20:58:47 jaypipes: I'm glad someone brought it up, I think that would be a good conversation 20:58:53 sdague: ++ 20:58:56 #info TC+BoD topic "have we all just given up on dropping the CLA?" 20:59:26 i was just about to ask 20:59:31 to make that a bit clearer, i assume that we have not. i assume that the board has been working in good faith on that. 20:59:33 And now we have 2 minutes to r aise points that should definitely appear in the TC comm 20:59:44 jeblair: ++ 20:59:53 jeblair: ok, the last email thread on legal-discuss did not seem to indicate that 20:59:56 is there a meet-the-TC thing in vancouver? 21:00:01 we should advertise that in TC comms IMO 21:00:02 lifeless: no 21:00:13 thank goodness :) 21:00:14 people are bored with us 21:00:17 lunch with the TC/board was useless 21:00:20 lifeless: we opted out the "Lunch with Board" thing 21:00:29 not the lunch, I remember a session in hong kong 21:00:36 yeah - no session such as that 21:00:37 just mics at front of a room 21:00:41 anyhoo, no is fine. 21:01:00 sdague: yeah, realize i may be disappointed. but my own inaction is not because i have given up, but rather am assuming good faith. 21:01:06 My idea for this week's post would be to summarize the comm plan, point people to tag discussions, indicate the governance change that happened last week about agenda item timing... 21:01:09 OK, last minute things-that-need-to-appear-in-anne's-post ? 21:01:27 annegentle: you can mention the project guide in prep 21:01:31 ttx: yes 21:01:32 annegentle: ++ 21:01:51 ok, time to wrap up 21:02:03 I'll be seeing you all in a few days 21:02:13 see you all sunday! 21:02:16 #endmeeting