20:02:20 #startmeeting tc 20:02:20 i'm sure he does. 20:02:21 Meeting started Tue Jul 29 20:02:20 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:24 mikal: look out the window 20:02:25 The meeting name has been set to 'tc' 20:02:29 I added a topic in th agenda 2 days ago :) 20:02:36 (Long) agenda for today is: 20:02:40 was waiting to discuss fit-upstream stuff 20:03:02 dguerri: a new meeting has started, please go to #openstack-infra 20:03:06 *git-upstream 20:03:08 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:03:09 ok 20:03:15 #topic Check progress on gap coverage plans (post-j2 edition) 20:03:24 o/ 20:03:24 As promised after each milestone we review progress on gap coverage plans 20:03:43 promised eglynn we would do him first 20:03:45 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage 20:03:50 ttx: thanks :) 20:03:56 well, we've had some some slippage from our target for completion of juno-2 20:04:11 eglynn: but everything is under review? 20:04:11 detailed in the strike-thru' on that wiki page 20:04:17 oh, not #5 20:04:30 how do you feel about completing these by j3? 20:04:37 eglynn: could you elaborate on the javelin thing? 20:04:42 looks like good progress 20:04:42 russellb: confident 20:04:52 QA declining? Something we could help to solve? 20:04:59 ttx: grenade/javelin not yet being as solid as we thought 20:05:12 (so it's kinda closed to new features right now) 20:05:29 eglynn: still thinking it can make j3, or is it going to be more of a kilo thing ? 20:05:29 eglynn: javelin2 is working now, just needs a few patches to land 20:05:41 yeh, it's taken up sometime to get the new javelin code working, so that's an upstream delay. 20:05:46 ttx: definitely juno-3 20:06:07 ok, this is taking more time than expected, but still looks doable in juno timeframe 20:06:09 jogo: cool, so we'd be looking at the cdent's patch being landable within weeks? 20:06:15 ttx: agreed 20:06:16 comments on Ceilometer? 20:06:46 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage 20:06:49 mestery: o/ 20:06:56 ttx: o/ 20:07:00 eglynn: without looking to closely I *think* so 20:07:05 can we hit status on each gap on this one? 20:07:09 russellb: Ack 20:07:10 jogo: great, thanks 20:07:19 Gap0 is closed. 20:07:28 We finished the DB migration work during Juno-2. 20:07:56 Gap1 will close at Juno-3, but we are at 100% API coverage, and the full job is now enabled as well (see mail threads) 20:08:06 running all tests now? 20:08:11 and how about stability? 20:08:19 russellb: I believe that's the case yes, failure rate last I heard was < 5% 20:08:27 russellb: I can dig out salv-orlando's email in a bit 20:08:50 Gap2 is underway now, on target to close at Juno-3 20:09:08 Gap3 has a patch proposed, I think we can look to merge that one soon 20:09:14 Gap4 is complete 20:09:27 Gap5 is making good progress, and will be complete at Juno-3 20:09:39 so last i looked, the code looked pretty far off 20:09:43 what was the decision on the OVS question? 20:09:45 feel confident it will be completed? 20:09:46 mestery: gap 5 mentions ovs 20:09:47 and yes, that question 20:09:48 russellb: DVR? 20:09:53 yes DVR 20:09:54 Yes, it's for OVS. 20:10:03 The DVR code is in much better shape now. 20:10:08 We've had lots of core reviews on it, testing, etc. 20:10:16 what's the nova/neutron position on the ovs requirement? 20:10:30 haven't seen a thread on that, but we should have one. 20:10:36 ++ 20:10:40 russellb: Want me to start it? 20:10:43 yes please 20:10:47 Will do 20:10:56 well the OVS requirement may not be a must 20:11:06 what a sentence 20:11:11 mordred: Heh :) 20:11:35 it would still be good to know the relative opinion on requiring that 20:11:38 haha… so linuxbridge will likely work just not a test path 20:11:56 s/test/tested/ 20:12:12 * mordred has no personal issues with OVS as a thing - but /me is not a nova core 20:12:15 Lets discuss in detail in the ML thread on that. 20:12:15 what does "not a test path" oh... you mean you can't test linuxbridge? Er. 20:12:22 so, aside from lack of testing, no obvious technical reason it wouldn't work with linuxbridge? 20:12:28 yeah I'd like to understand it too 20:12:30 ok, yes, to the ML on that 20:12:35 * devananda sneaks in late, lurks in the back 20:12:35 annegentle: just asked markmcclain the same thing :) 20:12:42 So, Gap6 is the one which is behind a bit. 20:12:42 it's all part of the "can we deprecate nova-network" issue ... 20:12:49 * mordred throws gluten at devananda in punishment 20:12:53 annegentle: he said it does not currently have a test plan in DVR patches 20:13:00 jaypipes: ah ok 20:13:01 markmcclain and marun are discussing with nova cores this week is my understanding 20:13:07 cool 20:13:09 yes, my impression of the migration plan thus far is not very good 20:13:11 and DVR is just the team name or a TLA? 20:13:13 the dvr bits are super new as well 20:13:16 but yes, i'm interested what progress is made this week 20:13:22 annegentle: "distributed virtual router" 20:13:31 russellb: upgrade path is on the agenda for later today 20:13:32 the migration plan has been kicked around in various directions 20:13:33 sdague: yes ... hard to call nova-network officially deprecated on merge day 20:13:35 russellb: We know we missed the nova spec deadline, and we're working to alleviate that. 20:13:36 mikal: cool 20:13:38 markmcclain: ++ 20:13:44 mikal: Thanks! 20:13:44 what not digital video recorder?! 20:13:47 annegentle: it's the multi-host functionality in neutron -- distributed virtual router. someone correct me if I'm wrong. 20:13:50 annegentle: Ha! 20:13:52 the various ways we've been pointed haven't ended up in a good place 20:13:53 i personally feel it's too late for juno to rush something like that 20:13:56 jaypipes: You're right :) 20:14:27 russellb: The migration path? 20:14:28 don't even have a plan, much less an implementation with some proven testing showing stability behind it 20:14:29 yes 20:14:29 okay and DVR is the "only" way to get multihost? or the one we've been going after for a while? 20:14:37 russellb: I don't know that we're actually rushing items 20:15:11 we have the opportunity to get a working path and then refine within the deprecation window 20:15:15 annegentle: That's the plan of record, yes. 20:15:24 markmcclain: ++ 20:15:26 markmcclain: well, i guess depending on what the plan looks like, looking for approval of plan and then implementation all for juno seems rushed this late, but i'd love to be proven wrong 20:15:28 o/ i just got off a plane and my connection is spotty 20:15:37 We've explored a few options around migration, and had some successes and some issues. 20:15:51 welcome vishy-from-a-plane 20:16:18 For closure here, Gap7 is ongoing and will close at the end of Juno 20:16:27 So, Gap6 is the main concern here (migration). 20:16:29 mestery: ok thanks 20:16:32 so gap 7 says document, but IMO, gap 7 is bigger than that 20:16:38 annegentle: you're welcome :) 20:16:40 it also mentions scale testing, which is the bigger problem 20:16:51 having an open source problem that scales well (and we can show that it does) 20:16:56 s/problem/option/ 20:16:57 ha 20:17:16 problem/opportunity 20:17:18 * jaypipes feels Gap7 should be more descriptive/explicit... 20:17:20 :) 20:17:27 jaypipes: agree with that 20:17:27 russellb: Agreed, the main issue has been finding resources for such scale testing 20:17:37 russellb: We've been reaching out to companies around this, it's a WIP to be honest. 20:17:39 on the docs, I'd like more description so we can get more to help out 20:17:40 mestery: so any progress beyond just the docs part? 20:17:42 for instance, what is "document open source scalability testing" really mean? 20:17:43 OK 20:17:55 mestery: is dvr going to be running on the default neutron jobs? 20:17:57 russellb: Nothing huge to report, it's taking time to find companies with resources. 20:18:05 so, my view of this gap was less about docs about more about having an open source option that we feel scales well 20:18:08 sdague: The sooner we can get that in, we can make that happen. 20:18:18 I know of a few efforts - at the ops meetup in August, 3-4 of us getting together, and before that, a "swarm" in Australia for a networking guide, any of those matching up? 20:18:26 russellb: maybe we need to have a specific topic on neutron/nova-network at the cross-project meeting? 20:18:34 russellb: I think there was slight disconnect there :) 20:18:46 ttx: sure ... though i think we're wrapping up the status at least 20:18:48 russellb: But I do agree with your assessment around scale 20:18:53 ok 20:19:02 and if the focus should be "just document open source happy path" that's good for scope/focus/rallying troups who write 20:19:22 I don't want to get into too much detail in the TC meeting, except recording the plan is now a bit more unlikely and needs to be further addressed 20:19:32 ttx: yep, sounds good 20:19:33 mestery: any other docs efforts? 20:19:42 russellb: so.. concerns about Gap6 and Gap7? 20:19:44 or more 20:19:49 annegentle: emagana has an etherpad with what we need to do, it was shared in monday;s neutron meeting 20:20:04 and maybe Gap5? 20:20:09 mestery: ok, I've edited that, so sounds like we know what we know 20:20:09 ttx: primary concerns are with 5, 6, and 7 20:20:09 so... hold up one sec 20:20:15 annegentle: ack 20:20:20 * russellb holds up 20:20:26 sitting next to markmcclain and he is frustrated with lack of clarity and specifics around Gap6 and Gap7 20:20:39 and frankly, after looking at the wiki, I share his concerns... 20:20:50 * markmcclain was hoping to clear them up with nova team this week 20:20:51 i think there was much more detailed discussion than ended up captured on this page ... 20:20:53 mestery: what is the status from Oleg on Gap6? any specific status from him? 20:21:05 #info TC voices concerns about Gap 5, Gap 6 and Gap 7 -- further precisions needed 20:21:05 jaypipes: The status is his BP didn't make the nova cut :( 20:21:26 jaypipes: He's done some great exploratory work, but the final approach wasn't signed off by nova in time was my understanding 20:21:28 mestery: could we put a link in that wiki to the relevant specs or etherpads pls? 20:21:31 shall we take an action for a subet of folks to work on further clarity around expectations here? 20:21:33 jaypipes: ++ 20:21:42 russellb: Yes, please 20:21:43 i'm happy to assist. 20:21:43 russellb: that's a good idea 20:21:47 mestery: just helps in getting the details about those gaps. 20:21:56 jaypipes: yes, agreed 20:22:05 let's expand on that during the cross-project meeting if that works for everyone 20:22:11 ttx: ++ 20:22:30 moving to next 20:22:39 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Trove_Gap_Coverage 20:22:43 #action mestery to work on clarified definitions of gaps 6 and 7 and bring back to TC for review, (russellb will help) 20:22:51 mestery: so, on Gap6, it currently says "This work is currently being scoped.". Should that be "This work is scoped now in blueprint ". 20:23:03 jaypipes: Yes, that makes more sense. 20:23:22 3 first gaps on Trove still open 20:23:23 So for trove we made really good progress on Gap 5 - it's now complete. 20:23:31 (Neutron support) 20:24:24 with gap 2 and gap 3 moved from j2 to j3 20:24:58 So for gap 2 we finished up the API docs. 20:25:05 SlickNik: how confident are you for completion of those two by j3? 20:25:28 And we went through an exercise identifying where we have holes in the docs. 20:25:47 Results of that are at: https://etherpad.openstack.org/p/trove-doc-items 20:26:03 I'm confident that we can address these in juno-3 (gap 2) 20:26:25 doc can be worked on post-j3 anyway 20:26:48 SlickNik: yeah you've made good progress there 20:26:48 more concerned about gap3 honestly 20:27:13 Getting gap 3 done by j3 has become _my_ top priority. 20:27:14 does tat need more infrfa lova ? anything we can do to help? 20:27:19 getting changes in upstream CI is less and less likely as we approach end of cycle 20:27:20 ow 20:27:25 based on history at least 20:27:31 I meant "does that need more infra love" 20:27:45 ttx: yes that would help 20:27:52 jeblair: ^ 20:28:00 the linked change came in right before the infra-core world tour, so i expect none of us has had a chance to review it 20:28:00 But they've been great so far :) 20:28:14 especially clarkb, fungi, and jeblair 20:28:33 * fungi has not been great 20:28:36 It's me who's had my plate somewhat full tackling the neutron gap. 20:28:39 fungi: you're always great :) 20:28:40 #info TC expresses concerns about Gap 3, keep us posted on progress 20:28:50 OK, other remarks on Trove? 20:28:51 ttx: Will do. 20:29:05 ttx: "infra tough love" 20:29:07 <3 infra 20:29:09 or lava 20:29:32 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Horizon_Gap_Coverage 20:29:35 too much going on 20:29:36 david-lyle: ohai 20:29:40 Thanks guys! 20:29:47 ttx: o/ 20:30:05 Gap 1 is up for review 20:30:18 yeah, it's us slacking there 20:30:25 will get it solved in 5 min 20:30:38 david-lyle: you mean Gap 0? 20:31:17 yes, sorry, Gap 1 has slipped but is still targeted for Juno, losing confidence that is going to make Juno, big openstack.requirements change blocking 20:31:38 #info Gap 1 unlikely to be closed within Juno timeframe 20:31:53 david-lyle: have a link to the requirements change? 20:31:56 I think that's relatively fine, though 20:32:13 more interested in getting Gap 4 covered tbh 20:32:24 sorry you all, I have to drop off now, but will catch up tonight 20:32:24 how is that (gap 4) going? 20:32:29 annegentle: o/ 20:32:31 dhellmann: https://review.openstack.org/#/c/97793/ 20:33:07 ttx: we are making progress, but I don't know that it will be integrated into the gate in Juno 20:33:10 #link https://review.openstack.org/#/c/97793/ 20:33:40 #info Gap 4 might miss the target too 20:33:50 in fact I imagine it won't as we get more functionality there 20:33:59 david-lyle: feeling confident on all the other ones, right? 20:34:06 yes 20:34:11 david-lyle: "The only code not already split is JavaScript and CSS that straddles both sides, this has been the main impediment for finishing the split. " refers to the xstatic packages? 20:34:24 Other comments on horizon? 20:34:44 david-lyle: and so that's the blocker for the toolkit/django repo split? 20:34:46 jeblair: the xstatic packages are pulling out those common components 20:35:02 yes, that's a blocker at this point 20:35:47 thank 20:35:48 s 20:35:55 there will be some repo work once that resolves, but that's the hardest part 20:36:13 I think that affects only Horizon though 20:36:21 so i'm relatively fine with it missing the mark 20:36:26 ok, glance 20:36:28 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Glance_Gap_Coverage 20:36:35 correct, but it will add an openstack requirement for the horizon_lib package 20:36:41 thanks 20:36:52 Looks like the only gap there missed the j2 mark 20:36:55 * markmcclain approves 97793 20:36:57 and may be a bit disruptive as we rework the gate structure for both repos 20:37:24 (but i'm very much looking forward to it!) 20:37:24 markwash: if you're arond, can you comment on having that gap covered in j3? 20:37:34 o/ 20:37:52 we had some effort around figuring out exactly where we need to change the image data bits in tempest 20:38:06 but then actually fixing it seems to have not had much progress 20:38:12 so I'm add the review right now 20:38:20 expect it to be in gerrit within the hour 20:38:27 s/add/adding 20:38:28 markwash: ok 20:38:33 Commenst on Glance? 20:39:01 #topic Blessing Heat gap coverage plan 20:39:08 Heat was under gap analysis at the last meeting 20:39:12 zaneb proposed the following plan: 20:39:17 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Heat_Gap_Coverage 20:39:34 The last item still needs a date/owner 20:39:45 I assume it's a j3 item and that it will have an owner 20:39:58 With that objection noted, I think it looks like a good plan 20:40:11 +1 20:40:28 #info Gap 3 needs an owner and a target milestone 20:40:38 #info Other wise plan looks good, make it happen 20:40:48 Remarks on that? 20:41:19 #topic Expand scope of the Identity program 20:41:24 dolphm: around? 20:41:28 o/ 20:41:29 So that's two separate parts: 20:41:34 * Expand scope of the Identity program to include auditing (https://review.openstack.org/109664) 20:41:45 This one is about keystone adopting PyCADF and expanding the program scope to cover it, which I think makes great sense, as long as Keystone and PyCADF maintainers are fine with it 20:41:54 * Rename the "Identity" program (https://review.openstack.org/108739) 20:42:02 So... This one raises an interesting question, which was also raised by Glance recently 20:42:08 we talked about it at the oslo meeting, and the oslo-core and pycadf-core teams agree to the move 20:42:13 Currently we are using the same term for the program name (i.e. the team name) and the "OpenStack name" of the main product 20:42:17 dhellmann: ++ 20:42:21 i.e. the Compute team produces Nova, also known as OpenStack Compute 20:42:29 but with programs taking on multiple projects, we reach the limits of this system 20:42:37 So I think we may need to divorce the team names from the OpenStack names. 20:42:44 ttx: makes sense. 20:42:48 We could add a line in there under "integrated-since:" that says "openstack-name: OpenStack Compute", and then be able to rename programs as we want 20:43:02 Which solves the issue with marketing wanting to have a say on the "OpenStack names" we pick or rename 20:43:09 russellb: yeah, I think nova will hit this in the next few releases too 20:43:41 what would the nova/compute team want to rename themselves to if their product is still 'openstack compute'? 20:44:08 jeblair: Nova is the counterexample, it would probably have the same term used in both places 20:44:09 i'm just trying to get a handle on the issue :) 20:44:15 But Glance or keystone... 20:44:31 jeblair: just look at https://review.openstack.org/108739 20:44:32 jeblair: we can discuss that later, but I think we might want to break the nova == compute relationship sometime in the future is all 20:44:41 jeblair: i.e. when we have a gantt project as well 20:44:46 i think this is a bit of an side from the reviews at hand ... 20:44:56 aside* 20:44:57 mikal: gotcha 20:44:57 russellb: agreeed 20:45:05 Keystone can't be named "OpenStack Authentication, Authorization, and Audit" 20:45:07 Its more that I am interested in where the precident goes 20:45:15 ttx: well I'm -1 on the rename, anyway :) 20:45:30 tripleA? 20:45:38 I think Identity is just fine. 20:45:46 russellb: but do you recognize it will become a problem as programs take on more projects? 20:45:46 ++ 20:45:46 it is concise, clear, and captures the primary mission. 20:45:51 russellb, i'm curious why you think identity is "fine" it really does not convey the program, what it encompasses, and where it is trending to go 20:46:02 openstack-triple-a 20:46:05 morganfainberg: it's your primary mission, for sure, right? 20:46:13 russellb, it isn't the *primary* focus anymore to be a source of identity, it is more of a source of authorization not authn 20:46:14 russellb: ++ 20:46:16 russellb: the issue with "identity" is that providing a source of "identity" is our last priority 20:46:17 the mission statement is for covering your full scope 20:46:21 not the name of the program 20:46:29 dolphm, ++ 20:46:31 morganfainberg: yeh, but I think changing that name is more confusing than leaving it 20:46:44 because there is inertia in understanding 20:46:46 sdague, that is a better arguement imo 20:46:51 dolphm: i think that's splitting hairs ... it provides identity to openstack via some way ... it's the identity API 20:46:51 we don't call the Compute program "The Compute, Containers, Bare-metal, Hypervisors, and Virtualization" program, either. 20:47:01 naming aside, perhaps I missed something. has the scope change been discussed, in terms of how it (does or does not) impact other programs? 20:47:09 jaypipes: that's a great idea. Not. 20:47:13 russellb: we abstract the identity problem away from openstack, for sure 20:47:17 russellb: so you're arguing the issue may exist, but we are not hitting it just yet, since the program should not be renamed 20:47:23 devananda: https://review.openstack.org/#/c/109664/1 20:47:25 ttx: pretty much, yes 20:47:34 russellb: ok, that's valid 20:47:35 jaypipes: s/and Virtualization/Virtualization and Kitchen Sink/ 20:47:47 let's cross that bridge when we get there 20:47:52 ttx: yes :) 20:47:57 A related question is whether we should just rename "programs" to "teams", because some people have been very confused by the "program" term, and think there is more to it than what it is (a team). 20:48:16 But then chaging name is about as confusing 20:48:28 jeblair: right. saw that. adding a library to this program doesn't clarify to me how the responsibility of "auditing" is centralized in this program or distributed across all programs 20:48:34 well, in the oslo program we have several teams, so I'm not sure that fits us 20:48:51 ttx: i'm neutral on that ... but agree that i've seen the confusion. 20:48:54 devananda: the scope change should not affect any other projects .. i was careful to choose "auditing" to include pycadf but not "accounting" which would overstep ceilometer and quota efforts :-/ 20:48:55 jeblair: eg, measurements (ceilometer) is a single program which other programs must integrate with. is Auditing following that model? 20:48:56 ttx: we only just picked "programs", let's stick with it for a while 20:49:04 ttx: question is, will time solve the confusion, or do we need to change 20:49:17 mikal: +1 20:49:33 hehe 20:49:34 dolphm: what is to be audited -- events within other projects/programs, right? 20:49:39 i'm inclined to stick with it for now (programs) 20:49:51 devananda: yes; we started with authentication & authorization events in keystone, for example 20:49:56 I think the discussion can continue on the review themselves 20:50:09 and be back on the agenda when we expressed ourselves there 20:50:40 i'll approve the first one in a few days unless somebody complain, it's just a project move and it's got noth PTLs approvals 20:50:43 both* 20:50:53 ttx: it's more than a project move though 20:50:53 The second one sounds more funny than expected 20:50:56 ttx: it also updates mission 20:51:00 dolphm: waitup one sec 20:51:02 ah. Good point 20:51:06 dolphm: the pycadf code is a bit... weird 20:51:08 I'll wait for 7 YEs on there then 20:51:13 so can we require that pyCADF gets a revamp? 20:51:14 dolphm: are you committing to making it less odd? 20:51:22 the code is somewhere between terrible and awful 20:51:30 terriful? 20:51:32 markmcclain: it is intertaining 20:51:32 tell us how you really feel :) 20:51:34 mikal: are you offering to propose a list of oddities to tackle? 20:51:36 ttx: ++ 20:51:37 haha 20:51:48 dolphm: not overly? 20:51:52 dolphm: have you read it? 20:51:58 dolphm: I do think it needs a spring clean though 20:52:02 it was designed by some guys who knew more about cadf than python. it's probably not optimal. do we need to trash it? 20:52:03 gap: make it suck less 20:52:04 ? 20:52:06 dolphm: do you disagree with me? 20:52:12 did we have any outstanding plans for a security audit of pycadf? is it targeted for vmt support? 20:52:13 markmcclain: not exhaustively 20:52:14 make it not be thinly translated java code 20:52:24 mikal: i call it opinionated :) 20:52:36 dolphm: like it wants to be java? 20:52:39 sdague: ew, that would be my definition of terriful. Translated from java code into Python 20:52:55 AuditFactoryFactory? 20:53:10 clearly that's a factory which builds audit factories 20:53:43 #link http://git.openstack.org/cgit/openstack/pycadf/tree/pycadf/event.py 20:53:50 hmm, the question of pycadf being awful is slightly orthogonal though, if both the current owner and the future owner agree to move it across 20:53:51 i'm unclear on how adding pycadf to keystone provides any auditing to openstack unless each project implements significant changes 20:54:12 maybe we should start a thread on pycadf awfulness and get some clear list on how to fix it? 20:54:13 devananda: the keystone middleware will use pycadf to emit audit notifications 20:54:14 markmcclain: that hurts 20:54:48 ttx: we should be tactful about it please 20:54:49 ew 20:54:50 markmcclain: okay, yeah that's a bit hard to read 20:54:50 dhellmann: I see, thanks 20:55:05 we need a tactful person to present it 20:55:07 however 20:55:10 any volunteer? 20:55:14 I really don't think it's appropriate for you guys to be trashing this code. As I said, the developers had a lot of domain knowledge. We expected to clean up the implementation over time. 20:55:19 wtf setattr hell 20:55:20 I think markmcclain volunteered 20:55:21