15:01:29 <mnaser> #startmeeting tc-goals
15:01:30 <openstack> Meeting started Thu Mar 21 15:01:29 2019 UTC and is due to finish in 60 minutes.  The chair is mnaser. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:30 <lbragstad> o/
15:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:33 <openstack> The meeting name has been set to 'tc_goals'
15:01:48 <mnaser> cool thanks for coming here everyone
15:02:13 <adriant> yay! i'm online
15:02:19 <ttx> o/
15:02:21 * fungi is trying to lurk, but also in a couple other meetings
15:02:32 <adriant> my home internet died minutes before the meeting...
15:02:41 <adriant> i'm hotspoting off my phone...
15:02:42 <evrardjp> better than during it  adriant :)
15:02:58 <evrardjp> adriant: limited data plan?
15:02:59 <mnaser> i've got _some_ sort of very basic etherpad to start on
15:03:05 <mnaser> https://etherpad.openstack.org/p/project-goal-meeting
15:03:34 <mnaser> i wanted to use the first bit of time to discuss the actual goal selection itself, dhellmann raised some concerns in his review
15:03:35 <adriant> evrardjp: home plan is basically a highspeed fibre business plan, but I guess they don't people to be awake at 4am
15:03:44 <dhellmann> o/
15:03:48 <zaneb> o/
15:04:00 <mnaser> i wanna try to timebox this to 20 minutes so we have time to talk about the other goals, but doug's review is here https://review.openstack.org/#/c/639010/
15:04:10 <mnaser> i'll let him take it from here
15:04:20 <dhellmann> well, I'm a little worried about the evolution of the solution to that goal in terms of how it fits our goals process
15:04:39 <dhellmann> the idea for goals is to rally the community around something that we all need to do together and that needs to land more or less at the same time
15:04:56 <dhellmann> this feels like a much much smaller thing that could be done iteratively by a small group
15:05:24 <dhellmann> the *original* definition would have required new APIs in all services, but the current draft (which I think makes sense technically) is basically adding features to the SDK
15:05:53 <dhellmann> what do the rest of you think?
15:06:20 <lbragstad> i agree, and i think this thread is applicable to the other goal under review as well
15:06:28 <gmann> dhellmann: you mean the part-1 of this goal, in that i agree with your point.
15:06:42 <gmann> but part-2 still need interface from each services
15:06:57 <evrardjp> lbragstad: I think it's even smaller grasp for the other goal
15:07:01 <jroll> I agree, and I also want to point out that every project team contributing to "one single library" would be a merge conflict nightmare
15:07:04 <dhellmann> are we talking about doing part 2 during train?
15:07:22 <adriant> jroll: that's why the original plan was a plugin based solution
15:07:32 <zaneb> I think this is highlighting (again) that we don't have a process for driving changes like this
15:07:34 <jroll> sure
15:07:34 <evrardjp> jroll: plugins?
15:07:37 <adriant> we can always reconsider doing part 2 in train
15:07:37 <gmann> ok, let's leave the part-2 separate (away from train)
15:07:41 <evrardjp> haha ok adriant :)
15:07:58 <dhellmann> adriant : I think the plugin solution was adding unnecessary technical complication just to make it fit the goals process
15:08:14 <dhellmann> zaneb : yes, you're right
15:08:20 <zaneb> shoehorning something that doesn't fit the goals process into the goals process would be a mistake IMHO (reserving judgement on whether this proposal still fits)
15:08:44 <adriant> dhellmann: I don't disagree that plugins over-complicated it
15:08:55 <dhellmann> it seems to fit a popup team or even help-most-needed item better than the community-wide goals process
15:09:02 <evrardjp> this looks _per se_ as a thing that should be globally done over openstack, and we could work together. That sounds like community goal.
15:09:04 <adriant> and if this ultimately isn't right for a goal, then it isn't.
15:09:10 <lbragstad> at the same time, i wonder if we feel pressure to actually have community goals?
15:09:14 <adriant> but it does need some TC support to get done
15:09:42 <adriant> because any official attempt to solve project deletion has sadly kind of failed before :(
15:09:55 <evrardjp> that's a different problem adriant
15:10:05 <evrardjp> imo
15:10:05 <ttx> I think release goals involve some overhead to track that work lands in every project team
15:10:14 <ricolin> dhellmann, popup indeed, if we only consider doing phase 1 in train
15:10:17 <adriant> I agree, and that's why maybe it isn't idea for a goal
15:10:19 <dhellmann> adriant : I think the SDK team (at least via mordred) have expressed that they would be interested in supporting this feature
15:10:41 <ttx> Here we get the goal overhead, but for stuff that ultimately does not require that much coordination work
15:11:02 <ttx> It really needs $people, not $coordination
15:11:12 <gmann> is goal means adding code in each service side ? I think it can be fewer code but largely agreed from each service where goal need some sort of technical help or interface involvement
15:11:13 <lbragstad> that and it leaves several projects wondering "um, what are we supposed to do for this, again?"
15:11:22 <dhellmann> the OSC centralization goal is slightly different, in that we would be asking every team to deprecate their client (IIUC)
15:11:44 <ttx> yeah, it seems to have at least /some/ per-project work
15:11:47 <evrardjp> I guess it depends if we consider part2 or not
15:12:00 <ttx> it's just a bit pessimistic and assumes only one team will complete the goal :)
15:12:12 <gmann> and as openstack as whole, i feel like even this is SDK implementation in part-1 but this overall tool will be completed with part-2 only which we should  consider now also.
15:12:15 <zaneb> dhellmann: from the project deletion goal: "If the SDK does not support the feature yet, implement it," - does that part sound like a legit community goal? (possibly overlapping with the other one)
15:12:18 <dhellmann> that OCS change still pretty minimal, but it would have a larger impact on users who need to start considering changing tools
15:12:25 <ttx> zaneb: ++
15:12:33 <adriant> there are actually some services which don't have admin level delete resources as an admin
15:12:43 <adriant> so that is needed and could be goal driven potentilly
15:12:49 <adriant> potentially*
15:12:57 <dhellmann> zaneb : it depends on what "the feature" means? is that the OSC or deletion goal?
15:13:24 <zaneb> dhellmann: deletion goal, but it means OSC support for deleting the resources IIUC
15:13:34 <gmann> adriant: and we need project team involvement in at least 'dependency tree build for their resource'  ?
15:13:34 <adriant> dhellmann: as in, full service/resource support in the SDK would be needed so we can actually query/delete it.
15:13:44 <dhellmann> adriant : depending on how many, yes. we may want to document expectations for admin APIs more formally than we have
15:13:51 <adriant> gmann: maybe
15:13:52 <dhellmann> which services does that apply to today?
15:14:19 <adriant> dhellmann: some one commented about it in the review, but I forget who (will look later).
15:14:26 <gmann> i think sahara it was if i remember
15:14:32 <adriant> yeah Sahara sounds right
15:14:43 <dhellmann> I don't think we need project teams to write code for the dependency tree stuff. The people writing the code may need advice, and if those relationships aren't documented those are doc bugs in the project documentation, but that doesn't mean every project needs to contribute a developer to this
15:15:06 <dhellmann> ok, well, if I was working on this I would just do sahara last and work out the basics with the other projects first
15:15:16 <dhellmann> and then get someone with some sahara knowledge to help with that part
15:15:37 <mnaser> if the project deletion feature becomes api-level changes only (i.e. introduce an api to delete an entire project) .. does this make it fit our goal model?
15:15:57 <mnaser> i agree with adriant that this is something that seems _so_ obvious, but not inside openstack
15:15:58 <adriant> API level changes probably would
15:16:10 <ttx> mnaser: sure, that requires stuff to land everywhere, and then the tracking overhead in goals is justified
15:16:15 <adriant> but API level changes needs A LOT of thought and design work
15:16:16 <dhellmann> it would be closer, for me, but I understand the technical objections to that approach -- we still need something to do the orchestration, and bulk delete is an optimization
15:16:34 <adriant> bulk deletion APIs would solve a lot of the issues
15:16:51 <ttx> We should definitely not adopt a weird implementation just so that it can fit the artificial goal process
15:16:51 <mnaser> well the orchestration can be done by a small group of people, but 'bulk delete APIs' would simplify and defer the problem to be more project level
15:16:58 <adriant> and allow the SDK work to become the core of the deletion logic with efficient ways to do it.
15:16:58 <mnaser> i agree, ttx.
15:17:05 <gmann> yeah, either way API or any other intrerface that need project side implementation
15:17:08 <dhellmann> it makes the "just go away" mode simpler, but introduces more complexity with dealing with dependency cleanup between services
15:17:12 <asettle> Tuning in and out due to overlapping meetings, why *don't* we allow bulk deletion of APIs? Speak to the moron here, people.
15:17:24 <dhellmann> we do allow them, we just don't have them
15:17:28 <mnaser> these apis just don't exist
15:17:29 <asettle> (probably shouldn't call myself a moron on a recorded meeting)
15:17:35 <mnaser> we do have a lot of cross-project dependencies though
15:17:45 <asettle> Gotcha.
15:17:47 <gmann> yeah not all project have bulk deletion API
15:17:50 <mnaser> i.e. if you try to do a bulk delete in neutron, and ports are assigned somewhere into nova, that might fail
15:17:54 <mnaser> so that can fail miserably
15:18:04 <lbragstad> it also requires projects to grok new authorization concepts
15:18:06 <ttx> asettle: too late
15:18:19 <asettle> ttx, *shrug* how bad could it be
15:18:20 <evrardjp> ttx:  :)
15:18:29 <adriant> which is where building some dependency stuff is useful. and find the points where you can bulk delete :/
15:18:35 <gmann> lbragstad: you mean scope type things ?
15:18:41 <asettle> adriant, makes sense
15:18:41 <asettle> Thanks all
15:18:53 <lbragstad> gmann correct - in the API level approach for each service
15:18:56 <mnaser> i agree in the value, but i feel what dhellmann brings up is a strong point
15:19:11 <mnaser> which is, for train, if we do step 1 only, it seems like a community effort
15:19:52 <dhellmann> zaneb's point from earlier is good, that we have a couple of things here we'd like to drive but that don't fit our current processes
15:20:22 <zaneb> yeah, I really really really want this to happen
15:20:43 <adriant> Even if it isn't a goal, getting support for it and some push to get it done, and for each service to (as part of adopting the SDK as their client library) commit to adding new resources to this logic, is important.
15:20:54 <adriant> essentially, yes we need this
15:20:55 <zaneb> (I think we have a Forum session to discuss other ways we might drive these sorts of changes)
15:21:14 <adriant> but once we have it, the services have to commit to helping maintain it and their resources in the SDK
15:21:28 <adriant> it can't just be on the SDK team
15:21:35 <ricolin> The part I hope we can provide this goal a better start and be quicker to reach is it have people to organize all these information, and help on holding and summarize discussion into actions. Than it's a community goal for sure. But I'm not to worry to put it as a goal even we need some work before we can push it to each teams
15:21:41 <evrardjp> yeah, I don't really care about the format myself. I just see the value of having those deletion APIs + central client (those 2 goals are good imo)
15:22:06 <gmann> adriant: that is hard part. project team maintaining it in SDK would not success always
15:22:20 <mnaser> unless SDK team builds tests
15:22:22 <adriant> yes each service owns their own python-<service>client, but that's soon to be deprecated
15:22:24 <mnaser> which run in gates
15:22:54 <adriant> the SDK will be the main and primary client
15:23:12 <adriant> so shouldn't all the services have some ownership there?
15:23:33 <adriant> and in turn, support deletion features for their existing and new resources there?
15:23:52 <adriant> that's a bigger topic, but applicable to this
15:24:14 <gmann> IMO, doing this lib implementation and then think of goal (part-2) may introduce complication/question from projects side about "why we need to do this" is/was this goal.
15:24:25 <zaneb> yeah, that's the part where it seems like a goal might be most applicable
15:24:29 <asettle> Support and ownership is important, but I see that as different to driving and developing these changes. Would it not be easier to have a centralised body to orchestrate part 1? Part 2 definitely looks like it's a greater effort.
15:24:35 <gmann> Combining both part together as goal is something we should do even that can take 2 cycle
15:25:02 <adriant> the issue is finding a consensus on what part 2 looks like
15:25:09 <adriant> what should the delete API be?
15:25:16 <adriant> bulk delete? Orchestrated deleted?
15:25:28 <lbragstad> what was something we brought up in berlin's forum session
15:25:45 <adriant> that's why I want to put that off until we have the client side work
15:25:55 <lbragstad> s/what/that/
15:26:10 <adriant> because we can look at the dependencies in a better light, and then thing about where the APIs would help
15:26:22 <adriant> think*
15:26:25 <lbragstad> there was an action item to write up what the delete APIs would look like, then we can pick them apart
15:26:49 <dhellmann> maybe we should focus on the scope of work proposed for this cycle
15:27:01 <mnaser> i have an idea (rare occurance): why don't we come up with a potential group of folks to work on the client side work in Train for project deletion, and come up with some sort of 'standard' ideas inside U and propose another goal for T.
15:27:11 <gmann> yeah, i think we need to decide the best interface which project team can maintain and comfortable with.
15:27:18 <mnaser> like say, maybe, RBAC support which keystone has put the foundation to
15:27:42 <mnaser> and honestly, it's a bit embarassing that ~openstack~ in all of it's might means you need to write hundnreds of policies to get a read only account
15:27:48 <adriant> I'd support a readonly rolein openstack as a goal :P
15:27:48 <ricolin> mnaser, that sounds like a popup team material
15:28:04 <mnaser> RBAC is something each project can implement in their policy
15:28:25 <zaneb> mnaser: they really can't
15:28:35 <mnaser> huh?
15:28:47 <adriant> some have hardcoded policy logic
15:29:00 <adriant> at least I think that's what he means...
15:29:06 <zaneb> mnaser: if other projects don't respect the same RBAC policies then they're worse than useless
15:29:39 <mnaser> zaneb: the problem is that.. not all projects would follow it, so if i create a reader role, i have to do it across all deployed projects
15:29:56 <zaneb> mnaser: correct
15:29:57 <mnaser> so in some way, if we implement this, we'll finally fix the long living issue of the fact that adminness doesnt exist
15:30:01 <lbragstad> i would issue a word of caution on the rbac stuff as a goal - having done a bunch of that work this release in keystone, i think if you're going to push it across the community the goal has to be **ultra** specific and clear
15:30:03 <mnaser> aka i cant have 'domain' admins
15:30:33 <dhellmann> are we talking about a new goal now? or did we drift off track?
15:30:36 <mnaser> i am going REALLY on a huge change of direction but i think rbac fits more of a goal, and i can imagine it would be a *huge* sell
15:30:42 <evrardjp> dhellmann: I have the impression
15:31:04 <mnaser> my (non committed idea) was that we can split the delete one into two goals
15:31:12 <mnaser> the first one is just to get a group of people to prepare for it
15:31:13 <zaneb> mnaser: lbragstad has been plugging away at that for a while now
15:31:28 <asettle> mnaser, +1
15:31:29 <mnaser> and that way we have a _proper_ infrastructure for U goal to bulk delete
15:31:39 <mnaser> so rather than having a goal in a cycle where only 1/2 of it is done..
15:31:44 <adriant> I can live with that
15:32:05 <mnaser> but then again, im just throwing this out there.
15:32:06 <zaneb> I agree that any goal that doesn't fit in a cycle should be split into smaller goals that do
15:32:07 <dhellmann> so how do we structure whatever portion of that work we want done in train?
15:32:21 <mnaser> dhellmann: this is where we can discuss at the ptg/forum to come up with that "platform"
15:32:32 <adriant> and if Monty is willing to help add it to the SDK, and we can get some other support/review from people who know more about the services/resources, then great
15:32:35 <mnaser> that allows us to get work done on *community* work that is not yet goal level
15:32:57 <mnaser> or whatever infrastructure we want to put in place, as what zaneb was talking about earlier
15:32:58 <dhellmann> mnaser : I'm confused. Are you saying we should wait until the PTG to pick goals?
15:33:17 <ttx> sounds too late to me
15:33:28 <mnaser> dhellmann: no, i'm suggesting a replacement goal for the deletion goal with something that fits our goal and putting the delete aside for now
15:33:32 <ttx> teams need to know what they are up to as they discuss other priorities
15:33:47 <dhellmann> ok
15:33:51 <mnaser> and in the ptg, we can discuss on coming up with a platform/infrastructure to get cross-project work done (what zaneb referred to at the start)
15:34:11 <dhellmann> ok
15:34:15 <mnaser> which is stuff that "gotta be done" but doesn't involve every single project doing a bit of work in their codebase
15:34:30 <lbragstad> so - if there is something that is rbac related that aids in the deletion goal down the road, we should find out which aspects of rbac need to be done first and we can write up a goal for that
15:34:36 <dhellmann> I added "popup teams" to https://etherpad.openstack.org/p/tc-train-ptg
15:34:52 <adriant> a cross project project? with their own stories/bugs and PTL? :P
15:35:06 <asettle> Gawd
15:35:16 <mnaser> but that's just a suggestion, and i don't know how others feel about it.  i'd love to know if lbragstad feels it's also the right time for things like rbac, but man, how many years are we into openstack and getting a read only user or a user that can access a specific service only.. is still a struggle
15:36:14 <lbragstad> fwiw - i've spent an ungodly amount of time trying to document this - so you anyone can give me an idea of what they need RBAC-wise for project deletion bits to go smooth, i can probably lay out the process
15:36:28 <lbragstad> s/you/if/
15:36:29 <dhellmann> standardizing roles feels like a good goal, but do you think we'd have time to organize that for train?
15:36:53 <lbragstad> maybe? it will be close
15:37:03 * lbragstad looks for a magic wand
15:37:04 <mnaser> and it's the type of thing we all need to land together in a single release to make it work, because if any of them don't, it would be a failure
15:37:04 <adriant> the issue is that deployers can make their own policy, but better sane and tested defaults would be amazing. A read only role, or roles per service would be amazing, but would need to be a combination of policy AND implied roles.
15:37:17 <dhellmann> mnaser : is it? or would it just not be done yet?
15:37:27 <zaneb> mnaser++
15:37:34 <ricolin> IMO if we can first put all potential goal into a popup team, than we don't have to worry about that goal at all, but such action should settle in previous PTG, just a little weird to take it into goal now. But it's definitely a good stuff for Train or U cycle for sure
15:37:36 <mnaser> dhellmann: it would be not done yet would be accurate, but so long as a project doesn't do it, we can never claim we have RBAC
15:37:47 * dhellmann nods
15:37:52 <zaneb> dhellmann: it's essentially useless until everybody does it, so that's a good candidate for a goal
15:37:53 <mnaser> so we can pretty much _never_ get rbac if $foo decides they dont want to get it done
15:38:11 <dhellmann> ok, that makes sense
15:38:40 <dhellmann> we talked about documenting expectations for admin APIs, and documenting RBAC expectations feels like another good area of guidance for the TC to provide
15:38:41 <ttx> yeah, goals are really for when (1) every team has to land changes and (2) there is some value if all teams do it around the same time
15:39:00 <lbragstad> ++
15:39:07 <lbragstad> RBAC fits that bill, imo
15:39:09 <jroll> mnaser: to be clear, you mean "never get good default rbac", right?
15:39:11 <ttx> (for some definition of "every". Can be "most")
15:39:43 <jroll> we can still have lame manual rbac by editing policy files and such
15:39:59 <mnaser> jroll: no, pretty much non functional, because if you give role:admin with project scope, and a project doesn't implement it properly, then youll have full admin access to that project
15:40:08 <evrardjp> I am confused what's here proposed
15:40:08 <gmann> good defaults RBAC is not there and it may needs lot of work depends on how good/bad projects policy are
15:40:11 <mnaser> when in reality, you wanted to give someone admin access to a project
15:40:19 <jroll> mnaser: ah right, gotcha.
15:40:21 <jroll> thanks
15:40:25 <dhellmann> evrardjp : we've gone into the weeds of rbac implementation again
15:40:31 <adriant> My worry with major RBAC work is that at best all we can do is make sane defaults, and docs. And ultimately a deployer can edit and screw all that work up.
15:40:32 <evrardjp> yes indeed
15:40:47 <mnaser> well then let's take a step back
15:40:52 <evrardjp> so basically we'll need to go through the details of personas and stuff?
15:41:02 <mnaser> evrardjp: keystone team already did all of that
15:41:08 <mnaser> teams literally just have to implement the policy, thats all
15:41:17 <evrardjp> but we change it, for the new usage :p
15:41:21 <mnaser> admin/member/reader and system/domain/project scope
15:41:22 <adriant> I think we NEED rbac work, but remember that ultimately policy and which roles are created is up to the deployer
15:41:23 <zaneb> adriant: isn't that better than the current insane defaults and deployers can still screw it up?
15:41:32 <mnaser> ok let's take a step back
15:41:33 <adriant> zaneb: I totally agree
15:41:35 <gmann> mnaser: "implement the policy" or "improve the policy" ?
15:41:40 <adriant> I we need something better
15:41:44 <evrardjp> gmann: good question.
15:41:56 <mnaser> it looks like the current project deletion goal in it's current state doesn't fit our goal process, does anyone disagree with this?
15:42:08 <adriant> any saner default rbac and roles is better than what we have now
15:42:36 <adriant> but we need to be careful to document why it is like that, and how existing deployers can switch to using it from their own weird policy as well
15:42:48 <ricolin> mnaser, we need to make sure we have something like a popup team for it before we drop it out of goal IMO
15:43:10 <mnaser> ricolin: yes, popup team IMHO would be a ptg/forum type of discussion, i'm not saying "we don't get it done"
15:43:11 <asettle> mnaser, no disagreement. But ack ricolin - need to make sure it's owned by a central body before we move on.
15:43:19 <mnaser> i'm saying it doesn't fit under "cycle goals"
15:43:24 <asettle> Or at least, an action item somewhere to ensure it's covered.
15:43:26 <adriant> mnaser: as the person proposing the goal, yes I agree that it does not fit the goal process
15:43:26 <zaneb> mnaser: as a whole, I don't disagree, but I think there may be parts related to SDK support that are. we can probably discuss that in the context of the other proposed goal though
15:44:04 <adriant> but I would still like something done which allows projects like this to exist with support from the likes of the TC
15:44:19 <zaneb> adriant++
15:44:25 <ricolin> adriant, +
15:44:27 <mnaser> adriant: absolutely, hence the discussion at ptg/forum which i think dhellmann mentioned they added
15:44:28 <adriant> because there are a lot of small things like this, which need that push to get done
15:44:43 <mnaser> https://etherpad.openstack.org/p/tc-train-ptg <-- popup teams here
15:44:49 <mnaser> so we're def going to make sure we cover it
15:44:55 <mnaser> and "Goal selection retrospective" in there too
15:44:58 <ttx> yes, something that makes at least as much noise as the goals process, to attract as much attention
15:45:05 <mnaser> absolutely
15:45:09 <adriant> ttx: ++
15:45:13 <adriant> yes, that
15:45:18 <zaneb> we need some way of saying yes, this is a thing that needs to be done and it has been consulted on widely enough and everybody needs to take account of it as part of how OpenStack works, signed: the TC
15:45:18 <mnaser> ok, so that means we're in a place where we need a 2nd goal
15:45:23 <ttx> but better suited in recruiting a small dedicated team of people to accomplish one objective
15:45:42 <mnaser> or rather a goal to replace the project delete one for Train
15:45:52 <adriant> ttx: so a working group? :P
15:46:05 <dhellmann> mnaser : what's the status of the testing platform upgrade?
15:46:11 <ttx> adriant: I think it needs a more shiny name
15:46:15 <dhellmann> that lingered during stein, is it done now?
15:46:18 <jroll> dumb question: do we *need* 2 goals? why?
15:46:19 <ttx> not "YAWG"
15:46:29 <ttx> (yet another working group)
15:46:30 <asettle> jroll, not dumb question. Would be good to know.
15:46:48 <mnaser> dhellmann: so moving towards bionic? i think we're in a good place and that's mostly done
15:46:52 <ttx> Maybe "DAWG" (dang, another working group)
15:46:53 <ricolin> ttx, common! it can be YASIG!
15:46:59 <dhellmann> ttx: YAWN: yet another working (group) name
15:47:04 <ttx> Yo Dawg
15:47:05 <mnaser> gmann: probably can comment better about that
15:47:26 <mnaser> !addquote <ttx> Yo Dawg
15:47:27 <openstack> mnaser: Error: "addquote" is not a valid command.
15:47:30 <mnaser> this one is for the books
15:47:30 <gmann> mnaser: dhellmann we left with 5-6 patches to land on project side to move project specific jobs to bionic
15:47:30 <mnaser> :P
15:47:49 <gmann> and trove and networking-midonet are the one which need some work to do before that
15:48:03 <dhellmann> gmann : ok, so that's done enough that we probably don't need to consider it a goal this time?
15:48:14 <gmann> I am working with them and based on progress and when they finsh, we will be able to say it is done
15:48:21 <ttx> https://imgflip.com/i/2wlm8n
15:48:24 <adriant> Oh, actually a goal suggestion: Move off Paste
15:48:27 <gmann> dhellmann: yeah, thats does not need to be in goal
15:48:49 <adriant> Paste is pretty much used by almost all services, and is on life support
15:48:58 <gmann> one I idea am thinking for goal is moving the legacy jobs to zuulv3
15:49:00 * smcginnis imagines ttx with cornrows
15:49:09 <ttx> disturbing
15:49:11 <adriant> and a lot of services also use eventlet, which also should go away...
15:49:12 <dhellmann> as a reminder, here's our goal backlog: https://etherpad.openstack.org/p/community-goals
15:49:22 <gmann> legacy jobs are pain whenever any updates we need to do on gate things
15:49:23 <adriant> either of those could be community wide goal
15:49:27 <adriant> goals*
15:49:36 <smcginnis> Paste seems like a good start.
15:49:57 <dhellmann> do we have enough of any of those worked out to have them documented before the ptg?
15:50:11 <jroll> dumb question: do we *need* 2 goals? why?
15:50:16 * jroll asks again
15:50:21 <dhellmann> jroll: not really
15:50:26 <ttx> jroll: no
15:50:27 <dhellmann> do we have any at all right now?
15:50:36 <mnaser> we have the osc legacy client killing
15:50:39 <ttx> I'm fine with a single large goal
15:50:40 <mnaser> well okay
15:50:49 <mnaser> legacy client deprecation in favour of osc
15:50:55 <jroll> ok, had to ask as there was some implication we had to scramble to find a second if we dropped the project deletion thing
15:50:57 <dhellmann> maybe we should talk about the client goal in more detail then?
15:51:01 * dhellmann looks at the clock
15:51:16 <smcginnis> Not even deprecation, right? Just getting osc caught up.
15:51:17 <ttx> maybe we can be a bit more optimistic if that's the only train goal
15:51:18 <asettle> Line 290, "Add Configuration References to Project Doc Trees" is this not complete?
15:51:22 * smcginnis hasn't read the latest proposal
15:51:25 <ttx> (a train goal is called a destination)
15:51:29 <dhellmann> https://review.openstack.org/#/c/639376/
15:51:38 <asettle> dhellmann, see note above
15:51:42 <mnaser> it seems to me that this goal fits the fact it's team-based
15:51:45 <smcginnis> asettle: I believe so
15:51:46 <mnaser> so i am not really opposed to it
15:51:47 <dhellmann> asettle : that etherpad may be out of date
15:52:01 <asettle> Ah right. Cause that wasn't the only one I thought had been done
15:52:16 <dhellmann> maybe mnaser wants a volunteer to prune the backlog there
15:52:22 <asettle> That would be really heplful.
15:52:24 <asettle> helpful*
15:52:44 * mnaser takes notes
15:52:49 <adriant> number 3 is basically: Get rid of Paste
15:52:59 <asettle> We should look through the legacy client dep goal, but it would be nice to look through what we already *have* and want to complete rather than taking on more and new issues
15:53:04 <asettle> adriant, heh
15:53:05 <asettle> yes
15:53:18 <adriant> that is a legitimately good goal
15:53:29 <adriant> and doesn't need a major amount of work to define
15:53:30 <mnaser> does anyone object under the the "Move legacy client CLIs to OSC goal to Train" goal?
15:53:47 <evrardjp> I don't think so -- as a user of the cloud, I don't really care if it's using paste of any other mw
15:54:07 <adriant> evrardjp: paste is deprecated and unsupported
15:54:10 <adriant> so you should
15:54:12 <lbragstad> mnaser i think that goal needs to have it's criteria broken into separate lists
15:54:18 <evrardjp> yes, so will python2 next year
15:54:23 <jroll> evrardjp: as an operator, paste is annoying
15:54:24 <mnaser> we can discuss the other goal soon
15:54:24 <dhellmann> it could use more detail, yeah
15:54:31 <evrardjp> jroll: yes kinda
15:54:32 <asettle> We don't still have any projects on py2, do we?
15:54:32 <jroll> mnaser: I don't object to the idea, I haven't read the latest iteration
15:54:37 <asettle> That was a ocata/pike goal
15:54:38 <lbragstad> otherwise it feels similar to the project deletion goal in that it is very specific to only a handful of projects
15:54:46 <evrardjp> asettle: we still carry it
15:55:01 <dhellmann> asettle : some teams have had technical issues completing the work, but it's still in progress
15:55:03 <ricolin> mnaser, so are we keep the community-goals etherpad so we can looking for goals for future releases?
15:55:10 <asettle> evrardjp, yes, I saw that. We don't have any projects still functioning on py2 though, do we? Like, everything is defaulted to py3?
15:55:10 <evrardjp> I think my intent was not clear in what I said -- We need to think the user facing value
15:55:15 <mnaser> yes ricolin that's how we kinda maintain it overall
15:55:21 <smcginnis> asettle: We currently support both 2 and 3, with the stated plan of looking at dropping 2 in the U release.
15:55:40 <mnaser> and i agree with evrardjp.  paste is rpetty stable and doesn't really change as much.  afaik cdent took it over too so we can maintain it somewhat
15:55:44 <ricolin> mnaser, than I think we should put RABC and paste into that etherpad:)
15:55:52 <mnaser> paste is already there under #3
15:55:57 <asettle> Mayhaps I'm being a little too literal - but to me this is the other half of finish what you started. If we require a second goal, starting the work on removing py2 seems like the logical next step
15:56:11 <evrardjp> It's a nice thing to remove paste, don't get me wrong
15:56:31 <mnaser> please, let's try to focus if the osc client goal removal is a thing
15:56:32 <asettle> It would also help push projects to finish the original goal
15:56:48 <mnaser> we can decide about those details later of another second potential goal
15:56:59 <asettle> Sorry, yes
15:57:02 <evrardjp> mnaser: I think it's a nice goal
15:57:19 <asettle> (yes it's got a lovely personality, good at dinner parities evrardjp :p )
15:57:20 <adriant> mnaser: standalone client deprecation in favor of OSC as the CLI is a good goal, but should also include switching to the SDK as the main python client
15:57:42 <adriant> or at least lead into the latter
15:57:44 <dhellmann> we've said we weren't going to drop python2 support until the U cycle
15:57:45 * dhellmann looks at the clock again
15:57:54 <dhellmann> #link https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-timeline.html
15:57:57 <gmann> yeah
15:58:06 <mnaser> yeah i feel so far all we've managed to accomplish is figure out the project deletion goal is not ideal
15:58:10 <asettle> dhellmann, good to know
15:58:23 <mnaser> and then also it seems that everyone is half unsure about the OSC one
15:58:25 <asettle> mnaser, lots to talk about? Perhaps an agenda might not have been such an bad idea o.0
15:58:31 <evrardjp> I didn't want to bring py2 on the table -- that was just an example ! I should have shut up.
15:58:36 <asettle> (strict agenda, I mean)
15:58:46 <asettle> evrardjp, sorry I took that and ran with it.
15:59:09 <mnaser> sorry, i dropped the ball on properly planning this.  we started from discussing the goals to moving to finding other goals because those apparently don't seem to fit as well
15:59:37 <mnaser> i don't know if we should _discuss_ them more often, or if we should review more often.  but i think _now_ is really not a good time for us to realize it's not a good fit
15:59:49 <asettle> Not at all mnaser - sorry for insinuating that. This was an office hours casual chat.
15:59:52 <mnaser> i also don't want us to just leap forward "just cause"
16:00:04 <asettle> Fair
16:00:10 <ttx> need to jump to release meeting
16:00:12 * fungi can't wait to read all 400 lines of this ;)
16:00:19 <fungi> (after the release meeting)
16:00:26 * dhellmann also needs to change meetings
16:00:28 <mnaser> does anyone feel like we have some homework after this?
16:00:44 <asettle> Indeed
16:00:51 <lbragstad> i think i do
16:01:11 <adriant> I'll write up an email about dropping the project deletion goal, and that we intend to still do it, but not as a goal.
16:01:32 <mnaser> thanks adriant
16:01:49 <zaneb> I feel like we need to reconvene and discuss the OSC goal specifically, with the parts needed to achieve the project deletion thing front and centre
16:01:51 <adriant> and I'll have a chat with monty and see how willing he is with helping design and implement it along with me. But chances are more eyes on that work will be good.
16:02:00 <dhellmann> zaneb : ++
16:02:03 <evrardjp> thanks adriant
16:02:13 * gmann need to jump to qa office hour
16:02:16 <adriant> zaneb: full support for the SDK from each project would be amazing!
16:02:22 <mnaser> ok, i'll end for now and we can keep talking within office hours
16:02:24 <mnaser> #endmeeting