20:02:20 <ttx> #startmeeting tc
20:02:20 <russellb> i'm sure he does.
20:02:21 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:24 <jaypipes> mikal: look out the window
20:02:25 <openstack> The meeting name has been set to 'tc'
20:02:29 <dguerri> I added a topic in th agenda 2 days ago :)
20:02:36 <ttx> (Long) agenda for today is:
20:02:40 <dguerri> was waiting to discuss fit-upstream stuff
20:03:02 <jeblair> dguerri: a new meeting has started, please go to #openstack-infra
20:03:06 <dguerri> *git-upstream
20:03:08 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:09 <dguerri> ok
20:03:15 <ttx> #topic Check progress on gap coverage plans (post-j2 edition)
20:03:24 <eglynn> o/
20:03:24 <ttx> As promised after each milestone we review progress on gap coverage plans
20:03:43 <ttx> promised eglynn we would do him first
20:03:45 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Ceilometer_Gap_Coverage
20:03:50 <eglynn> ttx: thanks :)
20:03:56 <eglynn> well, we've had some some slippage from our target for completion of juno-2
20:04:11 <ttx> eglynn: but everything is under review?
20:04:11 <eglynn> detailed in the strike-thru' on that wiki page
20:04:17 <ttx> oh, not #5
20:04:30 <russellb> how do you feel about completing these by j3?
20:04:37 <ttx> eglynn: could you elaborate on the javelin thing?
20:04:42 <russellb> looks like good progress
20:04:42 <eglynn> russellb: confident
20:04:52 <ttx> QA declining? Something we could help to solve?
20:04:59 <eglynn> ttx: grenade/javelin not yet being as solid as we thought
20:05:12 <eglynn> (so it's kinda closed to new features right now)
20:05:29 <ttx> eglynn: still thinking it can make j3, or is it going to be more of a kilo thing ?
20:05:29 <jogo> eglynn: javelin2 is working now, just needs a few patches to land
20:05:41 <sdague> yeh, it's taken up sometime to get the new javelin code working, so that's an upstream delay.
20:05:46 <eglynn> ttx: definitely juno-3
20:06:07 <ttx> ok, this is taking more time than expected, but still looks doable in juno timeframe
20:06:09 <eglynn> jogo: cool, so we'd be looking at the cdent's patch being landable within weeks?
20:06:15 <eglynn> ttx: agreed
20:06:16 <ttx> comments on Ceilometer?
20:06:46 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage
20:06:49 <ttx> mestery: o/
20:06:56 <mestery> ttx: o/
20:07:00 <jogo> eglynn: without looking to closely I *think* so
20:07:05 <russellb> can we hit status on each gap on this one?
20:07:09 <mestery> russellb: Ack
20:07:10 <eglynn> jogo: great, thanks
20:07:19 <mestery> Gap0 is closed.
20:07:28 <mestery> We finished the DB migration work during Juno-2.
20:07:56 <mestery> 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 <russellb> running all tests now?
20:08:11 <russellb> and how about stability?
20:08:19 <mestery> russellb: I believe that's the case yes, failure rate last I heard was < 5%
20:08:27 <mestery> russellb: I can dig out salv-orlando's email in a bit
20:08:50 <mestery> Gap2 is underway now, on target to close at Juno-3
20:09:08 <mestery> Gap3 has a patch proposed, I think we can look to merge that one soon
20:09:14 <mestery> Gap4 is complete
20:09:27 <mestery> Gap5 is making good progress, and will be complete at Juno-3
20:09:39 <russellb> so last i looked, the code looked pretty far off
20:09:43 <dhellmann> what was the decision on the OVS question?
20:09:45 <russellb> feel confident it will be completed?
20:09:46 <mordred> mestery: gap 5 mentions ovs
20:09:47 <russellb> and yes, that question
20:09:48 <mestery> russellb: DVR?
20:09:53 <russellb> yes DVR
20:09:54 <mestery> Yes, it's for OVS.
20:10:03 <mestery> The DVR code is in much better shape now.
20:10:08 <mestery> We've had lots of core reviews on it, testing, etc.
20:10:16 <mordred> what's the nova/neutron position on the ovs requirement?
20:10:30 <russellb> haven't seen a thread on that, but we should have one.
20:10:36 <mestery> ++
20:10:40 <mestery> russellb: Want me to start it?
20:10:43 <russellb> yes please
20:10:47 <mestery> Will do
20:10:56 <markmcclain> well the OVS requirement may not be a must
20:11:06 <mordred> what a sentence
20:11:11 <mestery> mordred: Heh :)
20:11:35 <mordred> it would still be good to know the relative opinion on requiring that
20:11:38 <markmcclain> haha… so linuxbridge will likely work just not a test path
20:11:56 <markmcclain> 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 <mestery> Lets discuss in detail in the ML thread on that.
20:12:15 <annegentle> what does "not a test path" oh... you mean you can't test linuxbridge? Er.
20:12:22 <russellb> so, aside from lack of testing, no obvious technical reason it wouldn't work with linuxbridge?
20:12:28 <annegentle> yeah I'd like to understand it too
20:12:30 <russellb> ok, yes, to the ML on that
20:12:35 * devananda sneaks in late, lurks in the back
20:12:35 <jaypipes> annegentle: just asked markmcclain the same thing :)
20:12:42 <mestery> So, Gap6 is the one which is behind a bit.
20:12:42 <russellb> 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 <jaypipes> annegentle: he said it does not currently have a test plan in DVR patches
20:13:00 <annegentle> jaypipes: ah ok
20:13:01 <mestery> markmcclain and marun are discussing with nova cores this week is my understanding
20:13:07 <mordred> cool
20:13:09 <russellb> yes, my impression of the migration plan thus far is not very good
20:13:11 <annegentle> and DVR is just the team name or a TLA?
20:13:13 <sdague> the dvr bits are super new as well
20:13:16 <russellb> but yes, i'm interested what progress is made this week
20:13:22 <mordred> annegentle: "distributed virtual router"
20:13:31 <mikal> russellb: upgrade path is on the agenda for later today
20:13:32 <markmcclain> the migration plan has been kicked around in various directions
20:13:33 <russellb> sdague: yes ... hard to call nova-network officially deprecated on merge day
20:13:35 <mestery> russellb: We know we missed the nova spec deadline, and we're working to alleviate that.
20:13:36 <russellb> mikal: cool
20:13:38 <mestery> markmcclain: ++
20:13:44 <mestery> mikal: Thanks!
20:13:44 <annegentle> what not digital video recorder?!
20:13:47 <jaypipes> annegentle: it's the multi-host functionality in neutron -- distributed virtual router. someone correct me if I'm wrong.
20:13:50 <mestery> annegentle: Ha!
20:13:52 <markmcclain> the various ways we've been pointed haven't ended up in a good place
20:13:53 <russellb> i personally feel it's too late for juno to rush something like that
20:13:56 <mestery> jaypipes: You're right :)
20:14:27 <mestery> russellb: The migration path?
20:14:28 <russellb> don't even have a plan, much less an implementation with some proven testing showing stability behind it
20:14:29 <russellb> yes
20:14:29 <annegentle> okay and DVR is the "only" way to get multihost? or the one we've been going after for a while?
20:14:37 <markmcclain> russellb: I don't know that we're actually rushing items
20:15:11 <markmcclain> we have the opportunity to get a working path and then refine within the deprecation window
20:15:15 <mestery> annegentle: That's the plan of record, yes.
20:15:24 <mestery> markmcclain: ++
20:15:26 <russellb> 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 <vishy> o/ i just got off a plane and my connection is spotty
20:15:37 <mestery> We've explored a few options around migration, and had some successes and some issues.
20:15:51 <annegentle> welcome vishy-from-a-plane
20:16:18 <mestery> For closure here, Gap7 is ongoing and will close at the end of Juno
20:16:27 <mestery> So, Gap6 is the main concern here (migration).
20:16:29 <annegentle> mestery: ok thanks
20:16:32 <russellb> so gap 7 says document, but IMO, gap 7 is bigger than that
20:16:38 <mestery> annegentle: you're welcome :)
20:16:40 <russellb> it also mentions scale testing, which is the bigger problem
20:16:51 <russellb> having an open source problem that scales well (and we can show that it does)
20:16:56 <russellb> s/problem/option/
20:16:57 <russellb> ha
20:17:16 <annegentle> problem/opportunity
20:17:18 * jaypipes feels Gap7 should be more descriptive/explicit...
20:17:20 <russellb> :)
20:17:27 <russellb> jaypipes: agree with that
20:17:27 <mestery> russellb: Agreed, the main issue has been finding resources for such scale testing
20:17:37 <mestery> russellb: We've been reaching out to companies around this, it's a WIP to be honest.
20:17:39 <annegentle> on the docs, I'd like more description so we can get more to help out
20:17:40 <russellb> mestery: so any progress beyond just the docs part?
20:17:42 <jaypipes> for instance, what is "document open source scalability testing" really mean?
20:17:43 <russellb> OK
20:17:55 <sdague> mestery: is dvr going to be running on the default neutron jobs?
20:17:57 <mestery> russellb: Nothing huge to report, it's taking time to find companies with resources.
20:18:05 <russellb> 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 <mestery> sdague: The sooner we can get that in, we can make that happen.
20:18:18 <annegentle> 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 <ttx> russellb: maybe we need to have a specific topic on neutron/nova-network at the cross-project meeting?
20:18:34 <mestery> russellb: I think there was slight disconnect there :)
20:18:46 <russellb> ttx: sure ... though i think we're wrapping up the status at least
20:18:48 <mestery> russellb: But I do agree with your assessment around scale
20:18:53 <russellb> ok
20:19:02 <annegentle> 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 <ttx> 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 <russellb> ttx: yep, sounds good
20:19:33 <annegentle> mestery: any other docs efforts?
20:19:42 <ttx> russellb: so.. concerns about Gap6 and Gap7?
20:19:44 <ttx> or more
20:19:49 <mestery> annegentle: emagana has an etherpad with what we need to do, it was shared in monday;s neutron meeting
20:20:04 <ttx> and maybe Gap5?
20:20:09 <annegentle> mestery: ok, I've edited that, so sounds like we know what we know
20:20:09 <russellb> ttx: primary concerns are with 5, 6, and 7
20:20:09 <jaypipes> so... hold up one sec
20:20:15 <mestery> annegentle: ack
20:20:20 * russellb holds up
20:20:26 <jaypipes> sitting next to markmcclain and he is frustrated with lack of clarity and specifics around Gap6 and Gap7
20:20:39 <jaypipes> 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 <russellb> i think there was much  more detailed discussion than ended up captured on this page ...
20:20:53 <jaypipes> mestery: what is the status from Oleg on Gap6? any specific status from him?
20:21:05 <ttx> #info TC voices concerns about Gap 5, Gap 6 and Gap 7 -- further precisions needed
20:21:05 <mestery> jaypipes: The status is his BP didn't make the nova cut :(
20:21:26 <mestery> 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 <jaypipes> mestery: could we put a link in that wiki to the relevant specs or etherpads pls?
20:21:31 <russellb> shall we take an action for a subet of folks to work on further clarity around expectations here?
20:21:33 <mestery> jaypipes: ++
20:21:42 <mestery> russellb: Yes, please
20:21:43 <russellb> i'm happy to assist.
20:21:43 <dhellmann> russellb: that's a good idea
20:21:47 <jaypipes> mestery: just helps in getting the details about those gaps.
20:21:56 <mestery> jaypipes: yes, agreed
20:22:05 <ttx> let's expand on that during the cross-project meeting if that works for everyone
20:22:11 <mestery> ttx: ++
20:22:30 <ttx> moving to next
20:22:39 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Trove_Gap_Coverage
20:22:43 <russellb> #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 <jaypipes> mestery: so, on Gap6, it currently says "This work is currently being scoped.". Should that be "This work is scoped now in blueprint <LINK>".
20:23:03 <mestery> jaypipes: Yes, that makes more sense.
20:23:22 <ttx> 3 first gaps on Trove still open
20:23:23 <SlickNik> So for trove we made really good progress on Gap 5 - it's now complete.
20:23:31 <SlickNik> (Neutron support)
20:24:24 <ttx> with gap 2 and gap 3 moved from j2 to j3
20:24:58 <SlickNik> So for gap 2 we finished up the API docs.
20:25:05 <ttx> SlickNik: how confident are you for completion of those two by j3?
20:25:28 <SlickNik> And we went through an exercise identifying where we have holes in the docs.
20:25:47 <SlickNik> Results of that are at: https://etherpad.openstack.org/p/trove-doc-items
20:26:03 <SlickNik> I'm confident that we can address these in juno-3 (gap 2)
20:26:25 <ttx> doc can be worked on post-j3 anyway
20:26:48 <annegentle> SlickNik: yeah you've made good progress there
20:26:48 <ttx> more concerned about gap3 honestly
20:27:13 <SlickNik> Getting gap 3 done by j3 has become _my_ top priority.
20:27:14 <ttx> does tat need more infrfa lova ? anything we can do to help?
20:27:19 <russellb> getting changes in upstream CI is less and less likely as we approach end of cycle
20:27:20 <ttx> ow
20:27:25 <russellb> based on history at least
20:27:31 <ttx> I meant "does that need more infra love"
20:27:45 <SlickNik> ttx: yes that would help
20:27:52 <ttx> jeblair: ^
20:28:00 <jeblair> 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 <SlickNik> But they've been great so far :)
20:28:14 <SlickNik> especially clarkb, fungi, and jeblair
20:28:33 * fungi has not been great
20:28:36 <SlickNik> It's me who's had my plate somewhat full tackling the neutron gap.
20:28:39 <russellb> fungi: you're always great :)
20:28:40 <ttx> #info TC expresses concerns about Gap 3, keep us posted on progress
20:28:50 <ttx> OK, other remarks on Trove?
20:28:51 <SlickNik> ttx: Will do.
20:29:05 <fungi> ttx: "infra tough love"
20:29:07 <russellb> <3 infra
20:29:09 <annegentle> or lava
20:29:32 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Horizon_Gap_Coverage
20:29:35 <clarkb> too much going on
20:29:36 <ttx> david-lyle: ohai
20:29:40 <SlickNik> Thanks guys!
20:29:47 <david-lyle> ttx: o/
20:30:05 <david-lyle> Gap 1 is up for review
20:30:18 <ttx> yeah, it's us slacking there
20:30:25 <ttx> will get it solved in 5 min
20:30:38 <ttx> david-lyle: you mean Gap 0?
20:31:17 <david-lyle> 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 <ttx> #info Gap 1 unlikely to be closed within Juno timeframe
20:31:53 <dhellmann> david-lyle: have a link to the requirements change?
20:31:56 <ttx> I think that's relatively fine, though
20:32:13 <ttx> more interested in getting Gap 4 covered tbh
20:32:24 <annegentle> sorry you all, I have to drop off now, but will catch up tonight
20:32:24 <ttx> how is that (gap 4) going?
20:32:29 <ttx> annegentle: o/
20:32:31 <david-lyle> dhellmann: https://review.openstack.org/#/c/97793/
20:33:07 <david-lyle> ttx: we are making progress, but I don't know that it will be integrated into the gate in Juno
20:33:10 <jeblair> #link https://review.openstack.org/#/c/97793/
20:33:40 <ttx> #info Gap 4 might miss the target too
20:33:50 <david-lyle> in fact I imagine it won't as we get more functionality there
20:33:59 <ttx> david-lyle: feeling confident on all the other ones, right?
20:34:06 <david-lyle> yes
20:34:11 <jeblair> 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 <ttx> Other comments on horizon?
20:34:44 <jeblair> david-lyle: and so that's the blocker for the toolkit/django repo split?
20:34:46 <david-lyle> jeblair: the xstatic packages are pulling out those common components
20:35:02 <david-lyle> yes, that's a blocker at this point
20:35:47 <jeblair> thank
20:35:48 <jeblair> s
20:35:55 <david-lyle> there will be some repo work once that resolves, but that's the hardest part
20:36:13 <ttx> I think that affects only Horizon though
20:36:21 <ttx> so i'm relatively fine with it missing the mark
20:36:26 <ttx> ok, glance
20:36:28 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Glance_Gap_Coverage
20:36:35 <david-lyle> correct, but it will add an openstack requirement for the horizon_lib package
20:36:41 <david-lyle> thanks
20:36:52 <ttx> Looks like the only gap there missed the j2 mark
20:36:55 * markmcclain approves 97793
20:36:57 <jeblair> and may be a bit disruptive as we rework the gate structure for both repos
20:37:24 <jeblair> (but i'm very much looking forward to it!)
20:37:24 <ttx> markwash: if you're arond, can you comment on having that gap covered in j3?
20:37:34 <markwash> o/
20:37:52 <markwash> we had some effort around figuring out exactly where we need to change the image data bits in tempest
20:38:06 <markwash> but then actually fixing it seems to have not had much progress
20:38:12 <markwash> so I'm add the review right now
20:38:20 <markwash> expect it to be in gerrit within the hour
20:38:27 <markwash> s/add/adding
20:38:28 <ttx> markwash: ok
20:38:33 <ttx> Commenst on Glance?
20:39:01 <ttx> #topic Blessing Heat gap coverage plan
20:39:08 <ttx> Heat was under gap analysis at the last meeting
20:39:12 <ttx> zaneb proposed the following plan:
20:39:17 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Heat_Gap_Coverage
20:39:34 <ttx> The last item still needs a date/owner
20:39:45 <ttx> I assume it's a j3 item and that it will have an owner
20:39:58 <ttx> With that objection noted, I think it looks like a good plan
20:40:11 <russellb> +1
20:40:28 <ttx> #info Gap 3 needs an owner and a target milestone
20:40:38 <ttx> #info Other wise plan looks good, make it happen
20:40:48 <ttx> Remarks on that?
20:41:19 <ttx> #topic Expand scope of the Identity program
20:41:24 <ttx> dolphm: around?
20:41:28 <dolphm> o/
20:41:29 <ttx> So that's two separate parts:
20:41:34 <ttx> * Expand scope of the Identity program to include auditing (https://review.openstack.org/109664)
20:41:45 <ttx> 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 <ttx> * Rename the "Identity" program (https://review.openstack.org/108739)
20:42:02 <ttx> So... This one raises an interesting question, which was also raised by Glance recently
20:42:08 <dhellmann> we talked about it at the oslo meeting, and the oslo-core and pycadf-core teams agree to the move
20:42:13 <ttx> 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 <dolphm> dhellmann: ++
20:42:21 <ttx> i.e. the Compute team produces Nova, also known as OpenStack Compute
20:42:29 <ttx> but with programs taking on multiple projects, we reach the limits of this system
20:42:37 <ttx> So I think we may need to divorce the team names from the OpenStack names.
20:42:44 <russellb> ttx: makes sense.
20:42:48 <ttx> 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 <ttx> Which solves the issue with marketing wanting to have a say on the "OpenStack names" we pick or rename
20:43:09 <mikal> russellb: yeah, I think nova will hit this in the next few releases too
20:43:41 <jeblair> what would the nova/compute team want to rename themselves to if their product is still 'openstack compute'?
20:44:08 <ttx> jeblair: Nova is the counterexample, it would probably have the same term used in both places
20:44:09 <jeblair> i'm just trying to get a handle on the issue :)
20:44:15 <ttx> But Glance or keystone...
20:44:31 <ttx> jeblair: just look at https://review.openstack.org/108739
20:44:32 <mikal> 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 <mikal> jeblair: i.e. when we have a gantt project as well
20:44:46 <russellb> i think this is a bit of an side from the reviews at hand ...
20:44:56 <russellb> aside*
20:44:57 <jeblair> mikal: gotcha
20:44:57 <mikal> russellb: agreeed
20:45:05 <ttx> Keystone can't be named "OpenStack Authentication, Authorization, and Audit"
20:45:07 <mikal> Its more that I am interested in where the precident goes
20:45:15 <russellb> ttx: well I'm -1 on the rename, anyway :)
20:45:30 <eglynn> tripleA?
20:45:38 <russellb> I think Identity is just fine.
20:45:46 <ttx> russellb: but do you recognize it will become a problem as programs take on more projects?
20:45:46 <jaypipes> ++
20:45:46 <russellb> it is concise, clear, and captures the primary mission.
20:45:51 <morganfainberg> 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 <vishy> openstack-triple-a
20:46:05 <russellb> morganfainberg: it's your primary mission, for sure, right?
20:46:13 <morganfainberg> 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 <sdague> russellb: ++
20:46:16 <dolphm> russellb: the issue with "identity" is that providing a source of "identity" is our last priority
20:46:17 <russellb> the mission statement is for covering your full scope
20:46:21 <russellb> not the name of the program
20:46:29 <morganfainberg> dolphm, ++
20:46:31 <sdague> morganfainberg: yeh, but I think changing that name is more confusing than leaving it
20:46:44 <sdague> because there is inertia in understanding
20:46:46 <morganfainberg> sdague, that is a better arguement imo
20:46:51 <russellb> dolphm: i think that's splitting hairs ... it provides identity to openstack via some way ... it's the identity API
20:46:51 <jaypipes> we don't call the Compute program "The Compute, Containers, Bare-metal, Hypervisors, and Virtualization" program, either.
20:47:01 <devananda> 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 <mikal> jaypipes: that's a great idea. Not.
20:47:13 <dolphm> russellb: we abstract the identity problem away from openstack, for sure
20:47:17 <ttx> 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 <jeblair> devananda: https://review.openstack.org/#/c/109664/1
20:47:25 <russellb> ttx: pretty much, yes
20:47:34 <ttx> russellb: ok, that's valid
20:47:35 <markmcclain> jaypipes: s/and Virtualization/Virtualization and Kitchen Sink/
20:47:47 <ttx> let's cross that bridge when we get there
20:47:52 <russellb> ttx: yes :)
20:47:57 <ttx> 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 <ttx> But then chaging name is about as confusing
20:48:28 <devananda> 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 <dhellmann> well, in the oslo program we have several teams, so I'm not sure that fits us
20:48:51 <russellb> ttx: i'm neutral on that ... but agree that i've seen the confusion.
20:48:54 <dolphm> 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 <devananda> jeblair: eg, measurements (ceilometer) is a single program which other programs must integrate with. is Auditing following that model?
20:48:56 <mikal> ttx: we only just picked "programs", let's stick with it for a while
20:49:04 <russellb> ttx: question is, will time solve the confusion, or do we need to change
20:49:17 <dhellmann> mikal: +1
20:49:33 <ttx> hehe
20:49:34 <devananda> dolphm: what is to be audited -- events within other projects/programs, right?
20:49:39 <russellb> i'm inclined to stick with it for now (programs)
20:49:51 <dolphm> devananda: yes; we started with authentication & authorization events in keystone, for example
20:49:56 <ttx> I think the discussion can continue on the review themselves
20:50:09 <ttx> and be back on the agenda when we expressed ourselves there
20:50:40 <ttx> 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 <ttx> both*
20:50:53 <russellb> ttx: it's more than a project move though
20:50:53 <ttx> The second one sounds more funny than expected
20:50:56 <russellb> ttx: it also updates mission
20:51:00 <mikal> dolphm: waitup one sec
20:51:02 <ttx> ah. Good point
20:51:06 <mikal> dolphm: the pycadf code is a bit... weird
20:51:08 <ttx> I'll wait for 7 YEs on there then
20:51:13 <markmcclain> so can we require that pyCADF gets a revamp?
20:51:14 <mikal> dolphm: are you committing to making it less odd?
20:51:22 <markmcclain> the code is somewhere between terrible and awful
20:51:30 <ttx> terriful?
20:51:32 <mikal> markmcclain: it is intertaining
20:51:32 <russellb> tell us how you really feel :)
20:51:34 <dolphm> mikal: are you offering to propose a list of oddities to tackle?
20:51:36 <sdague> ttx: ++
20:51:37 <markmcclain> haha
20:51:48 <mikal> dolphm: not overly?
20:51:52 <markmcclain> dolphm: have you read it?
20:51:58 <mikal> dolphm: I do think it needs a spring clean though
20:52:02 <dhellmann> 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 <russellb> gap: make it suck less
20:52:04 <russellb> ?
20:52:06 <mikal> dolphm: do you disagree with me?
20:52:12 <fungi> did we have any outstanding plans for a security audit of pycadf? is it targeted for vmt support?
20:52:13 <dolphm> markmcclain: not exhaustively
20:52:14 <sdague> make it not be thinly translated java code
20:52:24 <dolphm> mikal: i call it opinionated :)
20:52:36 <sdague> dolphm: like it wants to be java?
20:52:39 <ttx> sdague: ew, that would be my definition of terriful. Translated from java code into Python
20:52:55 <russellb> AuditFactoryFactory?
20:53:10 <fungi> clearly that's a factory which builds audit factories
20:53:43 <markmcclain> #link http://git.openstack.org/cgit/openstack/pycadf/tree/pycadf/event.py
20:53:50 <ttx> 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 <devananda> i'm unclear on how adding pycadf to keystone provides any auditing to openstack unless each project implements significant changes
20:54:12 <ttx> maybe we should start a thread on pycadf awfulness and get some clear list on how to fix it?
20:54:13 <dhellmann> devananda: the keystone middleware will use pycadf to emit audit notifications
20:54:14 <russellb> markmcclain: that hurts
20:54:48 <mikal> ttx: we should be tactful about it please
20:54:49 <ttx> ew
20:54:50 <jeblair> markmcclain: okay, yeah that's a bit hard to read
20:54:50 <devananda> dhellmann: I see, thanks
20:55:05 <ttx> we need a tactful person to present it
20:55:07 <jeblair> however
20:55:10 <ttx> any volunteer?
20:55:14 <dhellmann> 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 <vishy> wtf setattr hell
20:55:20 <mikal> I think markmcclain volunteered
20:55:21 <jeblair> considering that it's middleware, how much do we really care about the api?
20:55:36 <jeblair> er i mean the internal api
20:55:52 <morganfainberg> jeblair, some projects use it directly, so the internal api does matter some
20:55:55 <mikal> dhellmann: I agree, I think we can improve it without getting personal about it
20:56:04 <markmcclain> mikal: ++
20:56:05 <mikal> dhellmann: we've all written code we regret in the past
20:56:06 <sdague> jeblair: well, I think the question is maintainability if it's a core part of a project
20:56:08 <morganfainberg> jeblair, but ... not sure if it's a huge deal (and can be cleaned up as we go)
20:56:13 <markmcclain> I'd just like to see if be much more pythonic
20:56:14 <vishy> its just unpythonic ut im sure the code is fine
20:56:19 <dhellmann> mikal: and sometimes the not too distant past :-)
20:56:22 <ttx> ok, so no need to trash it
20:56:26 <mikal> dhellmann: or the future
20:56:30 <mikal> I am doing it now
20:56:32 <ttx> and again, this discussion is a bit orthogonal to the issue
20:56:44 <ttx> and we need to move on
20:56:46 <mikal> ttx: well, I do think we are asking if keystone can shepherd this forwards
20:56:53 <dhellmann> mikal: you're in a weird time zone, your past might be my future
20:56:54 <jeblair> ttx: well, we're talking about a scope expansion, so i don't think it's entirely unrelated
20:57:00 <mikal> ttx: if that's a yes, then I'm cool with it
20:57:03 <ttx> mikal: everybody seem to be happy for them to do so ?
20:57:04 <dolphm> mikal: that's a yes
20:57:16 <mikal> dolphm: then I am cool
20:57:32 <ttx> if dhellmann and dolphm are fine with transition I-m fine
20:57:42 <ttx> further comments on the review!
20:57:43 <dhellmann> I'm fine, and gordc (primary maintainer) is fine.
20:57:46 <markmcclain> dolphm: thanks
20:57:48 <ttx> #topic Other governance changes
20:57:53 <ttx> * Add repository glance.store to glance (https://review.openstack.org/107585)
20:58:00 <ttx> I'll need markwash to confirm he wants it in, then if nobody objects I'll approve it
20:58:11 <ttx> * Adds the openstack/os-net-config to TripleO... (https://review.openstack.org/108745)
20:58:17 <ttx> lifeless did approve it -- so I'll approve unless someone objects to it today
20:58:22 <ttx> * Adding Horizon mission statement (https://review.openstack.org/102050)
20:58:24 <markwash> ttx: we're having a little discussion about that this week
20:58:34 <markwash> ttx: so hold off for at least two days :-)
20:58:36 <ttx> Still one approval short on that last one
20:58:45 <ttx> dhellmann agreed to disagree
20:58:57 <ttx> so we just need another +1 and be done with it
20:58:58 <markwash> hmm, should I add that note to the review?
20:59:04 <ttx> markwash: yes please
20:59:15 <ttx> when OK with it, add that you support it (+0)
20:59:24 <ttx> #topic Cosmetic governance changes
20:59:29 <ttx> * Updates the Designate repo namespace to openstack/ (https://review.openstack.org/107395)
20:59:34 <ttx> I'll approve this one now, it has enough approvals
20:59:43 <ttx> * Sync programs.yaml with current gerrit repos (https://review.openstack.org/107690)
20:59:53 <ttx> So for this one, my goal was to find adopters for the remaining ones on the list... But at this point it's probably simpler to propose them as further changes
21:00:00 <ttx> jeblair: I suspect you want a few of those in "infra"
21:00:10 <ttx> maybe just adopt them in a future change
21:00:20 <ttx> * use ">" to indicate multiline mission statements (https://review.openstack.org/109021)
21:00:27 <ttx> rebases ahead! will approve once we get the previous ones in to avoid most of those
21:00:34 <ttx> #topic Open discussion
21:00:40 <ttx> Two things I wanted to quickly mention before we clsoe
21:00:48 <ttx> griff started a TC thread on "Block Storage abstractions in Cinder"
21:00:51 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2014-July/000736.html
21:00:59 <ttx> I'm not sure there is any meeting discussion/action for us to take on it
21:01:05 <ttx> If you think otherwise, let me know
21:01:09 <jeblair> griff: oh you changed your name?
21:01:10 <jaypipes> Speaking of Java code masquerading as Python code...
21:01:13 <ttx> In other news, Ryan Lane resigned from the User committee
21:01:19 <ttx> Since he was the nominee from the TC, Tim Bell asked us to nominate someone else
21:01:29 <ttx> So please think about names which would make great representatives of OpenStack users -- then we can pick one and ask that person if they would be interested
21:01:35 <ttx> Anything else, anyone ?
21:01:40 <anteaya> thanks to Ryan_Lane for all his great work
21:01:47 <jeblair> sad to hear that :(
21:02:14 <ttx> discussing names will be for a future meeting discussion
21:02:41 <ttx> Those interested in further digging into Neutron gap coverage progress, you can stay tuned as we'll tackle some of that in the cross-project meeting next
21:03:02 <ttx> ok, closing meeting in 30sec, famous last words
21:03:06 <jaypipes> ttx: re: the Cinder block storage abstraction...
21:03:12 <ttx> jaypipes: yes?
21:03:16 <jaypipes> ttx: it also is Java code trying to be Python.
21:03:24 * jaypipes ecourages TC folks to review the code...
21:03:50 <ttx> ack
21:04:01 <ttx> contribute to that thread with further thoughts.
21:04:03 <ttx> Thanks everyone
21:04:09 <ttx> #endmeeting