20:01:33 #startmeeting tc 20:01:34 Meeting started Tue Aug 30 20:01:33 2016 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:37 The meeting name has been set to 'tc' 20:01:42 Welcome back everyone... Our agenda for today: 20:01:47 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:51 o/ 20:01:55 (remember to use #info #idea and #link liberally to make for a more readable summary) 20:02:04 #topic Extra ATCs 20:02:10 We have two late requests for addition of extra-ATCs 20:02:20 I'm saying late because we are now past the deadline described at 20:02:24 #link https://releases.openstack.org/newton/schedule.html#n-extra-atcs 20:02:34 The first one was submitted in time, we just didn't process it last week since there was a meeting skip 20:02:38 * amrith sneaks into the back rows 20:02:44 seems reasonable to allow 20:02:49 That is "Adds winstackers extra ATCs list" (https://review.openstack.org/355872) 20:03:03 The second one was submitted a bit late but we could give it an exception I guess, since it's our first time doing this 20:03:15 The too late one being "Add Bryan Sullivan as extra-ATC for Congress" (https://review.openstack.org/358762) 20:03:24 * flaper87 is good with giving it an exception 20:03:33 wfm 20:03:36 I'm approving the first one 20:03:45 \o/ 20:03:52 ++ on the second 20:03:53 does approving these mean they would apply to the upcoming elections? 20:04:06 I'm OK with it either way, I'm just asking to clarify 20:04:10 I'm +1 on the Congress exception too, just we close the bar now 20:04:14 dhellmann: yes 20:04:18 ok 20:04:27 cool 20:04:29 yeh, I think it's fine. 20:04:32 We haven't tagged the repo for elections yet 20:04:34 and yes, I agree with saying we're closing this for this cycle 20:04:40 o/ 20:04:46 oh yeah should we ask the election officials if they're ok with this addition? 20:04:55 #agreed Those were the last extra-ATC requests for this cycle 20:05:00 +1 from me 20:05:12 annegentle: they close the list much later usually so they should be ok 20:05:12 tonyb : thanks 20:05:21 tonyb thanks for taht 20:05:23 they'll also get summit registration discount codes when i send the final batch next week (assuming they're not already contributors to another official project team) 20:05:23 that even 20:05:26 +1 to close the door with these 20:05:37 fungi ok, good to know 20:05:38 ok, Bryan approved too 20:05:39 fungi : ah, ok, good 20:05:41 fungi : thanks 20:05:54 ok, moving on 20:06:01 #topic Update Glance mission statement 20:06:06 #link https://review.openstack.org/354053 20:06:16 This update is to reflect the long-term focus of Glance in light of the upcoming Glare split 20:06:22 Which should happen during Ocata 20:06:36 Looks like the current proposed version is consensual amongst Glance devs 20:06:46 ++ 20:06:55 Sounds reasonable and it reflects the direction the team is going 20:07:14 yep, I'm fine adjusting it even if Glare is not separated out yet 20:07:17 very good sign that there are no -1's 20:07:32 approving now unless there is a last-minute objection 20:07:40 let's do it 20:07:44 done 20:07:51 sounds good 20:07:56 next topic! 20:07:58 #topic Add the newly-created Requirements team to projects.yaml 20:08:04 #link https://review.openstack.org/358380 20:08:14 This is the last split from the original release management team (after VMT and stable branch maintenance) 20:08:30 \o/ 20:08:32 My only gripe would be that the mission is not mentioning dependency convergence, but that's not enough to block it. 20:08:48 reading mtreinish recent comments though 20:08:56 ttx: Yeah the mission statement is weak but I'm happy to fix that 20:09:06 ttx: oh, annegentle and I were just talking about adding a check job to run the validate tox job 20:09:08 yeah, I'd like to fix that in a separate patch if we can 20:09:14 ttx: https://review.openstack.org/#/c/363165/2 20:09:33 unrelated to the review really 20:09:55 tonyb: ok, I'll propose the adjustment in a subsequent patch 20:09:55 yeah more of a process / expectation question but thanks 20:10:20 #action ttx to suggest dependency convergence as part of requirements mission as a separate patch 20:10:34 OK, let's approve this one then 20:10:55 Thank! 20:10:58 The important bit is to get the team up there 20:11:00 approved 20:11:14 tonyb: I wonder how many ptl hats you can collect for barcelona 20:11:17 OK, now for more interesting discussions 20:11:27 #topic New Storlets project team 20:11:28 mtreinish: ;P 20:11:36 yay welcome to requirements team! 20:11:42 ttx: tonyb and I may need to talk with you about summit space if you haven't already allotted some for the new team 20:11:50 I'd like to timebox that one to the next 25 min (up until :35) 20:12:03 dhellmann: I think I included Tony in the list 20:12:08 ttx: ok, cool 20:12:12 dhellmann: sure. 20:12:20 Let's say I'm "forward-looking" rather than "cheating"' 20:12:23 dhellmann: I've sumitted for stable and requirements 20:12:32 So.. Storlets 20:12:36 #link https://review.openstack.org/353693 20:12:37 tonyb : ok, good, I wanted to make sure you got some for requirements 20:12:44 OK, round 2 of discussion on this one, since last meeting we could only spend 10 minutes on it 20:13:02 Let me try to summarize the objections/comments so far, and then we can have a discussion about the specifics 20:13:03 I'd like to hear from some of the folks who had time to look at the storlets code since I didn't and there were comments on the review about organization and such 20:13:12 1. Use of Java and C code 20:13:17 o/ 20:13:20 Usage of Java seems limited to glue code to make user-side containerized Java payloads work 20:13:21 * flaper87 stfu and lets ttx talk 20:13:33 I'm fine with that especially since there are plans to add support for user-side Python/XXX payloads 20:13:42 ttx: that was not my understanding 20:13:52 Usage of C code seems to be limited to ~800sloc to work around limitations to pass FDs to Java in the container -- long-term would be great to find a way around that 20:14:04 There is also a simple tool to run within the container, which could be using shell instead (restart_docker_container.c) 20:14:14 flaper87: what was your understanding ? 20:14:16 my understanding was that storelets are currently written in Java and that's what is executed 20:14:20 in a python sense that C code sounds a bit like privsep? 20:14:34 flaper87: well, a "storlet" is the user-side code 20:14:37 right, it runs java code, I think 20:14:46 I think I asked this in the review. I wonder if there will be storelets written in some other language 20:14:54 ttx: oh you said glue code and I thought about something else 20:15:01 It is a Python pipeline creating a container that runs code. Currently Java code 20:15:03 We are currently working on Pytrhob 20:15:03 it's the actual code that users will write 20:15:15 the data processing world is very java/scala centric, so it doesn't surprise me they started there 20:15:24 johnthetubaguy: ++ 20:15:30 Let me finish the writeup 20:15:30 johnthetubaguy: you got us :-) 20:15:38 2. Java as a dependency 20:15:53 The main issue with Java as a dependency is that in some cases that means effectively depending on non-free Oracle SDK, since OpenJDK is, let's say... less tested and people are encouraged to run Oracle JDK to avoid corner oddities 20:15:54 johnthetubaguy: not saying it's bad 20:15:56 fwiw 20:16:05 In this precise scenario though I feel like it's only used for user-side payloads, so it's slightly less of a problem 20:16:20 But still, to avoid questions and legal redistribution troubles I think we need to clearly depend on OpenJDK rather than "a Java runtime" 20:16:32 ++ 20:16:37 3. Unlogged meetings, single-core approvals 20:16:41 ++ ttx 20:16:47 Those are pretty common in not-yet-official projects, and could be fixed post-approval 20:16:55 4. Java-centric code organization and build system 20:17:06 I posted this one on the review today -- browsing the source code for storlets feels like walking on an alien planet. 20:17:09 Can users only run Java? Or is this a "serverless" solution where compute processes could run as if SSHing in? 20:17:15 ttx: in the past we've asked to see some period of time with logged meetings before approving 20:17:16 It really feels like Python code bolted on a Java project rather than the other way around 20:17:24 dhellmann: ++ 20:17:32 fwiw, we already leverage openjsk in some infra jobs (and for some infra services) so it should be straightforward from a ci perspective 20:17:33 dhellmann: yeah 20:17:37 er, openjdk 20:17:38 dhellmann: yeah, which is why I raised it as an objection 20:17:48 ok, you said it could be fixed after 20:17:54 Given that the project should be open to other type of user-side workloads (including Python) I think the project should rather be Python with Java code bolted on top 20:18:05 dhellmann: my personal view on it, but yes, it adds up 20:18:09 That would make it more familiar for existing OpenStack developers and make it more like other OpenStack projects 20:18:20 Which brings us to the last objection 20:18:26 5. Timing of the proposal 20:18:39 Overall it feels a bit early for this to be included as an OpenStack project. There seems to be a bit of code organization refactoring, documentation to do (like the README still containing boilerplate), also QA integration... 20:18:50 ++ 20:18:51 So it feels more like Ocata material than Newton, and I would rather delay this inclusion while we iron out those details, rather than fast-track it. 20:19:04 Also adding new projects at this stage of the cycle is slightly suboptimal (too late for release inclusion, bit late for ATC codes, too late to be included in Design Summit...) 20:19:17 right 20:19:19 Any other objection that I failed to capture ? Any comment on those objections ? 20:19:30 ttx: I think that's a good summary, and a good plan of action 20:19:36 I don't think any of the issues are insurmountable 20:19:41 Have they talked about the general security issue of running user code on servers? 20:19:52 Not sure if you mentioned the coding style but I did bring it up in the review 20:19:55 I like the plan of actions 20:19:58 and given the release timing, given them some time to deal with it and then return after the summit sounds perfectly reasonable 20:20:02 dtroyer: meh, it's containers all the security you need :) 20:20:18 Ideally we would have someone from the TC signing up to help them in the coming month(s) so that they can apply again at the start of Ocata 20:20:32 mtreinish : LOL 20:20:36 but I'll admit my dance pad is full 20:20:41 good outline thanks ttx anyone here from storelets? 20:20:50 annegentle: eranrom is here 20:20:52 ttx: I can help 20:20:55 eranrom: ^ 20:21:04 flaper87: ttx: Thanks! 20:21:07 flaper87: nice 20:21:28 #agreed flaper87 can mentor the storlets team for early addition in Ocata 20:21:54 flaper87 : nice of you! 20:21:56 Quick question: Could we still hold a (mini) design summit in Barcelona? 20:21:57 eranrom: none of those objections are insurmontable like mordred says. Just a bit of cleanup and process to follow and reapply when it's better time to do so 20:22:01 * flaper87 agrees with what's been agreed 20:22:19 ttx: Sure, thanks for the summary. We are on it 20:22:32 eranrom: we usually reach out to teams that have proposed recntlky to offer some space when there is space left (there usually is) 20:22:41 * flaper87 adds insurmontable to his dictionary 20:23:06 ttx: alright, thanks 20:23:13 eranrom: I'll be in touch in the coming weeks 20:23:18 eranrom: ditto 20:23:25 eranrom: do the objections all make sense ? 20:23:31 flaper87: you should probably add "insurmountable" too :) 20:23:37 ttx: Absolutley 20:23:43 (I bet flaper87 will help further explaining anyway 20:24:17 edleafe: jeeez, I knew I should have trusted the red line under insurmontable 20:24:22 eranrom so is the idea to enable more end-user language options? 20:24:45 yes, we are very actively working on Python now 20:24:48 It feels like it could support Go with minimal effort, and Python 20:25:03 eranrom great, thanks 20:25:25 ttx: correct 20:25:57 I added something about privsep vs that C code 20:26:01 OK, if no more questions, we can move to next topic 20:26:06 its not a blocker, I am just curious what the difference is 20:26:24 but we can move on, we can talk about that in the review 20:26:32 johnthetubaguy: I think it's passing logging FDs around and expose them within the jvm, but I read quickly 20:26:56 johnthetubaguy: pardon my ignorance privsep? we can discuss offline though 20:27:26 eranrom : http://docs.openstack.org/developer/oslo.privsep/ 20:27:40 what dhellmann said^ 20:27:57 eranrom : also http://docs.openstack.org/developer/oslo.rootwrap/ which is the older lib, but may fit your use case better 20:27:58 it might do what you need for those docker operations (it might not, but I was just curious really) 20:28:12 sure, will have a look thanks! 20:28:14 yeah, let's discuss that offline 20:28:18 +1 20:28:20 MOving on 20:28:22 ++ 20:28:24 #topic Goals 20:28:34 We have a number of reviews that iterate on the stuff we merged last meeting 20:28:42 First one expands the goal template with a section to reflect current state: 20:28:46 #link https://review.openstack.org/356674 20:28:54 Looks like a good idea that we can merge now 20:28:59 this was sdague's idea, for the record 20:29:14 sounds good to me 20:29:19 Objections ? 20:30:09 (change also applies said extra section to the already-approved copypaste-removal goal) 20:30:36 we're not gonna make extra whitespace removal a requirement? I kid. 20:30:37 Alright, approving now 20:31:12 Second one is a bit of clean up following last meeting, adding reference to goals/ and the house rule to fast-track PTL responses to the goals 20:31:19 #link https://review.openstack.org/356699 20:31:35 * ttx reads most recent patchset 20:31:48 thanks to annegentle for pointing out some clumsy wording there 20:32:20 Thanks annegentle -- when I don't parse a sentence I assume it's because I'm bad at English 20:32:26 yes, much clearer, thanks 20:32:43 piling up +1s 20:32:56 I'm bad at parsing usually 20:33:29 5 and counting 20:33:32 * dhellmann has a bad tendency toward complex sentence structure 20:33:53 dhellmann: I don't not have similar issues 20:33:59 hey, at least you're using genderless pronouns :) 20:34:03 mordred : don't be so negative ;-) 20:34:24 Alright, another winner 20:34:27 dhellmann: negative is the new positive 20:34:34 Third one is an incremental improvement on the goals document wording: 20:34:38 #link https://review.openstack.org/356156 20:35:12 There was an objection (from dhellmann and me) on the analyze part 20:35:24 + a minor wording suggestion 20:35:42 If those are the only objections, maybe do a quick new patchset ? 20:35:54 ++ 20:35:54 ++ 20:36:01 * flaper87 is ready to vote as soon as the new ps is up 20:36:18 In the mean time we can discuss the last part 20:36:21 agree on new ps 20:36:34 annegentle: are you on a ps-regeneration-friendly setting ? 20:36:42 in* 20:36:53 a.k.a. not on your phone 20:36:56 yeah 20:37:09 Do you agree with the proposed tweaks ? 20:37:15 * annegentle is never on a phone for irc 20:37:22 never say never 20:37:27 oh yes. I can change 20:37:42 OK, let's discuss py35 again in the mean time 20:38:01 So... last is the Python 3.5 support goal, which we left over last meeting to have more discussion on it: 20:38:06 #link https://review.openstack.org/349069 20:38:45 I commented earlier today that as it stood the goal was slightly suboptimal, since it was a bit too asymmetric 20:39:01 with two teams already expected to miss it 20:39:16 I think this will not be the last time we come across a goal like that, which would otherwise be an easy decision 20:39:35 or folks would have already done it :) 20:39:39 I still would very much like some py35 progress as a goal in Ocata though 20:40:04 dhellmann suggested making unit tests optional in the goal 20:40:07 I think we can take 3 approaches here. 20:40:15 * flaper87 reads carefully 20:40:28 1. we can say up front that some projects aren't likely to finish their unit tests, and leave those as exceptions 20:40:37 yeh, honestly, I think that from a global perspective, if you want a real move forward on python 3 support, we should only talk about full stack testing 20:40:46 2. we can make unit tests entirely optional, which would maybe mean fewer projects actually update them than could 20:40:52 3. we can remove all mention of unit tests for now 20:41:06 or 4. we can pick an completely-different goal entirely 20:41:13 sure, or 4 20:41:24 I think that if the goals are layed out as are in that document, what you will actually get is folks focussing on unit / functional side 20:41:30 I'm 2 3 4 1 20:41:32 and skipping the full stack, because it's harder 20:41:46 but if it's just full stack, you'll get more real progress in 3.5 support 20:41:46 yeah, even for a project as limited in scope as bindep, it took me enlisting someone to spend a fair amount of time to migrate from mox to mock so we could get py3k unit testing out of teh way 20:42:07 sdague : I suppose that depends on the test coverage from any given layer of tests, which is why I included all 3 to start 20:42:17 it's not just about coverage 20:42:20 I'm pro-4, but I couldn't come up with a solid new goal. 20:42:30 it's about what things look like when they are actually running, multi process 20:42:43 You know I was thinking of an API reference consistency goal, but it doesn't compare/replace py3.5 20:42:52 so, yeah, didn't propose 20:42:52 sdague: do you think we could build a goal that would be "complete-able" and would advance full stack testing in for Ocata 20:43:18 Let's also keep in mind Ocata is a shorter cycle 20:43:18 ? 20:43:19 ttx: probably, though until we're in freeze it's hard to think about 20:43:29 I'm pro 2 3 4 1 too 20:43:31 your brain froze too sdague ? :) 20:43:46 well, my brain is focussed on ensuring the placement api is ready to go 20:43:52 Shall we defer picking the second goal to post-FF ? 20:44:00 ttx hm... 20:44:08 worth noting, that's really only applicable to stuff that's integration tested under devstack or has functional testing, right? there are a lot of "outside the stack" projects maintained by various teams 20:44:14 is there a list of candidate 2nd goals anyone else has? 20:44:45 sdague: +1 all your comments here, it feels like more focus on full stack would be better, but I am unsure how possible that is right now 20:45:07 annegentle : https://etherpad.openstack.org/p/ocata-tc-goals 20:45:16 dhellmann perfect thanks 20:45:36 I would still like to see progress on the py3.5 work for ocata, tbh. If having it as a goal, even with optional bits, helps then I'm good with that 20:45:39 johnthetubaguy: right, honestly that ends up being something where what you really need is a couple of people to try the world, see what works, fall back, start filing bugs 20:45:58 sdague: yeah +1 20:45:59 johnthetubaguy: I actually think that it would be easier than doing mox->mock in nova 20:46:00 annegentle : that said, I am strongly opposed to delaying work on the python 3 port any further. 20:46:13 mtreinish: yeah, I totally think it is 20:46:13 dhellmann: ++ 20:46:18 dhellmann yeah 20:46:20 even if we reduce the scope of this goal, I think it's extremely important for us to start pushing 20:46:25 dhellmann: exactly 20:46:39 this isn't going to be the last time that we have a goal that some projects can't finish in one cycle. requiring that all projects finish the goal in 1 cycle limits the number of projects that would be candidate for these kinds of goals. Doesn't it make sense to stick with the goal with the known set of exceptions going in, with the understanding that those projects have one more cycle (and the goals from that cycle?) 20:46:41 dhellmann: right, I agree with you. I'm suggesting an approach that I think will move us further along 20:46:43 afaik, there are no other goals for which we have an external deadline 20:46:44 I would still like to see progress on the py3.5 work for ocata, tbh. If having it as a goal, even with optional bits, helps then I'm good with that 20:46:45 dhellmann : keep unit/functional and drop integration for ocata? 20:46:57 dims: no 20:47:03 sdague : yeah, I would rather focus on that than changing to a different goal 20:47:07 (FTR annegentle's new patchset is up at https://review.openstack.org/#/c/356156, please vote) 20:47:11 how about disabling all mock-using nova unit tests (and any others that spontaneously break) when tested under python 3.5? curious how involved that would be 20:47:16 dims: that's actually pretty much pointless I think 20:47:23 really, we're at this tipping point 20:47:49 2 people and 4 weeks would probably get 1/2 the iaas projects over to a python 3 gate 20:48:00 for devstack 20:48:06 which would then allow readding tests under the 3.5 job as they're updated to work there 20:48:16 (provided sufficient core reviewers...yes) 20:48:20 and have a work list that shows the path forward 20:48:43 but, this isn't going to be a thing we can push out just to all the teams and assume that scatter gather works I don't think 20:48:59 I expect this only works with 1 or 2 drivers that are handling this globally as well 20:48:59 fungi: that's what the jobs do now iirc (they use a blacklist on py3) 20:49:17 its more a central team that will create a bunch of work folks need to jump on, I guess? 20:49:40 johnthetubaguy : no, I don't want anyone to assume that there is a team of folks standing by to submit these patches 20:49:43 johnthetubaguy: and shake out all the gate / devstack / tempest issues that I'm sure are there 20:50:21 dhellmann: agreed we can't assume they are there, its just where the work will flow from (I need a better word than flow...) 20:50:24 OK, so it feels like we need to continue the discussion on this one and we won't solve it in the coming 5 minutes 20:50:25 so we pick say a test (devstack+tempest) and say we should be able to run various things with a blacklist if needed 20:50:45 Should we have at thread ? Just wait post-FF so that people have more bandwidth ? 20:51:04 a* 20:51:08 we sorta need to just try out goals and learn from them. 20:51:15 ttx: sure. Though in my mind, I think we still need to understand if there will be global drivers for an activity like this 20:51:21 ++ttx (post-FF) 20:51:25 because I actually don't think we'll make progress without that 20:51:31 so maybe sticking with py35, documenting expectations, then having a post-mortem discussion helps the most 20:51:35 and it's not super clear that's part of this process 20:51:36 sdague : i agree 20:51:49 that's where I'm having difficulty reconciling 20:52:04 sdague you're likely correct (and steeped in experience) 20:52:21 kudos to haypo and others who brought us this far in python3 20:52:25 because I think the folks pushing python3 thus far, are actually quite disconnected from full stack testing 20:52:26 feels like the full stack bit is the most important bit, and there is a big natural bottleneck in the middle 20:52:30 ok, let's discuss it again next week. Please vote on https://review.openstack.org/#/c/356156/ so that we can at least improve that one 20:52:34 dims: yes, definitely 20:52:42 s/improve/approve 20:53:13 * dims peeks at the clock 20:53:14 And let's move to open discussion 20:53:21 #topic Open discussion 20:53:31 I had a quick question for that 20:53:37 regarding the proposed Ocata release schedule 20:53:40 #link https://review.openstack.org/#/c/357214/ 20:53:48 It's based on placing the release week the week of the PTG end of February 20:53:57 As predicted that makes for a short cycle (13 weeks between DS and FF, including the end-of-year holiday period) 20:54:05 (to compare with recent history, Newton was 18, Mitaka was 18, Liberty was 15, Juno was 16) 20:54:18 A lot of projects already said they would take advantage of that to do some technical debt reduction (a.k.a. a stabilization cycle) 20:54:27 does anyone have any objection to running the validation tox job nonvoting on projects.yaml changes? (I have that patch up) 20:54:28 Some have been wondering if the TC should not more aggressively encourage that line of thought 20:54:41 make it the "py3k cycle"? ;) 20:54:47 Thoughts on that ? 20:54:50 fungi : ++ :) 20:55:01 Personally I'd rather let project teams take it to their own conclusions 20:55:08 We've kicked that idea around for a long time, this is the natural time to do it 20:55:11 and focus on the goals soft-guidance instead 20:55:25 ttx : +1 to soft-guidance 20:55:28 "themes" seem like a friendly way to encourage that 20:55:29 ttx: yeah, I think the soft approach makes sense here 20:55:43 We just need to make sure everyone realizes how short it is 20:55:52 but that's relmgt team work, not tc 20:56:24 mtreinish: go for it (non-voting job) 20:56:25 so, I almost feel like we should just call out R-8 as dead week 20:56:44 because, I can't imagine you'll have many reviewers working that week 20:56:51 sdague: right 20:57:15 relmgt can send out a email with the proposed dates and callout the # of weeks and R-8 etc 20:57:20 ttx: well it's mostly does anyone have a reason we shouldn't do: https://review.openstack.org/363165 20:57:39 I'm also considering proposing that we freeze all libraries the week before o-3 instead of splitting client and non-client -- the split has introduced some confusion in teams with libs that seem on the fence between client or not 20:57:53 I think it would be useful to get the metric tag info on proposed changes so we can easily refer to it in review 20:58:14 the tradeoff is querying stackalytics is slow (it took ~15min locally to finish) 20:58:19 mtreinish : as long as it's non-voting, I don't have an issue. I just don't want the repo blocked when data outside our control changes the definition of "valid" 20:58:19 dhellmann : the problem there is the requirements need to be updated.. 20:58:26 in the past it was because non-client library releases needed to get updated in caps in client library requirement files during the intervening week 20:58:46 now we're hopefully relying a lot more on constraints and less on requirements cap bumps though 20:58:51 still short of one vote on Anne's https://review.openstack.org/#/c/356156/ 20:58:52 dhellmann: yeah definitely, I made sure to leave it nonvoting 20:58:56 dims : what fungi said 20:59:00 should we just limit the client bits to that then? 20:59:09 ack dhellmann fungi 20:59:17 thx sdague 20:59:20 Sorry to pop in, yuval from smaug/karbor. Would like to update that smaug repo will be renamed karbor this weekend by the infra team. Just want to make sure it's ok to do so when the governance patch ( https://review.openstack.org/#/c/353278/ ) vote is still running 20:59:21 dtroyer : ? 20:59:32 yuval : yes 20:59:37 yuval: i'll approve that one as soon as the rename is done 20:59:42 limit the clients to settling the requirements in the following week after lib freeze 20:59:45 dhellmann: ttx: thanks 20:59:57 Alright, one min left 21:00:07 Anything else, anyone ? 21:00:44 Taking that as no 21:00:48 #endmeeting