20:01:33 #startmeeting tc 20:01:34 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:39 The meeting name has been set to 'tc' 20:01:39 o/ 20:01:41 So I'm back, yay 20:01:50 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:06 #topic Progress on DefCore feedback 20:02:14 #link https://review.openstack.org/#/c/74483/ 20:02:23 I hope everyone had a chance to catch up with the current draft over the week 20:02:37 So far we had a number of +1s on the review. Comments ? Strong objections ? 20:02:47 I haven't received any negative comments 20:03:05 Counting mikal's implied +1 that makes 8 YES and no objection, so I can approve it after meeting 20:03:18 I'm assuming we'll make a pass for typos and punctuation and stuff before sending it? 20:03:24 i think i agree with just about everything in it 20:03:35 * jgriffith needs a bit more time 20:03:36 dhellmann: comment on errors in gerrit and I will fix 20:03:56 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 dhellmann: Ideally we'd fix typos and punctuation BEFORE writing it as a final resolution 20:04:13 o/ 20:04:26 mikal: do you know when the next DefCore meeting will be ? 20:04:33 Ah! I guess zehicle knows 20:04:36 Heh 20:04:42 ttx: Monday 20:04:42 There's a physical meeting soon 20:04:51 And a VC at a time which doesn't work for me this week IIRC 20:05:02 #link https://etherpad.openstack.org/p/DefCoreElephant.5 20:05:03 I missed last weeks meeting because my day sucked, which I apologise for 20:05:08 mikal: so it would be great to have the final base position approved by then, so that you can represent it 20:05:28 #https://etherpad.openstack.org/p/DefCoreElephant.4 from last time, we try to keep good notes 20:05:35 Oh, there's a remote option now 20:05:36 Cool 20:05:51 or anne may be able to stand in for you 20:06:34 jgriffith: is the "more time" you need measured in minutes or days ? 20:06:45 ttx: I'm done 20:06:54 ttx: waiting for people to throw shoes at me 20:06:54 jgriffith: and what's the verdict ? 20:06:59 I'm a -1 20:06:59 sorry i'm late, my irc bouncer crashed 20:07:04 hah! 20:07:07 Most of it I agree with 20:07:20 but I can't get passed the "black box API" suggestion 20:07:25 "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 jgriffith: reading your comment 20:07:34 jgriffith: we're not saying that black box is _the_ answer 20:07:43 jgriffith: we're saying is the _start_ of an answer 20:07:44 ttx: was nice enough to paste it above :) 20:07:47 jgriffith, the trademark rules already require you to run the code 20:07:51 let's allocate 10 minutes to discuss that, I don't want it to steal all the meeting time 20:07:53 mikal: then it shouldn't be suggested IMO 20:07:58 jgriffith, the requirement is rather vague though 20:08:10 markmc: hey... I'm just one guy, and I get to vote 20:08:19 jgriffith: well, we say its what we think can get done for Icehouse and that we'll iterate 20:08:20 markmc: if I'm crazy so beit :) 20:08:24 jgriffith, of course - I'm just discussing ? 20:08:29 so I share jgriffith's concern FWIW 20:08:33 jgriffith, clarifying ... 20:08:38 markmc: understood sorry 20:08:45 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 lifeless: it's only a first step, if you read the draft 20:09:12 lifeless: as in, better than nothing and maybe doable for icehouse release 20:09:13 ttx: I know 20:09:17 lifeless: that's kinda the way I feel.. the API component is assumed IMO 20:09:18 ttx: I voted +1 on the draft. 20:09:49 API testing is also better than what we have now 20:09:54 Which is mostly a hand wavey promise 20:09:55 I feel I may be worrying about this more than I should 20:09:59 no-one is saying passing API tests is sufficient alone for TM usage 20:10:29 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 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 markmc: fair enough 20:10:43 jgriffith: do you want a response that makes that more explicit? 20:10:49 jgriffith: I do share some of your concern, maybe we can make the wording stronger? 20:10:52 so, out of curiosity, has anyone sniff tested that APIs for the big openstack public clouds 20:10:57 markmc: jeblair yes, explicit is better than implicit IMO 20:11:12 sdague: elephant in the room 20:11:17 sdague: could you consider nodepool to be a simple sniff test? 20:11:20 sdague: o/ :) 20:11:22 sdague: infra uses hp and rax 20:11:24 yeah 20:11:26 what mikal said 20:11:26 ttx: I have to drop out for 10m to drop C off at kindy 20:11:32 lifeless: ack 20:11:39 mordred: yeh, through novaclient, which hides a ton of differences 20:11:40 lifeless: we shall have moved on 20:11:44 hehe. we should just say "if nodepool works, you're openstack" :) 20:11:49 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 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 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 jgriffith: nope to both - just saying, we _do_ use the apis in production across four different openstack versions of cloud successfully 20:12:29 I think maybe if people have concerns big enough to vote -1 they should comment in gerrit so they're tracked 20:12:36 mordred: fair 20:12:43 and what jeblair said 20:12:44 mikal: I did 20:13:01 jgriffith: I know, but others are concerned now too. You've started a thing. 20:13:11 dang me!!! 20:13:23 I don't mind taking some time today to try and address people's concerns 20:13:31 But we should try to not keep defcore people waiting too long 20:13:35 mikal: i still support the draft as written, but would also support adding something that addresses jgriffith's concerns 20:13:42 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 My suggestion would be API compat as a seperate effort/proposal or at least a sub-task 20:13:57 but that it be explicit that that's what it is 20:14:05 mikal: (because i feel it's making something explicit that is currently implicit) 20:14:18 mikal: my concerns were eased by the statement that this is just the start and we already require "all the code" 20:14:22 jgriffith: let's have a chat in PM after the meeting and see if we can nail something down 20:14:32 mikal: sure 20:14:35 mikal: +1 20:14:52 dhellmann: I'm not 100% sure the words are "all the code" or just "the code". 20:14:55 dhellmann: that's a valid point 20:14:58 markmc: ^-- do you know which? 20:15:08 I believe it's "the code" 20:15:10 mikal, digging up a link now 20:15:32 "the code" isn't "some of the code" so isn't it "all the code"? 20:15:34 I can certainly add something saying we believe that statement shouldn't be removed yet 20:15:51 i.e. API tests are not a sufficient replacement 20:15:54 dhellmann: explicit is better than implicit 20:15:54 " 20:15:55 include the entirety of the OpenStack [..] code from either of the latest 20:15:55 two releases and associated milestones, but no older, and 20:15:56 " 20:16:02 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 :) 20:16:16 "entirety" sounds like "all" 20:16:16 * annegentle_web slides into the back of the room 20:16:32 jbryce quoted here: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026559.html 20:16:43 OK, time is up. Let's continue iterating on the draft, with the Monday deadline in mind 20:16:52 and move on 20:16:56 ++ 20:16:57 Cool 20:17:05 #topic Creating key distribution service (KDS) under identity program 20:17:12 #link https://review.openstack.org/#/c/73022/ 20:17:20 So... As I mentioned in http://lists.openstack.org/pipermail/openstack-tc/2014-February/000540.html ... 20:17:34 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 And obviously if the project files for incubation, it needs to go through our regular procedure (incubation request) 20:18:06 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 The other is about the project addition itself, which I flagged for discussion and put on the agenda 20:18:45 My question is, how this would be affected long-term by Barbican, which also promises to "distribute keys" ? 20:18:58 dolphm: you around ? 20:19:05 jraim_ too 20:19:11 ttx: I'm here 20:19:13 ttx: o/ 20:19:44 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 ttx: exactly - when/whether it's integrated isn't my immediate concern at all 20:20:42 dolphm: ok, good 20:20:43 i really just want to ensure that the code has a proper place to live next week (outside of keystone) 20:21:06 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 I'd like for DefCore to take up answering these questions at the meeting on Monday 20:21:23 ttx: correct 20:21:37 zehicle_at_dell: the questions in the draft response? 20:21:42 zehicle: maybe follow the draft review on https://review.openstack.org/#/c/74483/ 20:21:49 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 russellb & ttx, ok thanks 20:22:05 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 This could live in stackforge with a specific set of core devs 20:22:29 stackforge/ is absolutely fine with me 20:22:32 especially if we approve barbican soon 20:22:37 what's the relationship between this code and barbican? are they separate implementations of the same feature? 20:23:28 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 I understand the need for that code to live somewhere, in a somewhere that is not Keystone icehouse release 20:23:39 but if we're approving barbican soon (seems likely), it's making less and less sense i think ... 20:23:46 barbican doesn't support what this does, though 20:23:48 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 dhellmann: today, they don't overlap 20:24:04 ok 20:24:05 russellb: that's why if tha code needs to live somewhere, I'd rather have it in stackforge 20:24:11 to be contrary 20:24:22 but nova can't really use it unless it's an official project IMO 20:24:25 so we're no better off 20:24:31 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 dhellmann, and it wasn't clear when they would overlap. 20:24:42 dolphm: do you feel that people doing work on this are doing work that's part of the openstack identity program? 20:25:05 mordred: they are looking like a separate group of people to me 20:25:06 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 does that mean we are waiting for secure messaging until barbican is an integrated project? 20:25:20 dhellmann: that's what I was getting at 20:25:24 dhellmann: it's the fact that we all think it will have to be removed in 6 months 20:25:29 sdague: that's what we were originally hoping to avoid ... 20:25:35 ttx: why do we think that? 20:25:47 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 dhellmann: because it's overlapping with Barbican goals 20:25:52 ttx: I heard "on barbican's long-term roadmap" 20:25:56 ttx: I did not hear 6 months 20:26:03 mordred: I heard "in Juno" 20:26:11 "it seems like we could subsume it into barbican for juno" 20:26:26 ttx: sure, but that doesn't help nova 20:26:31 mordred: there's not substantial contributions from the existing keystone community 20:26:32 * markmc has to drop off 20:26:37 kk 20:26:47 I mean, if it's meant to live for a few cycles, then I agree to have it in openstack/kite 20:26:48 sdague: is nova going to use a non-integrated project from keystone? 20:26:55 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 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 dhellmann: well that's the other open question 20:27:05 but if everyone wants it to die after icehouse, then it feels a bit weird 20:27:05 dhellmann: sdague no... 20:27:12 and the answer should be no 20:27:13 russellb: right, that's what I thought 20:27:15 like russellb said 20:27:19 +1 20:27:51 morganfainberg: I would not be asking this question if we weren't considerign barbican for incubation 20:28:01 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 that changed the rules a bit 20:28:09 ttx, makes perfect sense. 20:28:18 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 IMO, anyway 20:28:35 russellb: it won't be an integrated project anyway 20:28:40 (kite) 20:28:49 right 20:28:55 and possibly never will be 20:29:09 and if that's the case, i don't think nova (or more accurately, oslo.messaging, right?) will use it 20:29:10 is the purpose of this new repo to preserve the kite code somewhere out of the keystone repo? 20:29:24 dhellmann: that is my immediate goal 20:29:30 which i'm certainly disappointed by, we've been talking about this functionality for years 20:29:42 dolphm: could we just make a branch where we keep it and delete it from master? 20:29:52 dhellmann: i don't want to see it ship as an incomplete implementation of a complete service in keystone.contrib.kds 20:29:59 discrete service* 20:30:07 dolphm: makes sense 20:30:24 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 :( 20:30:36 but do we need a new repo to preserve it, esp. if it's going to merge with barbican soon? 20:30:37 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 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 do we expect this project to apply for incubation? 20:31:06 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 if not, the whole thing is moot, nobody is going to use it 20:31:16 dolphm: is active development going to happen in that repo before it is merged into barbican? 20:31:23 russellb: no, unless we reject barbican from incubation next week 20:31:36 ok, just wanted to make sure that's clear 20:31:38 sdague: semantics? If this is going away because of barbican, does it need to live on its own anywhere? 20:31:49 this is something we don't expect to ever get used at this point, then :( 20:31:56 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 dhellmann: that's kind of my question 20:32:06 sdague: ditto 20:32:09 sounds like git rm is the answer 20:32:11 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 yeh, I'm headed down the path of git rm 20:32:35 jeblair: I imagine barbican will take the functionality, but not necessarily the code 20:32:35 +1 20:32:45 russellb: i'm fine with stackforge or git rm 20:32:49 because barbican has now become the quicker path to getting this functionality into the integrated release 20:32:51 ttx: I agree, I didn't realize it was gong away that soon 20:32:53 jraim_: right, that's what I expected 20:33:42 ttx: I think abandonware on stackforge is the wrong answer 20:33:42 maybe we should rule on barbican first 20:33:45 back 20:33:55 i think we've been pretty positive on barbican so far 20:34:00 ++ 20:34:01 just waiting on final requirements to get met 20:34:15 sdague: don't think abandonware. Think temporaryware. 20:34:23 so can we just park it in an feature branch temporalily? 20:34:33 ttx: it's only temporaryware if someone is going to use it 20:34:39 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 markmcclain: why even bother? it's in the git history already 20:34:52 sdague: oh ok, i see your point 20:34:57 mordred: just ease, but fair point 20:34:58 mordred: ++ 20:35:01 mordred: markmcclain unless they still want to work on it 20:35:06 mordred: there are outstanding patches in review; i'd like to keep them moving 20:35:13 ok 20:35:13 yes, git rm sounds like the answer here 20:35:16 dolphm: but, why? 20:35:23 mordred: i don't want to see the effort die, unless it's being picked up someplace else 20:35:24 because I think we just decided it's a dead end 20:35:32 mordred: good point… I wasn't sure of the state of continuing work on it 20:35:51 because it will never be used in anything, so it seems like spending time on it is just a big waste 20:35:57 and jraim_ suggested they might not take the code 20:35:58 until barbican picks it up it's good to keep it alive ? 20:36:23 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 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 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 jeblair: ++ 20:40:44 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 ttx: as long as those working on it understand the likely end game ... 20:40:44 it's not fair to folks to let them think otherwise 20:40:45 they should rather join barbican imho 20:40:45 the service side work has taken place under this bp - https://blueprints.launchpad.net/keystone/+spec/key-distribution-server 20:40:45 ttx: +1 20:40:45 make sure their concerns are taken into account 20:40:45 there's still a few things in review with recent revisions 20:40:45 help work on barbican 20:40:46 dolphm: ideally you should rip it off by feature freeze 20:40:46 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 ttx: +++ 20:40:47 dolphm: you could use a feature branch,n as long as those working on it know about the future 20:40:49 we need to move on 20:40:49 which uses falcon? 20:40:49 russellb: barbican 20:40:49 sigh ok 20:40:49 I think we have general agreement that adding a project is not the way to go 20:40:49 ttx: so, stackforge repo or feature branch? 20:40:49 feature branch does not require us approving you :) 20:40:49 or git rm, or private github repo, or ... whatever 20:40:49 ok, we need to move on 20:40:49 alright - that's good enough for me until after feature freeze :) 20:40:49 and we shall have an answer for barbican next week 20:40:49 if patches land 20:40:49 #topic Integrated projects and new requirements: Neutron 20:40:50 #link https://etherpad.openstack.org/p/IcehouseProjectReviewNeutron 20:40:50 markmcclain: ready? 20:40:50 yep 20:40:50 step 2 in our "let's apply new rules to old projects" 20:41:06 wow lag 20:41:36 do we have any guarantees of durability ? 20:41:36 bah, sorry, reading backlog :) 20:41:48 markmcclain: distributed virtual router ... merged? 20:42:16 no… DVR is likely to merge in Juno 20:42:20 OK 20:42:42 other big thing is the migration plan 20:42:44 we will merge several HA features before Icehouse closes 20:42:55 folks aren't happy with the "just snapshot to glance and re-deploy" migration option 20:43:10 well one of the other big things, there are a few 20:43:23 yeah… I'm working on finding a resource to see how we can integrate nova-net as a backend in Neutron 20:43:29 heh, cool 20:43:41 so ... production viable open source plugins 20:43:54 seems to be some thought that they may require a rewrite 20:43:58 ttx: is there an etherpad for this? 20:44:07 https://etherpad.openstack.org/p/IcehouseProjectReviewNeutron 20:44:31 The team has spent a lot of time making the current crop of agents more scalable 20:44:54 OK ... maybe we can find a way to do some scale / performance testing during juno 20:45:31 yeah that is on our list 20:45:47 ok, cool, i think we really do need some confidence there, using some data 20:46:12 there will eventually be a point at which we'll point folks towards the open source or proprietary controllers 20:46:14 nova + neutron integration code is already in flight it seems, so that's looking promising 20:46:20 yeh, agreed. Because it seems like the openvswitch implementation in tree has definitely been a pain point 20:46:47 lifeless: what is tripleo using? 20:46:47 right 20:47:08 jeblair: neutron 20:47:16 lifeless: sorry i mean what controller? 20:47:16 jeblair: ml2 + ovs 20:47:22 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 sdague: +1 20:47:36 s/neutron/tempest/ 20:47:54 jeblair: we're not using a full fledged SDN controller yet. Would love markmcclain to tell me what one Neutron recommends :) 20:47:59 so I think neutron is now exceeding nova in number of agents 20:48:08 sdague: so we're only support 3 adv services right now: Firewall, VPN, and Loadbalancing 20:48:09 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 FWIW neutron agents handle outages better than nova's. 20:48:38 sdague: difficult to tell, we haven't a mission statement describing scope yet :) 20:48:57 jeblair: well, ml2 + ovs isn't really an open source control compared to what you think of as an SDN 20:49:03 exactly 20:49:08 markmcclain: do you feel like the punch list for what's blocking deprecation of nova-network is well understood? 20:49:10 (exactly to sdague's comment) 20:49:14 yeah ml2 is not a full sdn solution 20:49:25 i feel like it is, but want to make sure we're on the same page 20:49:44 perhaps there should be a set of bugs 20:49:47 marked with a tag 20:49:51 markmcclain: so that's all networky services. Do you foresee any other networky service to be added on top ? QoS ? 20:49:51 so we can burn them down 20:50:07 lifeless: so beagles has been tracking those items 20:50:29 created bugs where we didn't have a blueprint covering other work 20:50:42 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 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 markmcclain: if we have to say 'look in these N places' it becomes massively harder to get folk up to speed 20:51:17 sdague: yes… some of the advanced services really benefit from direct integration 20:52:21 hm, 8 minutes left 20:52:29 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 so there is also a cost of adding more services here as well 20:52:45 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 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 russellb, right 20:53:18 I think my big 2 issues would be: 1 - not at parity with testing 20:53:22 I think our advice/requirements would mostly be about parity 20:53:27 2 - unclear scope boundary 20:53:31 the way we're approaching ironic now 20:53:32 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 markmcclain: one place, one search, automatically kept up to date as things land. 20:53:58 sdague: yeah we're working on making the services run within the same agent to reduce the load issue 20:54:05 are there lessons learned from nova-network->neutron that we can apply to nova-bm->ironic 20:54:06 markmc: agreed 20:54:15 I'd add a 3- vendor participation 20:54:20 e.g. no new features, no increase in scope, until you reach parity 20:54:23 from the outside, the core of neutron is very small 20:54:30 for all that the team is big 20:54:31 lifeless: agreed a few items didn't fit into bugs 20:54:37 markmc: yes that, and no calling ironic done/integrated until we get there 20:54:40 markmcclain: use a hammer :P 20:54:51 russellb, nod 20:55:10 are we saying we wouldn't graduate neutron now? 20:55:12 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 lifeless: I'd argue vendor participation is healthy 20:55:19 markmc: that's my opinion, i'm afraid 20:55:27 ttx: not done IMO 20:55:29 but we can finish quick 20:55:30 ttx, need to continue - no point in making this review a checkbox 20:55:32 The deployer side is one that I've been trying to grow more 20:55:40 or continue next week 20:55:54 I'm fine with continuing next week 20:56:00 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 we need to have clear outcomes if the current situation is not satisfactory 20:56:20 ok 20:56:37 OK, let's table this and continue next week 20:56:39 markmcclain: ok thats great; it just *looked* like many vendors were poking at their driver only. 20:56:41 ok 20:56:47 markmcclain: with patches taking months to get reviews 20:56:50 since I think that's a very valuable discussion to have 20:56:59 markmcclain: if they were for the core 20:57:01 ttx: ++ 20:57:12 #info to be continued next week 20:57:13 markmcclain: if thats changed, I'm super happy :) 20:57:15 #topic Minor governance changes 20:57:19 lifeless: so of the vendor patches got pushed to back of the queue to focus on testing 20:57:24 * Add oslo.test to the Oslo program [https://review.openstack.org/#/c/74117/] 20:57:30 I'll approve this one now, enough +1s already 20:57:40