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