20:01:33 <ttx> #startmeeting tc
20:01:34 <openstack> Meeting started Tue Feb 25 20:01:33 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:39 <openstack> The meeting name has been set to 'tc'
20:01:39 <SergeyLukjanov> o/
20:01:41 <ttx> So I'm back, yay
20:01:50 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:06 <ttx> #topic Progress on DefCore feedback
20:02:14 <ttx> #link https://review.openstack.org/#/c/74483/
20:02:23 <ttx> I hope everyone had a chance to catch up with the current draft over the week
20:02:37 <ttx> So far we had a number of +1s on the review. Comments ? Strong objections ?
20:02:47 <mikal> I haven't received any negative comments
20:03:05 <ttx> Counting mikal's implied +1 that makes 8 YES and no objection, so I can approve it after meeting
20:03:18 <dhellmann> I'm assuming we'll make a pass for typos and punctuation and stuff before sending it?
20:03:24 <jeblair> i think i agree with just about everything in it
20:03:35 * jgriffith needs a bit more time
20:03:36 <mikal> dhellmann: comment on errors in gerrit and I will fix
20:03:56 <dhellmann> mikal: ok, there were lots of sentences in bullets without caps on the first char, so that may just be a style thing
20:03:58 <ttx> dhellmann: Ideally we'd fix typos and punctuation BEFORE writing it as a final resolution
20:04:13 <zehicle_at_dell> o/
20:04:26 <ttx> mikal: do you know when the next DefCore meeting will be ?
20:04:33 <ttx> Ah! I guess zehicle knows
20:04:36 <mikal> Heh
20:04:42 <zehicle_at_dell> ttx: Monday
20:04:42 <mikal> There's a physical meeting soon
20:04:51 <mikal> And a VC at a time which doesn't work for me this week IIRC
20:05:02 <zehicle_at_dell> #link https://etherpad.openstack.org/p/DefCoreElephant.5
20:05:03 <mikal> I missed last weeks meeting because my day sucked, which I apologise for
20:05:08 <ttx> mikal: so it would be great to have the final base position approved by then, so that you can represent it
20:05:28 <zehicle_at_dell> #https://etherpad.openstack.org/p/DefCoreElephant.4 from last time, we try to keep good notes
20:05:35 <mikal> Oh, there's a remote option now
20:05:36 <mikal> Cool
20:05:51 <ttx> or anne may be able to stand in for you
20:06:34 <ttx> jgriffith: is the "more time" you need measured in minutes or days ?
20:06:45 <jgriffith> ttx: I'm done
20:06:54 <jgriffith> ttx: waiting for people to throw shoes at me
20:06:54 <ttx> jgriffith: and what's the verdict ?
20:06:59 <jgriffith> I'm a -1
20:06:59 <vishy> sorry i'm late, my irc bouncer crashed
20:07:04 <ttx> hah!
20:07:07 <jgriffith> Most of it I agree with
20:07:20 <jgriffith> but I can't get passed the "black box API" suggestion
20:07:25 <ttx> "disagree that API blackbox is the right answer. Anybody can write an interface for anything that's 100% compat with OpenStack API's so this IMO misses the point."
20:07:26 <mikal> jgriffith: reading your comment
20:07:34 <mikal> jgriffith: we're not saying that black box is _the_ answer
20:07:43 <mikal> jgriffith: we're saying is the _start_ of an answer
20:07:44 <jgriffith> ttx: was nice enough to paste it above :)
20:07:47 <markmc> jgriffith, the trademark rules already require you to run the code
20:07:51 <ttx> let's allocate 10 minutes to discuss that, I don't want it to steal all the meeting time
20:07:53 <jgriffith> mikal: then it shouldn't be suggested IMO
20:07:58 <markmc> jgriffith, the requirement is rather vague though
20:08:10 <jgriffith> markmc: hey... I'm just one guy, and I get to vote
20:08:19 <mikal> jgriffith: well, we say its what we think can get done for Icehouse and that we'll iterate
20:08:20 <jgriffith> markmc: if I'm crazy so beit :)
20:08:24 <markmc> jgriffith, of course - I'm just discussing ?
20:08:29 <lifeless> so I share jgriffith's concern FWIW
20:08:33 <markmc> jgriffith, clarifying ...
20:08:38 <jgriffith> markmc: understood sorry
20:08:45 <lifeless> but I also agree that black box testing is a good, common, necessary but not sufficient condition
20:08:47 * jgriffith tries to be funny sometimes and it doesn't work out well
20:08:58 <ttx> lifeless: it's only a first step, if you read the draft
20:09:12 <ttx> lifeless: as in, better than nothing and maybe doable for icehouse release
20:09:13 <lifeless> ttx: I know
20:09:17 <jgriffith> lifeless: that's kinda the way I feel.. the API component is assumed IMO
20:09:18 <lifeless> ttx: I voted +1 on the draft.
20:09:49 <mikal> API testing is also better than what we have now
20:09:54 <mikal> Which is mostly a hand wavey promise
20:09:55 <jgriffith> I feel I may be worrying about this more than I should
20:09:59 <markmc> no-one is saying passing API tests is sufficient alone for TM usage
20:10:29 <jeblair> last time we discussed that the current state is that you must "run all the code" to use the trademark, and the suggestions in the draft wouldn't change that....
20:10:34 <ttx> that draft doesn't claim to have an answer. It exposes some discomfort with the question that was asked, requires clarification on a number of items and proposes a first achievable step for icehosue
20:10:42 <jgriffith> markmc: fair enough
20:10:43 <jeblair> jgriffith: do you want a response that makes that more explicit?
20:10:49 <dhellmann> jgriffith: I do share some of your concern, maybe we can make the wording stronger?
20:10:52 <sdague> so, out of curiosity, has anyone sniff tested that APIs for the big openstack public clouds
20:10:57 <jgriffith> markmc: jeblair yes, explicit is better than implicit IMO
20:11:12 <jgriffith> sdague: elephant in the room
20:11:17 <mikal> sdague: could you consider nodepool to be a simple sniff test?
20:11:20 <jeblair> sdague: o/  :)
20:11:22 <mordred> sdague: infra uses hp and rax
20:11:24 <mordred> yeah
20:11:26 <mordred> what mikal said
20:11:26 <lifeless> ttx: I have to drop out for 10m to drop C off at kindy
20:11:32 <ttx> lifeless: ack
20:11:39 <sdague> mordred: yeh, through novaclient, which hides a ton of differences
20:11:40 <ttx> lifeless: we shall have moved on
20:11:44 <mordred> hehe. we should just say "if nodepool works, you're openstack" :)
20:11:49 <jgriffith> mordred: are HP and RAX the only ones that matter, and do you use the API's that heavily?
20:11:52 * mordred is joking
20:12:25 <sdague> and I know defcore is talking about tempest as a basis for some of this. It just seems like some early data would be handy to understand how sane the approach is
20:12:26 <jeblair> sdague: it's full of "if we detect rackspace behavior, do rackspace thing", but i fear most of that isn't api violations, it's, erm, "flexibility" in what the api allows
20:12:27 <mordred> jgriffith: nope to both - just saying, we _do_ use the apis in production across four different openstack versions of cloud successfully
20:12:29 <mikal> I think maybe if people have concerns big enough to vote -1 they should comment in gerrit so they're tracked
20:12:36 <jgriffith> mordred: fair
20:12:43 <mordred> and what jeblair said
20:12:44 <jgriffith> mikal: I did
20:13:01 <mikal> jgriffith: I know, but others are concerned now too. You've started a thing.
20:13:11 <jgriffith> dang me!!!
20:13:23 <mikal> I don't mind taking some time today to try and address people's concerns
20:13:31 <mikal> But we should try to not keep defcore people waiting too long
20:13:35 <jeblair> mikal: i still support the draft as written, but would also support adding something that addresses jgriffith's concerns
20:13:42 <ttx> OK, let's continue the discussion in the code review, and raise any strong disagreement as a -tc thread. See what we can come up in time for the next DefCore meeting (Monday)
20:13:48 <jgriffith> My suggestion would be API compat as a seperate effort/proposal or at least a sub-task
20:13:57 <jgriffith> but that it be explicit that that's what it is
20:14:05 <jeblair> mikal: (because i feel it's making something explicit that is currently implicit)
20:14:18 <dhellmann> mikal: my concerns were eased by the statement that this is just the start and we already require "all the code"
20:14:22 <mikal> jgriffith: let's have a chat in PM after the meeting and see if we can nail something down
20:14:32 <jgriffith> mikal: sure
20:14:35 <ttx> mikal: +1
20:14:52 <mikal> dhellmann: I'm not 100% sure the words are "all the code" or just "the code".
20:14:55 <jgriffith> dhellmann: that's a valid point
20:14:58 <mikal> markmc: ^-- do you know which?
20:15:08 <mordred> I believe it's "the code"
20:15:10 <markmc> mikal, digging up a link now
20:15:32 <dhellmann> "the code" isn't "some of the code" so isn't it "all the code"?
20:15:34 <mikal> I can certainly add something saying we believe that statement shouldn't be removed yet
20:15:51 <mikal> i.e. API tests are not a sufficient replacement
20:15:54 <jgriffith> dhellmann: explicit is better than implicit
20:15:54 <markmc> "
20:15:55 <markmc> include the entirety of the OpenStack [..] code from either of the latest
20:15:55 <markmc> two releases and associated milestones, but no older, and
20:15:56 <markmc> "
20:16:02 <jgriffith> I can translate english however is convenient
20:16:03 * markmc looking at https://raw.github.com/markmc/governance/defcore/resolutions/20140211-tc_defcore_response
20:16:04 <jgriffith> :)
20:16:16 <dhellmann> "entirety" sounds like "all"
20:16:16 * annegentle_web slides into the back of the room
20:16:32 <markmc> jbryce quoted here:  http://lists.openstack.org/pipermail/openstack-dev/2014-February/026559.html
20:16:43 <ttx> OK, time is up. Let's continue iterating on the draft, with the Monday deadline in mind
20:16:52 <ttx> and move on
20:16:56 <mordred> ++
20:16:57 <mikal> Cool
20:17:05 <ttx> #topic Creating key distribution service (KDS) under identity program
20:17:12 <ttx> #link https://review.openstack.org/#/c/73022/
20:17:20 <ttx> So... As I mentioned in http://lists.openstack.org/pipermail/openstack-tc/2014-February/000540.html ...
20:17:34 <ttx> We don't need to approve project additions to a program, unless one of the TC members flags it as potentially overstepping defined bounds, in which case we schedule a discussion about it
20:17:48 <ttx> And obviously if the project files for incubation, it needs to go through our regular procedure (incubation request)
20:18:06 <ttx> Here there are two issues. One is the addition to the "integrated" section, which obviously can't happen before Juno starts... but I think that was just misplacement in the YAML
20:18:31 <ttx> The other is about the project addition itself, which I flagged for discussion and put on the agenda
20:18:45 <ttx> My question is, how this would be affected long-term by Barbican, which also promises to "distribute keys" ?
20:18:58 <ttx> dolphm: you around ?
20:19:05 <ttx> jraim_ too
20:19:11 <jraim_> ttx: I'm here
20:19:13 <dolphm> ttx: o/
20:19:44 <ttx> dolphm: could you first confirm that you just want to add a new project to the program, not a new integrated piece to openStack common release ?
20:20:24 <dolphm> ttx: exactly - when/whether it's integrated isn't my immediate concern at all
20:20:42 <ttx> dolphm: ok, good
20:20:43 <dolphm> i really just want to ensure that the code has a proper place to live next week (outside of keystone)
20:21:06 <ttx> My understanding was that this is a temporary change, more to avoid shipping the KDS *in* Keystone in Icehouse and have to maintain/deprecate it in the near future when Barbican will be ready to replace it
20:21:06 <zehicle_at_dell> I'd like for DefCore to take up answering these questions at the meeting on Monday
20:21:23 <dolphm> ttx: correct
20:21:37 <russellb> zehicle_at_dell: the questions in the draft response?
20:21:42 <ttx> zehicle: maybe follow the draft review on https://review.openstack.org/#/c/74483/
20:21:49 <dolphm> the key dist implementation isn't ready to ship, and even if it was - it's a discrete service bundled into the tree that doesn't really belong (nor share anything in common with keystone outside of keystone.openstack.common)
20:21:58 <zehicle_at_dell> russellb & ttx, ok thanks
20:22:05 <ttx> dolphm: If that's the case (temporary), then I'm not sure we should use the openstack/* namespace for temporary drops of code
20:22:19 <ttx> This could live in stackforge with a specific set of core devs
20:22:29 <dolphm> stackforge/ is absolutely fine with me
20:22:32 <ttx> especially if we approve barbican soon
20:22:37 <dhellmann> what's the relationship between this code and barbican? are they separate implementations of the same feature?
20:23:28 <russellb> IMO, the reason we pushed for keystone to ship this a long time ago is because it seemed to fit OK with the program, and we thought we could get it out sooner that way
20:23:39 <ttx> I understand the need for that code to live somewhere, in a somewhere that is not Keystone icehouse release
20:23:39 <russellb> but if we're approving barbican soon (seems likely), it's making less and less sense i think ...
20:23:46 <russellb> barbican doesn't support what this does, though
20:23:48 <dolphm> dhellmann: kds / kite is providing a heavily requested feature for nova (the groundwork for secure messaging); which potentially overlaps with barbican's long term roadmap
20:23:59 <dolphm> dhellmann: today, they don't overlap
20:24:04 <dhellmann> ok
20:24:05 <ttx> russellb: that's why if tha code needs to live somewhere, I'd rather have it in stackforge
20:24:11 <mordred> to be contrary
20:24:22 <russellb> but nova can't really use it unless it's an official project IMO
20:24:25 <russellb> so we're no better off
20:24:31 <jraim_> agree with dolph. From my point of view, the point of putting kds into keystone was to launch before barbican was ready. It doesn't seem ready for icehouse, so it seems like we could subsume it into barbican for juno
20:24:32 <morganfainberg> dhellmann, and it wasn't clear when they would overlap.
20:24:42 <mordred> dolphm: do you feel that people doing work on this are doing work that's part of the openstack identity program?
20:25:05 <ttx> mordred: they are looking like a separate group of people to me
20:25:06 <dhellmann> we have lots of repositories in openstack/* that aren't integrated but are owned by an official program; what's the issue with adding this one?
20:25:10 <sdague> does that mean we are waiting for secure messaging until barbican is an integrated project?
20:25:20 <mordred> dhellmann: that's what I was getting at
20:25:24 <ttx> dhellmann: it's the fact that we all think it will have to be removed in 6 months
20:25:29 <russellb> sdague: that's what we were originally hoping to avoid ...
20:25:35 <dhellmann> ttx: why do we think that?
20:25:47 <russellb> but if it's split into its own project, and not an extension to keystone, it's not going to happen any sooner
20:25:48 <ttx> dhellmann: because it's overlapping with Barbican goals
20:25:52 <mordred> ttx: I heard "on barbican's long-term roadmap"
20:25:56 <mordred> ttx: I did not hear 6 months
20:26:03 <ttx> mordred: I heard "in Juno"
20:26:11 <ttx> "it seems like we could subsume it into barbican for juno"
20:26:26 <sdague> ttx: sure, but that doesn't help nova
20:26:31 <dolphm> mordred: there's not substantial contributions from the existing keystone community
20:26:32 * markmc has to drop off
20:26:37 <mordred> kk
20:26:47 <ttx> I mean, if it's meant to live for a few cycles, then I agree to have it in openstack/kite
20:26:48 <dhellmann> sdague: is nova going to use a non-integrated project from keystone?
20:26:55 <jraim_> mordred: I don't think I have a problem with the feature in theory, but no work in Barbican has been done to support it yet
20:27:01 <morganfainberg> ttx, originally that was not an option during the earlier conversations, it wasn't clear when the overlap/move to barbican would occur
20:27:02 <sdague> dhellmann: well that's the other open question
20:27:05 <ttx> but if everyone wants it to die after icehouse, then it feels a bit weird
20:27:05 <russellb> dhellmann: sdague no...
20:27:12 <sdague> and the answer should be no
20:27:13 <dhellmann> russellb: right, that's what I thought
20:27:15 <sdague> like russellb said
20:27:19 <dhellmann> +1
20:27:51 <ttx> morganfainberg: I would not be asking this question if we weren't considerign barbican for incubation
20:28:01 <russellb> if this has to be a new project, and it's on incubation cycle and such, i think we should be shooting for barbican
20:28:04 <ttx> that changed the rules a bit
20:28:09 <morganfainberg> ttx, makes perfect sense.
20:28:18 <russellb> it only makes sense outside of barbican if it could have been an extension to keystone that could be released much quicker
20:28:26 <russellb> IMO, anyway
20:28:35 <ttx> russellb: it won't be an integrated project anyway
20:28:40 <ttx> (kite)
20:28:49 <russellb> right
20:28:55 <russellb> and possibly never will be
20:29:09 <russellb> and if that's the case, i don't think nova (or more accurately, oslo.messaging, right?) will use it
20:29:10 <dhellmann> is the purpose of this new repo to preserve the kite code somewhere out of the keystone repo?
20:29:24 <dolphm> dhellmann: that is my immediate goal
20:29:30 <russellb> which i'm certainly disappointed by, we've been talking about this functionality for years
20:29:42 <dhellmann> dolphm: could we just make a branch where we keep it and delete it from master?
20:29:52 <dolphm> dhellmann: i don't want to see it ship as an incomplete implementation of a complete service in keystone.contrib.kds
20:29:59 <dolphm> discrete service*
20:30:07 <dhellmann> dolphm: makes sense
20:30:24 <sdague> so if the code has no actual life, because no one is going to use it, why do we care where it lives?
20:30:30 <russellb> :(
20:30:36 <dhellmann> but do we need a new repo to preserve it, esp. if it's going to merge with barbican soon?
20:30:37 <ttx> so it boils down to: the expectations of durability of a project below openstack/* vs. the expectations of consumability of something under stackforge
20:30:40 <dolphm> dhellmann: the code is written to be ripped out into it's own repo - i'd like to do that sooner before we accidentally make calls across projects and make separation more difficult
20:31:05 <russellb> do we expect this project to apply for incubation?
20:31:06 <sdague> dhellmann: why would we think it would merge into barbican vs. them writing their own version of this which fits better in their project
20:31:13 <russellb> if not, the whole thing is moot, nobody is going to use it
20:31:16 <jeblair> dolphm: is active development going to happen in that repo before it is merged into barbican?
20:31:23 <ttx> russellb: no, unless we reject barbican from incubation next week
20:31:36 <russellb> ok, just wanted to make sure that's clear
20:31:38 <dhellmann> sdague: semantics? If this is going away because of barbican, does it need to live on its own anywhere?
20:31:49 <russellb> this is something we don't expect to ever get used at this point, then :(
20:31:56 <dolphm> jeblair: so far, it only has one contributing developers, and a few of us have been regular reviewers; i don't know if i can predict any change there
20:31:56 <sdague> dhellmann: that's kind of my question
20:32:06 <dhellmann> sdague: ditto
20:32:09 <russellb> sounds like git rm is the answer
20:32:11 <ttx> dhellmann: right. This is a temporary code drop. I don't think we should use the openstack/�* namespoace fopr temporary code drops
20:32:25 <sdague> yeh, I'm headed down the path of git rm
20:32:35 <jraim_> jeblair: I imagine barbican will take the functionality, but not necessarily the code
20:32:35 <markmcclain> +1
20:32:45 <ttx> russellb: i'm fine with stackforge or git rm
20:32:49 <russellb> because barbican has now become the quicker path to getting this functionality into the integrated release
20:32:51 <dhellmann> ttx: I agree, I didn't realize it was gong away that soon
20:32:53 <sdague> jraim_: right, that's what I expected
20:33:42 <sdague> ttx: I think abandonware on stackforge is the wrong answer
20:33:42 <ttx> maybe we should rule on barbican first
20:33:45 <lifeless> back
20:33:55 <russellb> i think we've been pretty positive on barbican so far
20:34:00 <mordred> ++
20:34:01 <russellb> just waiting on final requirements to get met
20:34:15 <ttx> sdague: don't think abandonware. Think temporaryware.
20:34:23 <markmcclain> so can we just park it in an feature branch temporalily?
20:34:33 <sdague> ttx: it's only temporaryware if someone is going to use it
20:34:39 <jraim_> russellb: we should be pretty close, just final tweaks to gate job. I was planning on asking for our final review next week assuming no more speedbumps show up
20:34:47 <mordred> markmcclain: why even bother? it's in the git history already
20:34:52 <ttx> sdague: oh ok, i see your point
20:34:57 <dhellmann> mordred: just ease, but fair point
20:34:58 <sdague> mordred: ++
20:35:01 <russellb> mordred: markmcclain unless they still want to work on it
20:35:06 <dolphm> mordred: there are outstanding patches in review; i'd like to keep them moving
20:35:13 <mordred> ok
20:35:13 <ttx> yes, git rm sounds like the answer here
20:35:16 <sdague> dolphm: but, why?
20:35:23 <dolphm> mordred: i don't want to see the effort die, unless it's being picked up someplace else
20:35:24 <sdague> because I think we just decided it's a dead end
20:35:32 <markmcclain> mordred: good point… I wasn't sure of the state of continuing work on it
20:35:51 <sdague> because it will never be used in anything, so it seems like spending time on it is just a big waste
20:35:57 <jeblair> and jraim_ suggested they might not take the code
20:35:58 <ttx> until barbican picks it up it's good to keep it alive ?
20:36:23 <jraim_> jeblair: not sure either way. There are differences in frameworks, but some code might be usable. I haven't looked at it enough to know yet
20:37:19 <jeblair> it's not a great experience to hack on dead-end code; i think the sooner we can point the devs at where this really should end up, the better.
20:37:35 <sdague> so it really feels like either there is a commitment to get this out there an integrated soon, or we just strategically go in the direction of barbican (assuming all well there)
20:37:38 <sdague> jeblair: ++
20:40:44 <dolphm> sdague: if the feature set is being moved to barbican then that's a viable solution i'm just as happy with
20:40:44 <russellb> ttx: as long as those working on it understand the likely end game ...
20:40:44 <russellb> it's not fair to folks to let them think otherwise
20:40:45 <ttx> they should rather join barbican imho
20:40:45 <dolphm> the service side work has taken place under this bp - https://blueprints.launchpad.net/keystone/+spec/key-distribution-server
20:40:45 <russellb> ttx: +1
20:40:45 <ttx> make sure their concerns are taken into account
20:40:45 <dolphm> there's still a few things in review with recent revisions
20:40:45 <russellb> help work on barbican
20:40:46 <ttx> dolphm: ideally you should rip it off by feature freeze
20:40:46 <dolphm> jeblair: barbican might not take the bulk of the code due to falcon vs pecan/wsme, and probably difference in backend architecture
20:40:46 <dolphm> ttx: +++
20:40:47 <ttx> dolphm: you could use a feature branch,n as long as those working on it know about the future
20:40:49 <ttx> we need to move on
20:40:49 <russellb> which uses falcon?
20:40:49 <dolphm> russellb: barbican
20:40:49 <russellb> sigh ok
20:40:49 <ttx> I think we have general agreement that adding a project is not the way to go
20:40:49 <dolphm> ttx: so, stackforge repo or feature branch?
20:40:49 <ttx> feature branch does not require us approving you :)
20:40:49 <russellb> or git rm, or private github repo, or ... whatever
20:40:49 <ttx> ok, we need to move on
20:40:49 <dolphm> alright - that's good enough for me until after feature freeze :)
20:40:49 <ttx> and we shall have an answer for barbican next week
20:40:49 <ttx> if patches land
20:40:49 <ttx> #topic Integrated projects and new requirements: Neutron
20:40:50 <ttx> #link https://etherpad.openstack.org/p/IcehouseProjectReviewNeutron
20:40:50 <ttx> markmcclain: ready?
20:40:50 <markmcclain> yep
20:40:50 <ttx> step 2 in our "let's apply new rules to old projects"
20:41:06 <ttx> wow lag
20:41:36 <lifeless> do we have any guarantees of durability ?
20:41:36 <lifeless> bah, sorry, reading backlog :)
20:41:48 <russellb> markmcclain: distributed virtual router ... merged?
20:42:16 <markmcclain> no… DVR is likely to merge in Juno
20:42:20 <russellb> OK
20:42:42 <russellb> other big thing is the migration plan
20:42:44 <markmcclain> we will merge several HA features before Icehouse closes
20:42:55 <russellb> folks aren't happy with the "just snapshot to glance and re-deploy" migration option
20:43:10 <russellb> well one of the other big things, there are a few
20:43:23 <markmcclain> yeah… I'm working on finding a resource to see how we can integrate nova-net as a backend in Neutron
20:43:29 <russellb> heh, cool
20:43:41 <russellb> so ... production viable open source plugins
20:43:54 <russellb> seems to be some thought that they may require a rewrite
20:43:58 <jeblair> ttx: is there an etherpad for this?
20:44:07 <russellb> https://etherpad.openstack.org/p/IcehouseProjectReviewNeutron
20:44:31 <markmcclain> The team has spent a lot of time making the current crop of agents more scalable
20:44:54 <russellb> OK ... maybe we can find a way to do some scale / performance testing during juno
20:45:31 <markmcclain> yeah that is on our list
20:45:47 <russellb> ok, cool, i think we really do need some confidence there, using some data
20:46:12 <markmcclain> there will eventually be a point at which we'll point folks towards the open source or proprietary controllers
20:46:14 <russellb> nova + neutron integration code is already in flight it seems, so that's looking promising
20:46:20 <sdague> yeh, agreed. Because it seems like the openvswitch implementation in tree has definitely been a pain point
20:46:47 <jeblair> lifeless: what is tripleo using?
20:46:47 <russellb> right
20:47:08 <lifeless> jeblair: neutron
20:47:16 <jeblair> lifeless: sorry i mean what controller?
20:47:16 <lifeless> jeblair: ml2 + ovs
20:47:22 <sdague> so I guess the other question I have overall is scope. Because it seems like we keep adding *aaS services into neutron, as I keep getting review requests in devstack and neutron for them :)
20:47:28 <russellb> sdague: +1
20:47:36 <sdague> s/neutron/tempest/
20:47:54 <lifeless> jeblair: we're not using a full fledged SDN controller yet. Would love markmcclain to tell me what one Neutron recommends :)
20:47:59 <sdague> so I think neutron is now exceeding nova in number of agents
20:48:08 <markmcclain> sdague: so we're only support 3 adv services right now: Firewall, VPN, and Loadbalancing
20:48:09 <jeblair> k, good so that's a miniature production deployment using an open source crontroller where we as a project will have a lot of visibility
20:48:14 <lifeless> FWIW neutron agents handle outages better than nova's.
20:48:38 <ttx> sdague: difficult to tell, we haven't a mission statement describing scope yet :)
20:48:57 <sdague> jeblair: well, ml2 + ovs isn't really an open source control compared to what you think of as an SDN
20:49:03 <lifeless> exactly
20:49:08 <russellb> markmcclain: do you feel like the punch list for what's blocking deprecation of nova-network is well understood?
20:49:10 <lifeless> (exactly to sdague's comment)
20:49:14 <markmcclain> yeah ml2 is not a full sdn solution
20:49:25 <russellb> i feel like it is, but want to make sure we're on the same page
20:49:44 <lifeless> perhaps there should be a set of bugs
20:49:47 <lifeless> marked with a tag
20:49:51 <ttx> markmcclain: so that's all networky services. Do you foresee any other networky service to be added on top ? QoS ?
20:49:51 <lifeless> so we can burn them down
20:50:07 <markmcclain> lifeless: so beagles has been tracking those items
20:50:29 <markmcclain> created bugs where we didn't have a blueprint covering other work
20:50:42 <sdague> markmcclain: so is there are reason advanced services aren't being done trove style or NFV? I guess that's my long term concern on growth there
20:50:56 <lifeless> markmcclain: is there a single url I can visit that shows the status? E.g. a bug search, or a blueprint search ?
20:51:10 <lifeless> markmcclain: if we have to say 'look in these N places' it becomes massively harder to get folk up to speed
20:51:17 <markmcclain> sdague: yes… some of the advanced services really benefit from direct integration
20:52:21 <russellb> hm, 8 minutes left
20:52:29 <sdague> ok, so I guess in project scope / mission statement that should be indicated somewhere. Because turning on VPNaaS last fall cranked up the failure rate because of the extra load on the backend
20:52:43 <sdague> so there is also a cost of adding more services here as well
20:52:45 <russellb> i guess an important question is, if neutron were applying for graduation today, what would we say?  what feedback would we have?
20:53:02 <markmcclain> lifeless: there was wiki we've tracking most of Icehouse, but I got a report late yesterday that the maintainer wants to redo it again
20:53:11 <markmc> russellb, right
20:53:18 <sdague> I think my big 2 issues would be: 1 - not at parity with testing
20:53:22 <markmc> I think our advice/requirements would mostly be about parity
20:53:27 <sdague> 2 - unclear scope boundary
20:53:31 <markmc> the way we're approaching ironic now
20:53:32 <lifeless> markmcclain: if I can make a suggestion, get a set of bugs together, mark them high, tag them, and get russellb to agree that they are both necessary and sufficient :)
20:53:50 <lifeless> markmcclain: one place, one search, automatically kept up to date as things land.
20:53:58 <markmcclain> sdague: yeah we're working on making the services run within the same agent to reduce the load issue
20:54:05 <markmc> are there lessons learned from nova-network->neutron that we can apply to nova-bm->ironic
20:54:06 <russellb> markmc: agreed
20:54:15 <lifeless> I'd add a 3- vendor participation
20:54:20 <markmc> e.g. no new features, no increase in scope, until you reach parity
20:54:23 <lifeless> from the outside, the core of neutron is very small
20:54:30 <lifeless> for all that the team is big
20:54:31 <markmcclain> lifeless: agreed a few items didn't fit into bugs
20:54:37 <russellb> markmc: yes that, and no calling ironic done/integrated until we get there
20:54:40 <lifeless> markmcclain: use a hammer :P
20:54:51 <markmc> russellb, nod
20:55:10 <markmc> are we saying we wouldn't graduate neutron now?
20:55:12 <ttx> OK, we need to move on to the rest of the agenda. Do you need to continue the discussion on this next week ? Or is the feedback clear enough ?
20:55:18 <markmcclain> lifeless: I'd argue vendor participation is healthy
20:55:19 <russellb> markmc: that's my opinion, i'm afraid
20:55:27 <russellb> ttx: not done IMO
20:55:29 <russellb> but we can finish quick
20:55:30 <markmc> ttx, need to continue - no point in making this review a checkbox
20:55:32 <markmcclain> The deployer side is one that I've been trying to grow more
20:55:40 <russellb> or continue next week
20:55:54 <ttx> I'm fine with continuing next week
20:56:00 <russellb> but basically 1) would we graduate neutron and 2) if not, what timelines / expectations do we have for those expectations to be met now
20:56:12 <ttx> we need to have clear outcomes if the current situation is not satisfactory
20:56:20 <russellb> ok
20:56:37 <ttx> OK, let's table this and continue next week
20:56:39 <lifeless> markmcclain: ok thats great; it just *looked* like many vendors were poking at their driver only.
20:56:41 <sdague> ok
20:56:47 <lifeless> markmcclain: with patches taking months to get reviews
20:56:50 <ttx> since I think that's a very valuable discussion to have
20:56:59 <lifeless> markmcclain: if they were for the core
20:57:01 <sdague> ttx: ++
20:57:12 <ttx> #info to be continued next week
20:57:13 <lifeless> markmcclain: if thats changed, I'm super happy :)
20:57:15 <ttx> #topic Minor governance changes
20:57:19 <markmcclain> lifeless: so of the vendor patches got pushed to back of the queue to focus on testing
20:57:24 <ttx> * Add oslo.test to the Oslo program [https://review.openstack.org/#/c/74117/]
20:57:30 <ttx> I'll approve this one now, enough +1s already
20:57:40 <ttx> * Add Infrastructure Program mission [https://review.openstack.org/#/c/74494/]
20:57:54 <ttx> Since this was previously approved, it's more a housekeeping item, so I can probably approve this one too
20:58:05 <ttx> * Oslo program changes (oslo.vmware addition) [https://review.openstack.org/#/c/74570/]
20:58:15 <ttx> this one needs Doug's approval as Oslo PTL, then unless someone objects and flags it for further discussion I will approve it
20:58:27 <dhellmann> I +1ed it earlier today, I think
20:58:32 <ttx> indeed
20:58:44 <sdague> dhellmann: there still a rename that needs to happen?
20:58:54 <ttx> so unless someone objects I'll approve it tomorrow
20:58:55 <sdague> or just deal with that after
20:59:13 <ttx> #topic Open discussion
20:59:18 <dhellmann> sdague: the oslo.test library is now "oslotest" but I was going to wait until after the feature freeze thaws to mess with the repo name
20:59:22 <ttx> FWIW I reorganized the proposals for the BoD/TC meeting agenda at:
20:59:25 <ttx> https://etherpad.openstack.org/p/juno-tc-board-meeting-ideas
20:59:34 <ttx> I'll synthesize this and work with Alan to see which (and how much) we can fit in two hours
20:59:47 <ttx> Last minute thoughts ?
20:59:58 <mikal> I've tweaked the defcore draft
21:00:03 <jeblair> sdague, ttx we're starting to use the governance repo directly for the ATC scripts, so keeping that yaml file current would be better than having it represent a hopeful future state
21:00:05 <mikal> People should look again
21:00:27 <dhellmann> sdague: I need to chat with you about using d-g for testing oslo.test, see https://review.openstack.org/#/c/74408/
21:00:30 <ttx> jeblair: agreed
21:00:37 <ttx> mikal: thanks
21:00:42 <sdague> dhellman_: sure, to -infra with that
21:00:43 <ttx> and that concludes this meeting
21:00:50 <ttx> #endmeeting