20:01:08 #startmeeting tc 20:01:09 Meeting started Tue Jun 30 20:01:08 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:13 The meeting name has been set to 'tc' 20:01:17 Our agenda today: 20:01:17 jaypipes looks like he is swimming 20:01:24 or drowning 20:01:27 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:34 o/ 20:01:37 * zehicle lurking too 20:01:37 o/ 20:01:46 #topic Cross-project specs final approval 20:02:01 We have a number of specs which I think have reached consensus stage and need our final approval to get through 20:02:09 * Enabling Python 3 for Application Integration Tests 20:02:13 #link https://review.openstack.org/#/c/177375/ 20:02:36 This one was discussed at the cross-project meeting on June 9. 20:02:42 No objection recorded, I think it's more than time to final-approve it 20:02:56 no objections here 20:03:01 any objection, last-minute comment? 20:03:06 nope, lgtm. 20:03:28 glad it's finally getting approved 20:03:37 alright, it's in the pipe 20:03:45 * Add requirements management specification 20:03:50 #link https://review.openstack.org/#/c/186635/ 20:04:01 This one was discussed at the cross-project meeting twice, on June 9 and June 23 20:04:11 It's already being worked on as far as I know, no objection on the spec itself 20:04:26 no objections here 20:04:27 Looks ready to me. Objections ? 20:04:39 * flaper87 reads ttx's mind 20:05:12 I'll take silence as consent 20:05:14 and approve 20:05:24 done 20:05:33 * Update to CORS specification 20:05:37 #link https://review.openstack.org/#/c/189924/ 20:05:41 +1 20:05:48 This one is just small changes requested on the original CORS spec, that were pushed as a subsequent change rather than a new patchset 20:05:54 ttx: o/ 20:05:57 sorry I'm late 20:05:58 I think we can fast-track it 20:06:03 EFAMILY 20:06:10 ttx: sounds good 20:06:39 already has TC majority anyway 20:06:47 objections? 20:07:18 no objections, approved! 20:07:27 #topic Add release:managed to libraries and previously-incubated projects 20:07:43 Those are mostly technical adjustments to reflect what the release team directly manages those days, thanks to a lot of fresh blood 20:07:47 #link https://review.openstack.org/191893 20:07:51 #link https://review.openstack.org/192193 20:08:06 That kind of horizontal changes to the file generates a lot of merge conflicts, so I'd like to get them in ASAP before they generate more of those 20:08:26 ++ 20:08:39 they have the votes 20:08:45 APPROVE ALL THE THINGS 20:08:53 flaper87: +1 20:08:54 first one is short of one 20:09:04 jgriffith: could you apply rollcall+1 ? 20:09:05 bahh 20:09:15 ttx: done 20:09:31 ttx: I did too 20:10:10 I guess an additional question would be, are you fine with adjustments to release:* tags being merged as long as two release team members agree with the change ? 20:10:20 because those will be back 20:10:26 yes that's fine with me 20:10:31 * flaper87 is good with that 20:10:41 ++ 20:10:46 make sense 20:10:49 seems fine to me 20:10:49 happy to do a quick vote to keep it logged 20:10:52 it's all changeable if something comes up worth discussing 20:11:21 as in, meetbot vote, logged, stamped, we told you so 20:11:35 anyway, I'm good with that 20:11:35 yeah, and can revert / fix if weird 20:12:10 I don't think its a tc thing 20:12:10 I'm working on a revision of the tags, and wil include that tag application rule in it for reference 20:12:23 we shouldn't need to spend time thinking about stuff owned by other people 20:12:24 sounds good 20:12:37 #agreed future release:* tag changes can be fasttracked as long as the release team approves them 20:12:48 Thanks 20:13:01 #topic Be specific about geography in release names 20:13:10 #link https://review.openstack.org/191974 20:13:14 That one looks pretty straightforward 20:13:21 any objection to it merging here and now ? 20:13:29 merge it 20:13:29 we are on a ROLL today 20:13:31 nope 20:13:40 merge away 20:13:52 #topic RPM distribution packaging of OpenStack 20:14:00 #link https://review.openstack.org/191587 20:14:08 So.... This one was proposed as a split from the original "all packaging" team 20:14:17 That said, that team doesn't seem to be really formed yet, and I haven't seen any recent discussion about it 20:14:26 Which probably explains the absence of comment, the merge conflict status, and the ptl:TBD line 20:14:45 My take is that while we don't require teams to be mature, they should still exist in reality, have a clear scope and leadership, have some meeting point... 20:14:56 So I'd keep this one as WIP, same as the Debian packaging one 20:15:04 i think this is in the same situation as the deb version -- if the author comes forward and updates the proposal, i would +1 it 20:15:37 ttx: +1 20:15:50 would be good to have those coordinated IMO, maybe even in the same proposal somehow? 20:15:51 agreed ttx 20:16:03 jgriffith: I think thats asking too much :) 20:16:04 jgriffith: well they WERE in the same proposal 20:16:06 I went through that spec and I agree with russellb and ttx comments 20:16:13 then realized they could probably not work that well together 20:16:29 and would have been really two teams 20:16:53 ttx: well, I was thinking more in terms of the spec 20:16:59 i'm happy with this in concept, i just want some very basic level of a baked proposal 20:17:04 ttx: still two projects, but one consistent spec but that's ok 20:17:07 i feel like this is nothing but a incredibly high level idea 20:17:08 OK, I'll move it to backlog until it gets updated / refreshed / progress is made / meetings happened / PTL is chosen / scope is defined 20:17:19 +1 20:17:20 ttx: ++ 20:17:28 #topic Add Stackforge Retirement resolution 20:17:34 Alright! Enough consensus 20:17:39 #link https://review.openstack.org/192016 20:17:45 There are a few objections to this one. 20:17:48 consensus this one too! :) 20:17:54 jeblair: lol 20:17:56 My reading is that everyone agrees that we should encourage things that ultimately want to be an openstack project to directly file for the openstack namespace (category (a)) 20:18:05 i think the objections are perhaps lack of clarity that could be addressed in a subsequent resolution 20:18:07 And I think that's the main goal of this proposal: encourage "incubating" projects to directly file for big-tent inclusion 20:18:09 er revision 20:18:15 I call that the "stackforge is not an incubator" effort 20:18:23 jeblair: agreed, for instance my last comment 20:18:28 ttx: indeed. the main goal is not to reduce service, but instead to stop moving projects from org to org 20:18:29 Not everyone agrees that we should discontinue support for the other categories -- especially for projects that don't ever want to become an openstack project but still want to benefit from our infrastructure 20:18:47 For those (categories (b) and (c)), I think it was nice of us to provide resources to educate and encourage random open source projects to use nice tooling 20:18:58 but if it's too costly to support those projects, I support the Infra team decision of dropping them 20:19:04 i think it's totally fair for infra to not stay in the business of free infrastructure for things that don't want to be an openstack project 20:19:05 we do have some projects on stackforge that I wouldn't expect to want to become official, like pecan and WSME. I spoke to the pecan lead today and he's ok with moving back to github, but we would lose some of the gating they are doing for us. I would expect the WSME maintainers to move to github, too. 20:19:11 i'm pleasantly surprised by that; i'd like more feedback there 20:19:19 jeblair: is the bigger concern the org-to-org moves or the upkeep of stackforge 20:19:20 russellb: ++ 20:19:28 agentle: mostly the org-org moves 20:19:41 jeblair: Ultimately those could be two separate decisions. We could decide to communicate about "stackforge not being an incubator" 20:19:45 actual drain for supporting projects staying in stackforge is small 20:19:50 And separately we can decide to stop supporting other categories in stackforge (or to stop accepting new projects there) 20:19:55 ttx: i agree, that's an option 20:20:32 dhellmann: tbh, I think that's fine. We should find a way to help them gating for us or just deal with the lack ofit 20:20:38 I like the idea of having stackforge around for things (like Pecan et al) that we benefit from having similar ci 20:20:42 flaper87: right 20:20:45 i have a personal dream of just not having git namespaces at all so this silliness wouldn't be an issue, but that's not been feasible for technical reasons so far, so we're stuck with a cosmetic prefix on repository names to which people ascribe too much meaning 20:20:57 maybe at that point there be some higher criteria for adding new projects to it 20:21:06 i think we would need to characterize when we think it's reasonable for a project that deos not want to join openstack to use the service 20:21:07 fungi: we could rename stackforge to notnotopenstack 20:21:08 fungi: should we rename the world. To z/nova, z/cinder, 20:21:16 fungi: and f/pecan, etc. ? 20:21:31 not so keep on renaming 700 repos either, so... meh :/ 20:21:36 s/keep/keen/ 20:21:59 in the case of pecan, we're limiting their ability to test under versions of python that they care about but we don't, so the authors are ok with moving if that's the consensus 20:22:22 there are other CI systems out there that folks are pretty happy with, after all 20:22:23 fungi: i'm much more interested in performing the big-tent moves from stackforge -> openstack if we know there's a light at the end of the tunnel :) 20:22:37 dhellmann: I wonder if these are the only 2 cases but I doubt it 20:22:52 flaper87: no, just the 2 I'm familiar enough with 20:22:55 dhellmann, flaper87: we even have a couple in infra 20:22:57 it'd be cool to send an email out mentioning this and see who screams 20:23:00 so a conservative though would be to limit this to just not-an-incubator 20:23:05 jeblair: aha 20:23:08 and wait a year 20:23:24 jeblair: any reply to my last comment w.r.t requirements and possible instability? 20:23:27 am I just being paranoid ? 20:23:34 jeblair: I think it's fair to reject things-that-clearly-want-to-be-openstack when they apply to stackforge and tell them to apply for big tent instead 20:23:34 flaper87: good question! quick answer: you're being too paranoid! :) 20:23:38 lifeless++ 20:23:45 ttx: ++ 20:23:58 jeblair: I can live with that as long as there are people like you that will bring me back to earth 20:24:00 :D 20:24:01 jeblair: but that means an application process 20:24:01 flaper87: i think we can keep those concerns separate -- what projects use global reqs is a separate question from git namespace, etc. 20:24:10 flaper87: once constraints are live 20:24:11 jeblair: which you would have to handle 20:24:16 jeblair: fair enough 20:24:16 flaper87: the risk there goes WAY down 20:24:22 flaper87: and we're only waiting on pip 7.1 now 20:24:28 lifeless: ++ 20:24:30 lifeless: roger, that's good to here :) 20:24:31 flaper87: then there are two patches to merge, and we're live. 20:24:47 for reference, not including -attic repos we have 368 in openstack.* and 313 in stackforge at present 20:24:51 ttx: yeah, so i think i have what i need to sythesize a new rev 20:25:01 [there'll be rough edges for a while of course, and we need to expand the inverse test matrix, but the core will locked down straight up] 20:25:04 this has been really helpful 20:25:35 o/ 20:27:01 jeblair: ok, that discussion will be back 20:27:15 yep, look for a new rev by next week 20:28:12 #topic Be less proscriptive about new team size/maturity 20:28:20 #link https://review.openstack.org/193550 20:28:29 Looks like this one already has all the votes it will ever need 20:28:38 Objection to me merging it now ? 20:28:44 nope 20:28:49 yes! 20:28:52 ... no. 20:28:59 just wanted to argue about something. 20:29:08 LOL 20:29:12 I have the right topic for you to do that 20:29:16 oh cool 20:29:17 #topic Fix typo to 'Bare metal service' 20:29:21 lolol 20:29:21 hahahaha 20:29:22 #link https://review.openstack.org/194230 20:29:32 This one sounds like it should have been fast-tracked as a typo fix, but it triggered a lively discussion 20:29:51 this one set a new record for amount of discussion to (apparent) triviality of the patch 20:29:53 ttx: I have a legal question in to the Foundation now 20:29:54 agentle: around? 20:29:56 yes 20:29:59 I'm inclined to trust annegentle and the docs team on this one 20:30:01 I'm happy to defer to Anne and/or the docs team on that one 20:30:03 dhellmann: +1 20:30:11 ttx: +1 20:30:15 it's non-trivial for all the existing docs 20:30:19 If it's a typo, it's a typo and we can merge it. If it's not a typo, they know 20:30:21 wow 20:30:26 agentle: yeah, makes sense 20:30:27 it's not a typo 20:30:29 :) 20:30:39 in any case there is no point in us voting or discussing it ? 20:30:40 there's some inconsistency in the file then 20:30:53 russellb: yeah my hope is to clear that up with set guidelines 20:30:59 ttx: not yet 20:31:00 yeah, appreciate that, you cleared it up in comments 20:31:30 one point of discussion - generally speaking I do want the TC to be in the business of naming reviews, is that okay generally? Reasons not to? 20:31:45 thinking of it for the service catalog service type discussion and microversions for example 20:32:10 agentle: if we reuse the name in that file for service catalog, I think you're right 20:32:32 agentle: ++ 20:32:37 service catalog sounds like cross project spec kind of thing 20:32:44 I think it was either russellb or sdague who pointed out we'll have more than one service once competing solutions enter 20:32:48 russellb: it is 20:33:04 agentle: are you proposing that we register service catalog names in the governance repo? 20:33:07 russellb: and in that spec I want to assert that "TC names" with the idea that projects.yaml is the naming source of truth 20:33:12 * dhellmann hasn't been following that discussion 20:33:25 dhellmann: proposing that projects.yaml is the naming source of truth 20:33:34 yeah, want to hear from you all on that ^^ 20:33:40 +1 20:33:52 +1 20:34:02 +1 20:34:07 The caveat is the legal implications of course, but I'm seeking clarity. 20:34:11 +1 20:34:12 although I think we probably want another field other than this descriptive name for the service catalog names 20:34:16 queue indigo girls 20:34:25 dhellmann: HEH 20:34:34 dhellmann: I tend to agree that every time we've used the same field for two things, we regretted it 20:34:45 agentle: i don’t think i saw your legal question yet. what’s the high level? 20:35:08 jbryce: sure, it's this: does capitalization of the second (or third) word in the service name have any legal implication? 20:35:13 and I'm yet to be convinced that new projects shouldn't just be using their name, but I'll hold off on a final opinion until there's a formal spec put together for that 20:35:25 jbryce: we have Block Storage and Object Storage but also Bare metal and Application catalog 20:35:34 jbryce: i.e., "Bare metal" vs. "Bare Metal" 20:35:38 agentle: just found the ticket. i’m pretty confident the answer is no as long as you don’t pre-pend OpenStack 20:35:40 heh 20:35:47 Previously we've avoided "cognitive burden" of knowing whether to capitalize say the V in Key-Value by saying only the first letter should be capitalized. 20:36:24 * dhellmann imagines a world of project names in ALL CAPS for the same reason 20:36:25 jbryce: so then I'll just have to decide whether Storage set us up for a lifetime of capitalization rules :) 20:36:45 I still don't know whether it's Key-value Store or Key-Value Store even with capitalization rules 20:36:54 dhellmann: but then people think it's an acronym. Like OSLO 20:37:01 * ttx trolls 20:37:05 SNORT 20:37:09 lol 20:37:14 agentle: which project is that? 20:37:20 * zaneb is thoroughly sick of people shouting HEAT at him 20:37:23 dhellmann: MagnetoDB 20:37:24 LOL 20:37:28 https://github.com/openstack/governance/blob/master/reference/projects.yaml#L1129 20:37:38 HEAT OSLO NOVA SWIFT LOL 20:37:47 zaneb: I never knew what it stood for. 20:37:59 ... 20:38:04 ttx: don't you start 20:38:05 agentle: you mean lOl I think 20:38:19 Sadly, my technical editor at work wants Application Catalog and Bare Metal :) 20:38:38 agentle: anything else on that one ? Sounds like you have it under control 20:38:40 can we "fix" them all in one patch? 20:38:45 dhellmann: yeah 20:38:50 dhellmann: then go to the docs, sigh :) 20:38:53 ttx: I think so 20:38:59 thanks for bringing it up :) 20:39:15 OK, the next topic on the agenda was the Akanda proposal, but it was very recently WIPped 20:39:23 while they address the trademark / use company name as project name question 20:39:23 yup 20:39:32 So I propose we skip it and reconsider it when it's final and un-WIPped 20:39:39 good for me 20:39:43 101 clearly. 20:39:48 agentle: let's talk offline about ways to make substitutions like that simpler in rst 20:39:50 Then we don't need to worry about capitalisation 20:39:58 Let me see if we can get another patch to replace it on the agenda 20:40:08 I just hope that we do not turn into the little v vs. the big V debate (from the vSphere world) 20:40:17 adding neutron to compute starter kit? 20:40:18 * maishsk ducks and runs for cover… ;) 20:40:21 https://review.openstack.org/#/c/195771/ sounds like a good candidate 20:40:34 ah yes, that one first 20:40:41 Topic lastday 20:40:42 :( 20:40:44 since it was proposed in time -- any objection to discussing it now ? 20:40:59 if we don't approve it, does jogo have to stay around? 20:41:15 props for doing real work until the end :) 20:41:24 changing the world until the last day 20:41:31 okay, actually, i think that it was intentional 20:41:42 I'll take that as a yes 20:41:43 #topic Fix up the compute starter kit tag 20:41:52 #link https://review.openstack.org/#/c/195771/ 20:42:08 i thought that the intent was to have real discussion on the application? 20:42:08 So this patch basically applies the tag to the initial set of projects 20:42:11 yeah, i think we knew it hadn't been applied yet, because there was potential follow-up discussion yet, especially neutron 20:42:18 but i think the initial set of projects here has consensus in any case 20:42:20 so +1 from me 20:42:27 It is also use as a base for mordred's patch proposing neutron addition 20:42:33 yup 20:42:34 and the tag name seems fine 20:42:37 at least, i think that some questions were deferred with "that can be dealt with in tag application" 20:42:39 yeah, I'm good with that too 20:42:40 which should make for an interesting discussion, but next week 20:42:49 jeblair: right 20:42:55 for some definition of interesting 20:43:10 jeblair: we said that the tag definition still needed to be applied 20:43:46 and that we could rediscuss where it applies at that point. But I like the idea to iterate from the initial set proposed in the definition 20:43:56 k, just mostly wanted to make the point that i don't think this was an oversight, and that we are expected to apply discretion to this :) 20:44:02 I thought we had explicitly endorsed a tag starting with compute: during the previous discussion 20:44:17 if anyone would like to talk some more about current neutron state, i'm happy to chat out-of-meeting, if that'd help develop opinions on this neutron thing, i've been trying to follow much more closely lately 20:44:50 zaneb: I don't remember that... the prefix is a category thing, so compute: wouldn't make that much sense there ? 20:45:13 yeah, starter-kit makes sense as the category 20:45:15 maybe it should just be compute-starter-kit? 20:45:16 We have majority at this point 20:45:29 or i guess it could be even more general, "group:compute-starter-kit" 20:45:30 but meh 20:45:46 this wfm 20:45:53 zaneb: that is an option, but that can be proposed/discussed as a separate patch 20:46:18 Alright, I'll approve this in 30sec, get tyour last votes in 20:47:09 ok done 20:47:16 #topic Workgroup reports 20:47:22 * Project Team guide workgroup 20:47:30 No progress since last week. Was focused on liberty-1, should make more progress this week 20:47:37 Any suggestion on where we should publish it ? 20:47:46 I have a WIP patch that I'd be happy to start getting feedback on 20:47:49 (if no one has) 20:47:54 russellb: I'd like to do that. 20:47:55 and I'm sorry for being late there 20:47:58 russellb: (chat) 20:48:25 jeblair: IIRC you had an idea on where we should publish it 20:48:27 docs.openstack.org/project-team-guide? (that's original) 20:49:01 ttx: i can't remember :) i like agentle's idea 20:49:18 The infra guide is at docs.openstack.org/infra rather than docs.openstack.org/infra-guide 20:49:30 ttx: they should rename it :) 20:49:31 blue pain t on my bikesheds 20:49:33 I kid! 20:49:38 red 20:49:46 yeah, we grabbed a subdir to hold all kinds of infra stuff 20:50:04 and by grabbed, i believe i mean, politely asked agentle for permission :) 20:50:12 jeblair: heh 20:50:17 jeblair: do you plan to work on the publication jobs ? 20:50:41 ttx: can do; let's just #info the location when we finish bikeshedding 20:50:46 I'll do a complete review of the current chapters to check we have enough to start talking about it 20:51:34 Any objection to docs.openstack.org/project-team-guide ? 20:51:49 none from me 20:51:57 wfm 20:51:57 ttx: as long as you promise never to rename to program-team-guide 20:52:00 pinky swear? 20:52:05 #agreed Project team guide to be published to docs.openstack.org/project-team-guide 20:52:10 promise! 20:52:15 * Communications workgroup 20:52:24 agentle, flaper87: your turn 20:52:29 any movement on M name? 20:52:38 and really that doesn't come from "us" per se 20:52:46 do we need a blog post this week? 20:52:47 I got feedback from lsell 20:53:02 agentle: lots of things approved, but not exactly exciting stuff 20:53:02 oh and I keep forgetting to tweet 20:53:15 they are still working on it 20:53:20 mordred: okay 20:53:31 I think we could wait another week for compiled excitement 20:53:36 not sure if it's worth working on one this week 20:53:38 agentle: summary is the top 2 choices were quickly tm-ed out of contention. 3rd looks promising, waiting for detailed search 20:53:46 jbryce: ok thanks for that 20:53:51 agentle: ++ 20:53:59 flaper87: mind meld 20:54:00 agentle: surely we can't 'go' that long without compilation ? :) 20:54:15 * Other workgroups 20:54:23 lifeless: lol 20:54:31 Any progress in other workgroups ? 20:54:38 architecture still hasn't gotten off the group 20:54:40 ground 20:55:05 thats on me and markmcclain to make a timeslice and get things really rolling. I've been focusing on getting the constraints cross-project omgosh stuff off my plate 20:55:06 Once the peak of excitement is reached on project-team-guide is reached and I enter the valley of desillusion, I might help out there 20:55:12 heh 20:55:25 #topic Open discussion 20:55:28 agentle: which docs rae you referring to on https://review.openstack.org/#/c/196438/ ? 20:55:34 There was a post asking for volunteers for Travel support program 20:55:38 #link http://lists.openstack.org/pipermail/openstack-tc/2015-June/000998.html 20:55:42 Anyone interested ? 20:56:02 russellb: I haven't seen a coherent "this is how you do port assignment in neutron to make it like nova-net" nor a "how to migrate upgrade" 20:56:02 ttx: i replied off list that i'm willing to do it 20:56:04 I replied off list 20:56:23 all you have to do is agree to house a few summit attendees in your room! = ) 20:56:23 agentle: migration/upgrade isn't relevant for a starting point tohugh 20:56:26 russellb: but it's possible it's there and I've missed it so need links 20:56:39 jbryce: as long as they aren't in my carry-on 20:56:41 agentle: and the first part, i'm not sure i get, that's probably the most fundamental part of the neutron API 20:56:42 russellb: mm 20:56:54 creating a port on a network? 20:57:03 jbryce: I learned that in Japan you pay hotel rooms by occupancy and not per room, which if true menas you wouldn't win a lot 20:57:17 there has been discussion about provider networks, but that seems covered pretty nicely on http://docs.openstack.org/networking-guide/ scenarios 4a and 4b 20:57:37 4a and 4b are great 20:58:06 i'd encourage anyone who hasn't seen that guide to check it out 20:58:15 agentle: also, fwiw, shade makes nova-net look like neutron where possible 20:58:16 On the travel support program I'll reach out to Shari and check she has enough, and if not do another round of volunteer fishing 20:58:31 agentle: in the instances where we're forced to interact with nova-net 20:58:57 shade? 20:59:01 agentle: might or might not be a useful collection of data for someone in terms of what dicts look like 20:59:13 russellb: yeah networking guide is great so where does it say "if you just want a network do this for your users" 20:59:14 clouds make shade, shade makes cloud 20:59:24 russellb: library that wraps python-*client with business logic to hide all the cloud differences 20:59:29 mordred: nice 20:59:34 russellb: being used in upstream ansible openstack modules as well as nodepool 20:59:39 agentle: depends on the networking model you want to use 20:59:40 I remember a note in the etherpad, mordred you may have pointed it out, that people didn't know "oh don't worry about running out of IP addresses, you just do this thing" 20:59:43 One minute warning. Anything else, anyone ? 20:59:52 the nova-network equivalent is documented nicely in the provider networks part 20:59:54