20:02:04 <ttx> #startmeeting tc
20:02:05 <openstack> Meeting started Tue Aug 16 20:02:04 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:08 <openstack> The meeting name has been set to 'tc'
20:02:09 <ttx> Hello everyone! Our agenda for today:
20:02:14 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:14 <mtreinish> o/
20:02:22 <ttx> (remember to use #info #idea and #link liberally to make for a more readable summary !)
20:02:28 <ttx> #topic Appoint Dean Troyer as replacement for Morgan
20:02:34 <ttx> #link https://review.openstack.org/354633
20:02:47 <ttx> mestery and myself have approved post-meeting the charter change proposed last week, which merged
20:02:57 <ttx> This change is applying the process described there and appointing Dean in replacement or Morgan
20:03:02 <ttx> for*
20:03:13 <ttx> This has enough votes to pass now, so I'll approve it unless someone screams
20:03:20 <russellb> dtroyer: thanks for being willing to jump in
20:03:38 <sdague> ++
20:03:41 <mestery> +1
20:03:44 <johnthetubaguy> +1
20:03:46 <dtroyer> russellb: I am happy to
20:03:46 <annegentle> thanks dtroyer
20:03:48 <ttx> Welcome dtroyer, let me flip your ACL approval rights too
20:04:32 <ttx> done, you can Rollcall Vote now
20:04:46 <dtroyer> thank you ttx
20:04:53 <ttx> I think I fixed up your -tc ML rights the other day already
20:04:59 <dtroyer> and everyone
20:04:59 <ttx> (but shhh)
20:05:11 <ttx> #topic Community-wide goals
20:05:27 <ttx> We had another week of discussion around community goals, and I think we need to move now
20:05:33 <ttx> #link https://review.openstack.org/349068
20:05:41 <ttx> this one is the general process description
20:05:51 <ttx> Some wording could still be adjusted, but I think the current version can be merged now and subsequent adjustements be proposed as separate changes
20:06:01 <thingee> +1
20:06:07 <ttx> The only strong opposition was the concern that this would result in "top-down design" (jaypipes, hongbin), but I think we cleared out that this is not the intent of the goals at all
20:06:30 <ttx> The other concern (expressed by notmyname, sdague) is that some goals might be so much work that prioritizing them over everything would create conflict with other natural priorities in the team
20:06:32 <notmyname> if you think working should change, what's the rush on landing it now over getting better wording
20:06:59 <ttx> notmyname: I think wording could be improved. Doesn't mean there would be a majority of members agreeing with that
20:07:14 <annegentle> I'd like to see rephrasing as well before landing it. Shows work towards consensus-basis.
20:07:28 <dhellmann> someone needs to propose specific wording changes
20:07:34 <ttx> but if we have consensus around another wording now, that's fine too
20:07:46 <ttx> it's just simpler to judge as a separate patch
20:07:49 <annegentle> dhellmann sorry I hadn't caught the "technical debt" line, was on my phone (hence all the typos previously, bwah)
20:08:05 <ttx> I think careful selection of goals can help with that second concern
20:08:16 <ttx> Also, Murphy's law states that shit will always happen
20:08:26 <ttx> if a team finds themselves in an exceptional situation and ends up not being able to complete the goal, it's fine
20:08:38 <ttx> We just need to document that exceptional situation for future reference
20:08:39 <annegentle> ttx I'm overall fine with the effort, hence my vote. Still... any chance to revise would be welcomed
20:08:46 <dhellmann> annegentle : np, I do want to make sure the info is clear
20:08:53 <dhellmann> annegentle : what would you like to see changed?
20:08:58 <annegentle> dhellmann ok if I review now inline?
20:09:07 <dhellmann> sure
20:09:18 <annegentle> dhellmann really just was buying time before meeting to sit at a computer again... it's a crazy pre-kids-back-to-school-week
20:09:31 <annegentle> travel-next-week-kind-of-week
20:09:34 <annegentle> :)
20:09:36 <dhellmann> heh
20:10:03 <ttx> I was interested in approving this version and iterating on it since the current patchset has all +1s nicely lined up
20:10:21 <johnthetubaguy> ttx: +1 fix ups being a follow on patch
20:11:01 <ttx> this is a reference document, so it's a living document. Not like a resolution where the wording can't change
20:11:13 <annegentle> ttx hm...
20:11:29 <annegentle> ttx I guess I can be convinced with that because it offers more long-term flexibility too as we try this out
20:11:49 <annegentle> plus a spelling error seems like it could be fixed :)
20:11:57 <ttx> annegentle: that's why it lives in the reference/ directory and not in the resolutions/ one
20:12:10 <dhellmann> yeah, spelling errors fall under the trivial fix house rule
20:12:28 <sdague> ttx: yeh, I think that's a nuance that was missed by me
20:12:28 <ttx> err, it actually lives in its own directory
20:12:37 <dhellmann> yeah
20:13:10 <ttx> I guess we could add to README.rst that goals are also living documents like reference
20:13:37 <ttx> since README describes the directory structure of the repo
20:13:42 <annegentle> ok, looking at my suggestions they seem to fall under the "can be fixed in future" rewording camp
20:14:15 <annegentle> dhellmann er, took off my -1 in case it blocks
20:14:44 <ttx> We have almost everyone +1ing here so this sounds like a good starting point.
20:14:48 <dhellmann> annegentle : I replied to your comments inline
20:15:07 <russellb> ttx: ++
20:15:08 <ttx> Objections to merging this now and proposing subsequent improvements as separate reviews ?
20:15:20 <mtreinish> ttx: that works for me
20:15:23 <ttx> perfect being the enemy of good and all
20:15:28 <dhellmann> ttx: I'll update the readme in a follow-up
20:15:31 <annegentle> notmyname is the concern about the wording mentioned on the ML also mentioned in the review?
20:16:02 <notmyname> annegentle: good question. I haven't added it in the review (didn't want to have one conversation in 2 places)
20:16:15 <notmyname> annegentle: would you like me to add a reference in gerrit?
20:16:30 <ttx> I'll add my alternate wording suggestion in there for reference, before approving
20:16:37 <dansmith> seems like removing three words would make this first version acceptable to almost everyone, right?
20:16:49 <annegentle> notmyname ttx yeah that's helpful for archival purposes (and when our future selves look back after trying this out)
20:16:50 <dansmith> "above other work" the sticking point for me
20:17:48 <notmyname> dansmith: yeah, that's the worst part
20:17:59 <ttx> recorded my alternate wording suggestion
20:18:06 <dhellmann> dansmith : that would make it unacceptable to me, fwiw
20:18:15 <dansmith> if we removed that I'd be +1 (for what it's worth) and much happier to iterate from _that_ afterwards
20:18:20 <sdague> dhellmann: why?
20:18:46 <dansmith> based on the goals proposed after this general doc, I don't understand why it matters that they're highest priority
20:18:54 <dhellmann> sdague : because I consider that phrase an important part. Saying "they will prioritize the work" allows it to be a low priority and not even worked on.
20:19:06 <annegentle> the whole point is to get agreement that we're investing our resources wisely.
20:19:26 <sdague> sure, but there are lots of really important things that never will fit into a process like this
20:19:27 <dansmith> dhellmann: if that's the case then maybe it's best not to land this and then plan to iterate later, because that'd be the thing I'd like to see iterated upon first :)
20:19:29 <ttx> I think we can discuss the semantics in the subsequent patch when it's proposed by someone who cares enough about the issue to propose it
20:19:29 <annegentle> so I'd rather keep strong wording and ensure that the comms around it show the benefits outweigh the concerns
20:19:35 <sdague> like upgrade support
20:19:51 <annegentle> sdague ah, ok, so it's the timing/scoping.
20:19:53 <dansmith> exactly
20:19:54 <sdague> and it is fine that things that fit into one cycle are as important as other things
20:19:54 <flaper87> o/ kinda here
20:20:07 <sdague> but I'm not sure why things that fit into one cycle trump all other things
20:20:13 <dhellmann> sdague : it is not "above all other work" it is "above other work"
20:20:40 <annegentle> sdague that may be where I'm hesitant on value as well. hm.
20:20:43 <sdague> dhellmann: ok, I guess I was reading it as the first
20:20:45 <dansmith> dhellmann: the other words about being a single cycle move that from implicit to explicit, I thnk
20:20:56 <dansmith> dhellmann: because so much of our important stuff is multi-cycle
20:21:04 <dhellmann> dansmith : I have a high level of confidence that the nova team can do 2 things at one time
20:21:36 <notmyname> dhellmann: I get the impression you wouldn't be ok with a goal being prioritized as second from the last. that's "above other work". so what's the substantive difference between "over other work" and "over all other work"?
20:21:47 <edleafe> dhellmann: we're already doing like 6 things at once
20:22:09 <dhellmann> notmyname : I expect teams to have to drop things from their priority lists for a cycle in order to fit these things in. I do not expect them to drop everything.
20:22:16 <dansmith> dhellmann: we surely can, but I think most of us feel like py3 (as an example) is just not realistically completable in O, and that's kinda the benchmark goal I'm using in my head, since it's very cross-project-y
20:22:19 <flaper87> notmyname: I guess common sense will come into play in that case. These goals are cross-project and have significant relevance
20:22:52 <flaper87> I'd expect teams to be able to prioritize some of their tasks to be able to achieve these goals. Not all tasks should be dropped or de-prioritized
20:23:03 <ttx> OK, since there is no consensus on alternate wording right now, I'd rather merge the version that actually has 10+ TC members agree with it
20:23:08 <annegentle> flaper87 also the benefits should be amenable to all of OpenStack, amenable as in "yep that reasoning makes sense"
20:23:13 <ttx> and let people propose alternate wording
20:23:13 <sdague> so, to be clear, I don't want us to die on the hill over whether the word "all" feels implied or not. So as long as we all agree to be reasonable humans unit testing this process with some real things, I'm fine moving forward
20:23:17 <dhellmann> dansmith : I tried to answer sdague's concerns on that in the review. tl;dr is documenting the plan, and making significant progress on it, would be ok for me.
20:23:19 <flaper87> annegentle: correct
20:23:21 <flaper87> ttx: ++
20:23:26 <sdague> because I think the reality is we're going to learn a lot trying to do this
20:23:32 <annegentle> ttx are we on deadline for this release though?
20:23:34 <flaper87> sdague: yes
20:23:34 <dhellmann> sdague : agreed
20:23:36 <russellb> sdague: ++
20:23:38 <thingee> sdague: +1
20:23:47 <ttx> annegentle: we need to define the goals ASAP if they are to have any chance of success
20:23:53 <dtroyer> in one of the reviews sdague spelled out the Nove issues with mox3, that is the sort of thing I would want to see in a why-this-didn't-hit-once-cycle statement in the doc..  we'll never know _all_ of those things up front, and if we wait for that to even try, well, here we are
20:23:53 <johnthetubaguy> sdague +1
20:23:56 <annegentle> ttx oh for next. got it.
20:24:03 <dhellmann> dtroyer : exactly
20:24:12 <dansmith> dhellmann: then why not say that instead of "above other work"?
20:24:14 <ttx> OK, approved
20:24:16 <dansmith> anyway, we're clearly moving
20:24:24 <ttx> Now onto the goals for Ocata
20:24:40 <ttx> which should be the important discussion, rather than wording details that can change at any point in the future
20:24:51 <ttx> #topic Add ocata goal "support python 3.5"
20:24:53 <dhellmann> dansmith : it's all in there. I don't want every goal to turn into a multi-cycle effort, though. *try* to do the thing in the cycle.
20:24:56 <ttx> #link https://review.openstack.org/349069
20:24:56 <amrith> thanks dhellmann on moving this forward
20:25:06 <sdague> ok, so in the unit testing mode. I think the question in my mind is where the analysis for what's required happens
20:25:08 <ttx> the py35 one is mostly consensual, the only opposition I could track was the comment from sdague
20:25:17 <annegentle> ttx I have concerns
20:25:18 <ttx> (that mox has some crazy races with python 3 that seem completely non deterministic, and Nova still has 2440 instances where it's called)
20:25:33 * ttx refreshes review
20:25:36 <dansmith> I have concerns, I don't think py35 is doable in one (the next) cycle for nova
20:25:53 <sdague> ttx: well, I think it's one of the few projects that exposed what is required inside a specific project
20:25:58 <notmyname> likewise, I do not thing py35 is doable in swift in the next cycle
20:26:26 <ttx> notmyname: could you express that as a -1 on the review for reference ?
20:26:33 <dhellmann> dansmith , notmyname : do you think you could make significant progress on it? I think nova and swift are behind some of the other projects in terms of starting point.
20:26:45 <notmyname> ttx: sure. I was holding off until the other patch was resolved :-)
20:26:58 <dtroyer> notmyname: is there some discrete subset that might be?
20:27:01 <sdague> dhellmann: we've been making significant progress for 4 cycles
20:27:02 <ttx> notmyname: one -1 at a time ? :)
20:27:05 <dansmith> dhellmann: we already have
20:27:08 <dansmith> dhellmann: and will continue to
20:27:29 <dhellmann> sdague, dansmith : ok, but specifically toward the list of things in this proposal. what *could* you do?
20:27:30 <sdague> the point is the scope per project is assumed to be small
20:27:31 <ttx> dhellmann: maybe it's a bit early to have that as a goal then
20:27:43 <dhellmann> sdague : no, I have no doubt this is a big one.
20:27:44 <notmyname> ttx: well, as I said at the beginning, I didn't want to agree to a proposal when I didn't agree with the framework for it. but I'm not sure it needs a -1 because it can't be done all in one cycle?
20:27:46 <ttx> if for some projects it's more work than they can swallow in a (short) cycle
20:28:01 <annegentle> so, we're uncovering dependencies issues with Ansible and 3.5, plus the sizing.
20:28:09 <notmyname> sure, we'll make progress on py35 compat during the next cycle. as we've done in previous ones
20:28:16 <dhellmann> annegentle : the ansible thing is not an issue
20:28:17 <dansmith> dhellmann: I don't actually know anyone actively working on it, so it's really hard to even plan that
20:28:24 <ttx> notmyname: the concept of development cycle goals is that they have to be "completed" within a cycle
20:28:35 <dhellmann> dansmith : what would it take to ensure that there was someone actively working on it?
20:28:44 <annegentle> dhellmann ah ok, re-reading the "integration tests" piece.
20:28:47 <ttx> so if it's not doable for, say, Nova to complete the goal, it may not be a good goal
20:28:53 <sdague> the unit tests aren't doable for sure
20:29:00 <sdague> because of the mox issue
20:29:06 <russellb> well, nova is one of the biggest projects, it could also just be an exception
20:29:15 <dtroyer> for both Nova and Swift, is there a subset that is doable?
20:29:20 <russellb> we expect most projects to complete this, but could have a few documented exceptions where we expect it to be too big to complete
20:29:20 <dhellmann> yes, I'm not sure we want to size everything based on whether nova can do it in one cycle
20:29:21 <dansmith> dhellmann: I dunno, money? :)
20:29:22 <sdague> nova's functional tests are different than others, so it's actually not super clear that's actually useful
20:29:31 <notmyname> russellb: might need to take it as a sign that nova might not belong in openstack? ;-)
20:29:33 <sdague> the integration testing is the most likely next step
20:29:47 <mestery> russellb: ++, that sounds reasonable
20:30:00 <russellb> with the size of openstack, i'm sure exceptions will be common
20:30:02 <annegentle> I'm not completly convinced of the benefits for here/now.
20:30:07 <dhellmann> notmyname : not funny
20:30:11 <sdague> but, someone actually needs to own that bit cross project, to my knowledge python3 devstack is not actually a thing anyone is running voting anywhere
20:30:17 <notmyname> dhellmann: awe come one. I'm laughing :-)
20:30:24 <dansmith> annegentle: agreed, I'm not *really* sure who is clamoring for this, tbh
20:30:25 <sdague> which is unstaffed and not from any particular project, right?
20:30:27 <russellb> annegentle: because this is a requirement from the python community we have to keep up with?
20:30:36 <annegentle> and one thing I want to know is, how to propose an alternative to this particular goal? I'm okay with the Oslo one, but this one, I'm not as sure of.
20:30:44 <mtreinish> sdague: yeah we don't have that voting anywhere
20:30:54 <sdague> mtreinish: do we have it running anywhere?
20:31:00 <mtreinish> sdague: the last I looked there was a patch which flipped the switch dhellmann added a while back for testing
20:31:04 <dhellmann> sdague : how long before python 2 EOL do you want to wait? if you already think it's going to take >1 year, and we have something like 3?
20:31:16 <ttx> I think this goal only has value if we can achieve it for all projects, not with already-known missing projects
20:31:26 <sdague> dhellmann: we're going to make progress, I just don't think the unit tests are doable
20:31:28 <annegentle> russellb but who does that benefit exactly? I'm not sure.
20:31:34 <sdague> unless we do things like delete the xenserver driver
20:31:44 <ttx> annegentle: it benefits us
20:31:45 <dhellmann> sdague : that's fine with me. I'm much more interested in the integration tests, personally.
20:31:58 <sdague> which doesn't mean the code won't work, it's just the unit test issue
20:32:00 <mtreinish> sdague: https://review.openstack.org/#/c/331224/
20:32:00 <patchbot> mtreinish: patch 331224 - openstack-dev/devstack - DNM: Test with python 3.4 enabled
20:32:04 <russellb> annegentle: it affects everyone who runs openstack
20:32:06 <dhellmann> it just felt weird to say that we'd do those before unit tests
20:32:27 <sdague> dhellmann: right, well unit tests are technical debt too
20:32:40 <ttx> dhellmann: maybe limiting to integration tests would make it more... reasonable for the ocata goal
20:32:43 <dhellmann> yeah, logically those seemed easier, mox notwithstanding
20:32:44 <annegentle> clients are in scope here also?
20:32:50 <dhellmann> ttx: I would be ok with that
20:33:01 <dansmith> ttx: sdague: do we have any idea how close we could be to integration tests for all projects?
20:33:02 <dhellmann> annegentle : yes, everything
20:33:03 <sdague> dhellmann: yeh, if it wasn't the mox issue, it would be easy
20:33:08 <dansmith> becauseI feel like we know less about those than unit tests
20:33:11 <sdague> dansmith: I have no idea
20:33:18 <ttx> notmyname: how much more doable would that make it for swift ?
20:33:18 <sdague> that's the part that feels unstaffed
20:33:25 <notmyname> what is an integration test? is that running the service under py3 and running functional tests?
20:33:27 <dhellmann> sdague : is the solution to the mox thing to rewrite all of those tests?
20:33:28 <russellb> if we throw goals out because of a minority of exceptions, it feels like we'll just end up with the least common denominator of goals
20:33:31 <mtreinish> ttx: so change the goal to have a voting dsvm tempest python3.5 job on every project?
20:33:31 <dansmith> so if this is one cycle, prioritized above other work, how can we possibly even adopt this as a goal?
20:33:33 <russellb> and it won't be a very interesting exercise
20:33:33 <sdague> dhellmann: pretty much
20:33:43 <sdague> dhellmann: which we've been doing
20:33:43 <dhellmann> notmyname : devstack-gate with the service under python 3
20:34:03 <sdague> it's slow going
20:34:06 <dhellmann> sdague : ok, if we drop the unit tests does that make it more doable?
20:34:28 <dhellmann> russellb : right, consensus is not 100% agreement
20:34:46 <notmyname> ttx: it's hard to stay. yeah, that's less scope, but I'd have to explore more of the current py3 gaps before committing to a deadline
20:35:09 <russellb> and seems like it could be useful to carry goals over to the next cycle for projects that didn't finish it, tracking which needed a bit more time to wrap it up
20:35:11 <dansmith> notmyname: that's my point, I feel like it is less easy to answer if you remove the one known bit, at least for nova
20:35:13 <russellb> py3 seems like a good example of that
20:35:13 <dhellmann> dansmith : what I want is for projects to try it. If we discover that it doesn't work, then that's an outcome. But if we never set a goal of trying it, then everyone is going to keep saying "we have N more years"
20:35:15 <ttx> dhellmann: looks like this one needs more work, should we switch to discussing the other one ?
20:35:22 <dhellmann> ttx: ok
20:35:29 <ttx> #topic Add ocata goal "remove copies of incubated Oslo code"
20:35:34 <ttx> #link https://review.openstack.org/349070
20:35:34 <dhellmann> russellb: carry-over is built into the process
20:35:44 <ttx> I noticed objection from mugsie that designate likes using its own copy of the small memorycache wrapper
20:35:53 <dansmith> dhellmann: I'm all for it, but we just agreed it was going to be pretty high priority and we hardly know what the extent is :)
20:35:59 <ttx> But that seems to point to either the need to split that function from the lib or just accept the benefits of the maintained lib approach (disk space is cheap)
20:36:07 <ttx> No other objection last time I looked
20:36:13 <sdague> ttx: ok, so this again is the process question
20:36:36 <sdague> how many teams should check in with the scope for their project before moving this forward
20:36:46 <sdague> because it's super easy for me to +1, this directory doesn't exist in nova
20:36:53 <sdague> but, that's kind of a cop out :)
20:36:55 <jroll> there's a paste in the patch with a list of all the things this includes
20:36:57 <jroll> which isn't large
20:37:01 <ttx> sdague: I expect that even in the worst case scenario that would be reasonable amount of work
20:37:12 <sdague> ttx: I'd rather we didn't guess
20:37:21 <dhellmann> sdague : if the work is done, then that's all that needs to be reported.
20:37:25 <jroll> this is the current estimate:
20:37:27 <jroll> #link http://paste.openstack.org/show/550418
20:37:27 <ttx> sdague: that is why we cced all PTLs on that review
20:37:36 <dhellmann> sdague : this was a purposefully small goal, because the other was larger
20:37:36 <sdague> ttx: ok
20:37:48 <dtroyer> we are fast-tracking the bits that would get more time to research in future goals
20:38:02 <sdague> dtroyer: we're still setting a pattern
20:38:22 <sdague> I guess the question is, should the PTLs actually update the patch with what their project needs to do
20:38:27 <annegentle> ok, for this one can I get the rewording since the comms here are pretty critical?
20:38:31 <mtreinish> jroll: that's not that many
20:38:51 <sdague> so with TC hat on, it's easier to say, "yeh, this seems very reasonable to push through on this cycle"
20:38:55 <ttx> annegentle: agree wording is more important to get right on this one
20:38:57 <dhellmann> sdague : yes, the PTLs should all prepare patches to update the details for their project
20:38:58 <jroll> mtreinish: exactly, and it isn't likely to break things hard, so I think it should be fairly easy
20:38:59 <annegentle> sdague I think the other document says PTLs track separately?
20:39:17 <dhellmann> annegentle : they need to provide links to their tracking artifacts, or details as to why those do not exist
20:39:25 <sdague> dhellmann: ok, but the TC is going to evaluate goals before the data exists on project scope?
20:39:43 <sdague> I guess I imagined this a slightly different way
20:40:07 <johnthetubaguy> sdague: +1 on the process causing some confusion for me, I imagined something slightly different again
20:40:07 <sdague> TC: we think this should be a goal for the next cycle, how hard is it for projects
20:40:09 <dhellmann> sdague : we're bootstrapping this process with some goals that we all discussed before. I picked 2 I knew about to write up.
20:40:23 <sdague> Projects: this is what it requires of us (into the review)
20:40:35 <sdague> TC: ok, now we have the data to evaluate prioritizing this
20:40:43 <dhellmann> they don't have to provide that until the O-1 milestone
20:41:04 <sdague> dhellmann: so then how do we know these are reasonable goals?
20:41:11 <johnthetubaguy> hang on... at what point to we work out we screwed up
20:41:16 <johnthetubaguy> erm, I mean what sdague said...
20:41:51 <johnthetubaguy> are these proposals we talk to the summit, and then projects follow up on the winners?
20:41:52 <ttx> goals should not originally come from a vacuum
20:42:20 <ttx> they should be the result of community discussions where we see the topic emerge as a potential goal
20:42:25 <johnthetubaguy> s/we talk/we take/
20:42:52 <dhellmann> the normal order is: discuss goals in community to determine scope and interest (summit); plan goals in the community (before PTG); TC pick a couple, write up, and approve by PTG; plan implementation (PTG); submit artifact docs (1st milestone); submit final docs (release)
20:42:53 <ttx> the job of the TC is to detect that trend and propose it as goal. We can get it wrong
20:43:26 <dhellmann> for this coming cycle, we have the summit and cycle start happening at the same time
20:43:26 <ttx> but the review should uncover those
20:43:40 <dhellmann> but I did not want to wait a full year before starting to work out how to handle goals
20:43:53 <sdague> ok, I guess I assumed we'd get some first cut plan in this doc before it landed
20:43:55 <ttx> dhellmann: I don't think we need to wait one year either
20:44:30 <ttx> dhellmann: looks like we'll need another round on that goal as well, if only t oinclude the wording from anne in there
20:44:32 <dhellmann> sdague : no, those are meant to be individual follow-ups so we can discuss them
20:44:44 <dansmith> so, we as a project pick our priorities at the summit/beginning of the cycle,
20:44:53 <dhellmann> ttx: ?
20:44:59 <ttx> dansmith: summit won't be at beginning of cycle
20:45:01 <dansmith> I would think the goals have to be vetted and reasonable by that point to be included in our prioritization
20:45:20 <dansmith> ttx: yeah, which is why I said /beginning
20:45:27 <ttx> oh ok
20:45:52 <dansmith> ttx: but dhellmann said O1, which presumably means first milestone for any cycle, is where we find out if it's doable, right?
20:45:54 <ttx> dhellmann: we don't have majority yet and Anne proposed extra words for that one
20:45:59 <fungi> on the "submit artifact docs" stage, i can imagine it getting tiresome for some teams (for example, i18n who has no code repositories whatsoever, or stable branch team who won't be able to backport any of this) to have to provide the tc with updates on why each and every one of these priorities doesn't apply to their team. is the tc going to actuall expect to get word back from every single team,
20:46:01 <fungi> or just use common sense on what projects will actually be impacted?
20:46:13 <dhellmann> dansmith : you're skipping the discussions between summit and ptg
20:46:32 <ttx> oh we actually have a majority now
20:46:47 <ttx> dhellmann: do you want to do another patchset including anne's proposed wording ?
20:46:52 <dhellmann> fungi : we'll see how that goes. I'm curious about infra's plans to port tooling to py3, though. :-)
20:46:52 <annegentle> dhellmann or I can
20:47:01 <ttx> We need to switch to next topic
20:47:03 <dhellmann> annegentle : I do not see any suggested wording changes?
20:47:15 <johnthetubaguy> I was imagining we agree a draft list of goals in the last session of the cross project track, so that can trickle down, and we loop back at the end of the week
20:47:20 <ttx> dhellmann: Add lead sentence: "By ensuring all projects are using released Oslo libraries, OpenStack can ensure that Oslo bug fixes and security releases are available to all projects."
20:47:22 <annegentle> dhellmann would like a single sentence lead/lede
20:47:27 <annegentle> dhellmann I can do it, after merging
20:47:29 <fungi> dhellmann: me too!
20:47:30 <dhellmann> oh, I'm looking at the wrong patchset
20:47:31 <annegentle> dhellmann it's not controversial
20:47:40 <annegentle> fungi heh
20:47:50 <sdague> I don't think the goal is controversial, I just want to get the pattern right going forward
20:47:59 <annegentle> dhellmann it kinda sucks since it uses "ensure" twice.
20:48:07 <annegentle> dhellmann I can work on it
20:48:30 <dhellmann> annegentle : ok, let's work on that separately, I agree it's a good addition
20:48:34 <ttx> annegentle: let's approve it and refine it later ?
20:48:41 <annegentle> dhellmann ttx yep, I'm good with that
20:48:48 <ttx> ok done
20:48:49 <sdague> I would personally much rather have some chunk of the listed projects inline have data about whether or not it applies to them
20:48:50 <notmyname> on this general topic then, what's next for PTLs?
20:49:01 <sdague> and what the scope would be
20:49:01 <notmyname> where do we submit patches to reference things? when?
20:49:32 <ttx> sdague: we can always add that
20:49:34 <dhellmann> notmyname : update the goal page in the governance repo with links to plans or other artifacts by the first ocata milestone
20:49:39 <ttx> need to switch to next topic
20:49:45 <ttx> #topic Storlets (initial discussion)
20:49:50 <ttx> #link https://review.openstack.org/353693
20:49:57 <ttx> Do we have anyone from the Storlets project ?
20:50:07 <eranrom> yep. Thanks for having us
20:50:37 <eranrom> ttx: I have replied to your initial questions in Gerrit
20:51:14 <ttx> eranrom: thanks
20:51:58 <ttx> FWIW what I mean by viable standalone is a team taht actually works outside of the original team it was developed under
20:52:20 <ttx> I missed  your meetings since they are not logged under the offciial channels
20:52:42 <annegentle> is there any other project working like this today?
20:52:47 <ttx> so I was wondering how long you've been operating as a separate team
20:52:49 <eranrom> Well, the fact is the from day 1 storlets have been developed outside of the Swift team
20:53:04 <eranrom> for about a year now
20:53:16 <eranrom> 14 month to be precise :-)
20:54:05 <notmyname> ttx: what eranrom said. storlets didn't come out of the openstack swift developer team. this is an ecosystem project asking to join openstack, not a separation of one project out of another
20:54:25 <russellb> sounds like a very cool project, btw
20:54:34 <eranrom> russellb: thanks!
20:54:43 <annegentle> yeah I'm excited about the possibilities
20:54:44 <notmyname> although, of course, eranrom and anyone doing storlets is/has also been talking to people who do swift things (and quite a bit)
20:54:48 <bswartz> This project is Java code... doesn't that disqualify it?
20:54:49 <thingee> openjdk is not known at this time to work according to comments. I believe other solutions in openstack have hit this wall in just being a proposed dependency.
20:54:59 <russellb> bswartz: end users write java code
20:54:59 <dhellmann> eranrom : how do you test the java bits under CI?
20:55:57 <jroll> thingee: where does it say openjdk doesn't work?
20:56:01 <eranrom> well, all the Java code is running in a Docker container, we have a Jenkins job that builds it, and then we drive our middleware to test it
20:56:08 <jroll> thingee: oh, found it, sorry
20:56:08 <dtroyer> we don't (AFAIK) have any other projects promoting Java as a user-facing language
20:56:33 <mestery> eranrom: That's a slick way to do it using containers, very nice
20:56:37 <annegentle> dtroyer jclouds is governed by Apache Foundation fwiw
20:56:55 <dtroyer> it's an sdk/app developer thing, is this the same category
20:56:58 <eranrom> dtroyer: Doesn't the SDK uses Java and other?
20:57:04 <dtroyer> using that logic, we can run powershell in projects
20:57:08 <bswartz> I'm just confused about why we can say no to golang and yes to java...
20:57:26 <jroll> bswartz: this isn't a java project
20:57:30 <jroll> it's a project that runs java
20:57:40 <bswartz> jroll: thanks
20:57:43 <eranrom> mestery: Well containers are at the heart of the project, we cannot just execute end user code on a storage system
20:58:09 <mestery> eranrom: Exactly, but still, it's a neat model and lets you do some interesting things with regards to CI
20:58:10 <annegentle> bswartz it's not a REST service written in Java
20:58:25 <eranrom> mestery: right
20:58:45 <mestery> eranrom: We do some similar things for the work we've done in upstream ovs/ovn for scale testing
20:58:57 <eranrom> annegentle: bswartz: Right, its more if a language binding
20:59:07 <eranrom> we are now working also on Python
20:59:32 <kota_> eranrom: for running user's python code
20:59:41 <eranrom> kota_: right, thanks
20:59:42 <kota_> on a storage system
20:59:44 <ttx> OK, unfortunately we do not have a lot of time to cover this today and will have to continue this in a future meeting. In the mean time, please review and comment on the change itself
20:59:55 <dtroyer> has there been any thought with regard to auditing/securing the container running user-supplied code?
20:59:58 <ttx> since this teaser seems to have picked your interest
20:59:59 <eranrom> ttx: thanks
21:00:10 <annegentle> did I miss any answer for my question about the model, has it been done before or is it happening elsewhere?
21:00:24 <johnthetubaguy> I remember this coming up: https://zerovm.readthedocs.io/zerocloud/overview.html
21:00:28 <jroll> annegentle: zerovm did something similar but implemented totally different
21:00:28 <annegentle> the project dependency model
21:00:30 <ttx> eranrom: you could retrofit some of the answers to my questions in the commit message for reference
21:00:32 <annegentle> jroll ok
21:00:33 <eranrom> johnthetubaguy: right
21:00:38 <jroll> annegentle: and not openstack
21:00:40 <bswartz> ttx: s/picked/piqued/
21:00:45 <eranrom> ttx: sure
21:00:46 <ttx> (especially the details around language, which will avoid a lot of questions)
21:00:54 <ttx> bswartz: damn, owned by a French verb
21:01:05 <ttx> #topic Open discussion
21:01:14 <annegentle> ttx quelle horreur
21:01:15 <annegentle> :)
21:01:18 <ttx> A lot of us will be at OpenStack East / Ops midcycle in New York next week so it's probably a good bet to skip that one
21:01:47 <annegentle> so, shall I propose another idea for a goal to get all projects using the common API docs tooling? Is that the sort of thing we're looking at?
21:01:48 <ttx> I'll propose that in a -tc thread
21:01:59 <mtreinish> annegentle: ++
21:02:02 <annegentle> I don't mind skipping next week
21:02:03 <ttx> And we are over time
21:02:32 <annegentle> ayup
21:02:32 <ttx> #endmeeting