15:01:29 #startmeeting tc-goals 15:01:30 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 o/ 15:01:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:33 The meeting name has been set to 'tc_goals' 15:01:48 cool thanks for coming here everyone 15:02:13 yay! i'm online 15:02:19 o/ 15:02:21 * fungi is trying to lurk, but also in a couple other meetings 15:02:32 my home internet died minutes before the meeting... 15:02:41 i'm hotspoting off my phone... 15:02:42 better than during it adriant :) 15:02:58 adriant: limited data plan? 15:02:59 i've got _some_ sort of very basic etherpad to start on 15:03:05 https://etherpad.openstack.org/p/project-goal-meeting 15:03:34 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 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 o/ 15:03:48 o/ 15:04:00 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 i'll let him take it from here 15:04:20 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 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 this feels like a much much smaller thing that could be done iteratively by a small group 15:05:24 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 what do the rest of you think? 15:06:20 i agree, and i think this thread is applicable to the other goal under review as well 15:06:28 dhellmann: you mean the part-1 of this goal, in that i agree with your point. 15:06:42 but part-2 still need interface from each services 15:06:57 lbragstad: I think it's even smaller grasp for the other goal 15:07:01 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 are we talking about doing part 2 during train? 15:07:22 jroll: that's why the original plan was a plugin based solution 15:07:32 I think this is highlighting (again) that we don't have a process for driving changes like this 15:07:34 sure 15:07:34 jroll: plugins? 15:07:37 we can always reconsider doing part 2 in train 15:07:37 ok, let's leave the part-2 separate (away from train) 15:07:41 haha ok adriant :) 15:07:58 adriant : I think the plugin solution was adding unnecessary technical complication just to make it fit the goals process 15:08:14 zaneb : yes, you're right 15:08:20 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 dhellmann: I don't disagree that plugins over-complicated it 15:08:55 it seems to fit a popup team or even help-most-needed item better than the community-wide goals process 15:09:02 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 and if this ultimately isn't right for a goal, then it isn't. 15:09:10 at the same time, i wonder if we feel pressure to actually have community goals? 15:09:14 but it does need some TC support to get done 15:09:42 because any official attempt to solve project deletion has sadly kind of failed before :( 15:09:55 that's a different problem adriant 15:10:05 imo 15:10:05 I think release goals involve some overhead to track that work lands in every project team 15:10:14 dhellmann, popup indeed, if we only consider doing phase 1 in train 15:10:17 I agree, and that's why maybe it isn't idea for a goal 15:10:19 adriant : I think the SDK team (at least via mordred) have expressed that they would be interested in supporting this feature 15:10:41 Here we get the goal overhead, but for stuff that ultimately does not require that much coordination work 15:11:02 It really needs $people, not $coordination 15:11:12 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 that and it leaves several projects wondering "um, what are we supposed to do for this, again?" 15:11:22 the OSC centralization goal is slightly different, in that we would be asking every team to deprecate their client (IIUC) 15:11:44 yeah, it seems to have at least /some/ per-project work 15:11:47 I guess it depends if we consider part2 or not 15:12:00 it's just a bit pessimistic and assumes only one team will complete the goal :) 15:12:12 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 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 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 zaneb: ++ 15:12:33 there are actually some services which don't have admin level delete resources as an admin 15:12:43 so that is needed and could be goal driven potentilly 15:12:49 potentially* 15:12:57 zaneb : it depends on what "the feature" means? is that the OSC or deletion goal? 15:13:24 dhellmann: deletion goal, but it means OSC support for deleting the resources IIUC 15:13:34 adriant: and we need project team involvement in at least 'dependency tree build for their resource' ? 15:13:34 dhellmann: as in, full service/resource support in the SDK would be needed so we can actually query/delete it. 15:13:44 adriant : depending on how many, yes. we may want to document expectations for admin APIs more formally than we have 15:13:51 gmann: maybe 15:13:52 which services does that apply to today? 15:14:19 dhellmann: some one commented about it in the review, but I forget who (will look later). 15:14:26 i think sahara it was if i remember 15:14:32 yeah Sahara sounds right 15:14:43 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 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 and then get someone with some sahara knowledge to help with that part 15:15:37 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 i agree with adriant that this is something that seems _so_ obvious, but not inside openstack 15:15:58 API level changes probably would 15:16:10 mnaser: sure, that requires stuff to land everywhere, and then the tracking overhead in goals is justified 15:16:15 but API level changes needs A LOT of thought and design work 15:16:16 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 bulk deletion APIs would solve a lot of the issues 15:16:51 We should definitely not adopt a weird implementation just so that it can fit the artificial goal process 15:16:51 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 and allow the SDK work to become the core of the deletion logic with efficient ways to do it. 15:16:58 i agree, ttx. 15:17:05 yeah, either way API or any other intrerface that need project side implementation 15:17:08 it makes the "just go away" mode simpler, but introduces more complexity with dealing with dependency cleanup between services 15:17:12 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 we do allow them, we just don't have them 15:17:28 these apis just don't exist 15:17:29 (probably shouldn't call myself a moron on a recorded meeting) 15:17:35 we do have a lot of cross-project dependencies though 15:17:45 Gotcha. 15:17:47 yeah not all project have bulk deletion API 15:17:50 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 so that can fail miserably 15:18:04 it also requires projects to grok new authorization concepts 15:18:06 asettle: too late 15:18:19 ttx, *shrug* how bad could it be 15:18:20 ttx: :) 15:18:29 which is where building some dependency stuff is useful. and find the points where you can bulk delete :/ 15:18:35 lbragstad: you mean scope type things ? 15:18:41 adriant, makes sense 15:18:41 Thanks all 15:18:53 gmann correct - in the API level approach for each service 15:18:56 i agree in the value, but i feel what dhellmann brings up is a strong point 15:19:11 which is, for train, if we do step 1 only, it seems like a community effort 15:19:52 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 yeah, I really really really want this to happen 15:20:43 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 essentially, yes we need this 15:20:55 (I think we have a Forum session to discuss other ways we might drive these sorts of changes) 15:21:14 but once we have it, the services have to commit to helping maintain it and their resources in the SDK 15:21:28 it can't just be on the SDK team 15:21:35 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 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 adriant: that is hard part. project team maintaining it in SDK would not success always 15:22:20 unless SDK team builds tests 15:22:22 yes each service owns their own python-client, but that's soon to be deprecated 15:22:24 which run in gates 15:22:54 the SDK will be the main and primary client 15:23:12 so shouldn't all the services have some ownership there? 15:23:33 and in turn, support deletion features for their existing and new resources there? 15:23:52 that's a bigger topic, but applicable to this 15:24:14 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 yeah, that's the part where it seems like a goal might be most applicable 15:24:29 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 Combining both part together as goal is something we should do even that can take 2 cycle 15:25:02 the issue is finding a consensus on what part 2 looks like 15:25:09 what should the delete API be? 15:25:16 bulk delete? Orchestrated deleted? 15:25:28 what was something we brought up in berlin's forum session 15:25:45 that's why I want to put that off until we have the client side work 15:25:55 s/what/that/ 15:26:10 because we can look at the dependencies in a better light, and then thing about where the APIs would help 15:26:22 think* 15:26:25 there was an action item to write up what the delete APIs would look like, then we can pick them apart 15:26:49 maybe we should focus on the scope of work proposed for this cycle 15:27:01 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 yeah, i think we need to decide the best interface which project team can maintain and comfortable with. 15:27:18 like say, maybe, RBAC support which keystone has put the foundation to 15:27:42 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 I'd support a readonly rolein openstack as a goal :P 15:27:48 mnaser, that sounds like a popup team material 15:28:04 RBAC is something each project can implement in their policy 15:28:25 mnaser: they really can't 15:28:35 huh? 15:28:47 some have hardcoded policy logic 15:29:00 at least I think that's what he means... 15:29:06 mnaser: if other projects don't respect the same RBAC policies then they're worse than useless 15:29:39 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 mnaser: correct 15:29:57 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 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 aka i cant have 'domain' admins 15:30:33 are we talking about a new goal now? or did we drift off track? 15:30:36 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 dhellmann: I have the impression 15:31:04 my (non committed idea) was that we can split the delete one into two goals 15:31:12 the first one is just to get a group of people to prepare for it 15:31:13 mnaser: lbragstad has been plugging away at that for a while now 15:31:28 mnaser, +1 15:31:29 and that way we have a _proper_ infrastructure for U goal to bulk delete 15:31:39 so rather than having a goal in a cycle where only 1/2 of it is done.. 15:31:44 I can live with that 15:32:05 but then again, im just throwing this out there. 15:32:06 I agree that any goal that doesn't fit in a cycle should be split into smaller goals that do 15:32:07 so how do we structure whatever portion of that work we want done in train? 15:32:21 dhellmann: this is where we can discuss at the ptg/forum to come up with that "platform" 15:32:32 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 that allows us to get work done on *community* work that is not yet goal level 15:32:57 or whatever infrastructure we want to put in place, as what zaneb was talking about earlier 15:32:58 mnaser : I'm confused. Are you saying we should wait until the PTG to pick goals? 15:33:17 sounds too late to me 15:33:28 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 teams need to know what they are up to as they discuss other priorities 15:33:47 ok 15:33:51 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 ok 15:34:15 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 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 I added "popup teams" to https://etherpad.openstack.org/p/tc-train-ptg 15:34:52 a cross project project? with their own stories/bugs and PTL? :P 15:35:06 Gawd 15:35:16 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 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 s/you/if/ 15:36:29 standardizing roles feels like a good goal, but do you think we'd have time to organize that for train? 15:36:53 maybe? it will be close 15:37:03 * lbragstad looks for a magic wand 15:37:04 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 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 mnaser : is it? or would it just not be done yet? 15:37:27 mnaser++ 15:37:34 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 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 dhellmann: it's essentially useless until everybody does it, so that's a good candidate for a goal 15:37:53 so we can pretty much _never_ get rbac if $foo decides they dont want to get it done 15:38:11 ok, that makes sense 15:38:40 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 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 ++ 15:39:07 RBAC fits that bill, imo 15:39:09 mnaser: to be clear, you mean "never get good default rbac", right? 15:39:11 (for some definition of "every". Can be "most") 15:39:43 we can still have lame manual rbac by editing policy files and such 15:39:59 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 I am confused what's here proposed 15:40:08 good defaults RBAC is not there and it may needs lot of work depends on how good/bad projects policy are 15:40:11 when in reality, you wanted to give someone admin access to a project 15:40:19 mnaser: ah right, gotcha. 15:40:21 thanks 15:40:25 evrardjp : we've gone into the weeds of rbac implementation again 15:40:31 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 yes indeed 15:40:47 well then let's take a step back 15:40:52 so basically we'll need to go through the details of personas and stuff? 15:41:02 evrardjp: keystone team already did all of that 15:41:08 teams literally just have to implement the policy, thats all 15:41:17 but we change it, for the new usage :p 15:41:21 admin/member/reader and system/domain/project scope 15:41:22 I think we NEED rbac work, but remember that ultimately policy and which roles are created is up to the deployer 15:41:23 adriant: isn't that better than the current insane defaults and deployers can still screw it up? 15:41:32 ok let's take a step back 15:41:33 zaneb: I totally agree 15:41:35 mnaser: "implement the policy" or "improve the policy" ? 15:41:40 I we need something better 15:41:44 gmann: good question. 15:41:56 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 any saner default rbac and roles is better than what we have now 15:42:36 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 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 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 mnaser, no disagreement. But ack ricolin - need to make sure it's owned by a central body before we move on. 15:43:19 i'm saying it doesn't fit under "cycle goals" 15:43:24 Or at least, an action item somewhere to ensure it's covered. 15:43:26 mnaser: as the person proposing the goal, yes I agree that it does not fit the goal process 15:43:26 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 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 adriant++ 15:44:25 adriant, + 15:44:27 adriant: absolutely, hence the discussion at ptg/forum which i think dhellmann mentioned they added 15:44:28 because there are a lot of small things like this, which need that push to get done 15:44:43 https://etherpad.openstack.org/p/tc-train-ptg <-- popup teams here 15:44:49 so we're def going to make sure we cover it 15:44:55 and "Goal selection retrospective" in there too 15:44:58 yes, something that makes at least as much noise as the goals process, to attract as much attention 15:45:05 absolutely 15:45:09 ttx: ++ 15:45:13 yes, that 15:45:18 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 ok, so that means we're in a place where we need a 2nd goal 15:45:23 but better suited in recruiting a small dedicated team of people to accomplish one objective 15:45:42 or rather a goal to replace the project delete one for Train 15:45:52 ttx: so a working group? :P 15:46:05 mnaser : what's the status of the testing platform upgrade? 15:46:11 adriant: I think it needs a more shiny name 15:46:15 that lingered during stein, is it done now? 15:46:18 dumb question: do we *need* 2 goals? why? 15:46:19 not "YAWG" 15:46:29 (yet another working group) 15:46:30 jroll, not dumb question. Would be good to know. 15:46:48 dhellmann: so moving towards bionic? i think we're in a good place and that's mostly done 15:46:52 Maybe "DAWG" (dang, another working group) 15:46:53 ttx, common! it can be YASIG! 15:46:59 ttx: YAWN: yet another working (group) name 15:47:04 Yo Dawg 15:47:05 gmann: probably can comment better about that 15:47:26 !addquote Yo Dawg 15:47:27 mnaser: Error: "addquote" is not a valid command. 15:47:30 this one is for the books 15:47:30 mnaser: dhellmann we left with 5-6 patches to land on project side to move project specific jobs to bionic 15:47:30 :P 15:47:49 and trove and networking-midonet are the one which need some work to do before that 15:48:03 gmann : ok, so that's done enough that we probably don't need to consider it a goal this time? 15:48:14 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 https://imgflip.com/i/2wlm8n 15:48:24 Oh, actually a goal suggestion: Move off Paste 15:48:27 dhellmann: yeah, thats does not need to be in goal 15:48:49 Paste is pretty much used by almost all services, and is on life support 15:48:58 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 disturbing 15:49:11 and a lot of services also use eventlet, which also should go away... 15:49:12 as a reminder, here's our goal backlog: https://etherpad.openstack.org/p/community-goals 15:49:22 legacy jobs are pain whenever any updates we need to do on gate things 15:49:23 either of those could be community wide goal 15:49:27 goals* 15:49:36 Paste seems like a good start. 15:49:57 do we have enough of any of those worked out to have them documented before the ptg? 15:50:11 dumb question: do we *need* 2 goals? why? 15:50:16 * jroll asks again 15:50:21 jroll: not really 15:50:26 jroll: no 15:50:27 do we have any at all right now? 15:50:36 we have the osc legacy client killing 15:50:39 I'm fine with a single large goal 15:50:40 well okay 15:50:49 legacy client deprecation in favour of osc 15:50:55 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 maybe we should talk about the client goal in more detail then? 15:51:01 * dhellmann looks at the clock 15:51:16 Not even deprecation, right? Just getting osc caught up. 15:51:17 maybe we can be a bit more optimistic if that's the only train goal 15:51:18 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 (a train goal is called a destination) 15:51:29 https://review.openstack.org/#/c/639376/ 15:51:38 dhellmann, see note above 15:51:42 it seems to me that this goal fits the fact it's team-based 15:51:45 asettle: I believe so 15:51:46 so i am not really opposed to it 15:51:47 asettle : that etherpad may be out of date 15:52:01 Ah right. Cause that wasn't the only one I thought had been done 15:52:16 maybe mnaser wants a volunteer to prune the backlog there 15:52:22 That would be really heplful. 15:52:24 helpful* 15:52:44 * mnaser takes notes 15:52:49 number 3 is basically: Get rid of Paste 15:52:59 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 adriant, heh 15:53:05 yes 15:53:18 that is a legitimately good goal 15:53:29 and doesn't need a major amount of work to define 15:53:30 does anyone object under the the "Move legacy client CLIs to OSC goal to Train" goal? 15:53:47 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 evrardjp: paste is deprecated and unsupported 15:54:10 so you should 15:54:12 mnaser i think that goal needs to have it's criteria broken into separate lists 15:54:18 yes, so will python2 next year 15:54:23 evrardjp: as an operator, paste is annoying 15:54:24 we can discuss the other goal soon 15:54:24 it could use more detail, yeah 15:54:31 jroll: yes kinda 15:54:32 We don't still have any projects on py2, do we? 15:54:32 mnaser: I don't object to the idea, I haven't read the latest iteration 15:54:37 That was a ocata/pike goal 15:54:38 otherwise it feels similar to the project deletion goal in that it is very specific to only a handful of projects 15:54:46 asettle: we still carry it 15:55:01 asettle : some teams have had technical issues completing the work, but it's still in progress 15:55:03 mnaser, so are we keep the community-goals etherpad so we can looking for goals for future releases? 15:55:10 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 I think my intent was not clear in what I said -- We need to think the user facing value 15:55:15 yes ricolin that's how we kinda maintain it overall 15:55:21 asettle: We currently support both 2 and 3, with the stated plan of looking at dropping 2 in the U release. 15:55:40 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 mnaser, than I think we should put RABC and paste into that etherpad:) 15:55:52 paste is already there under #3 15:55:57 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 It's a nice thing to remove paste, don't get me wrong 15:56:31 please, let's try to focus if the osc client goal removal is a thing 15:56:32 It would also help push projects to finish the original goal 15:56:48 we can decide about those details later of another second potential goal 15:56:59 Sorry, yes 15:57:02 mnaser: I think it's a nice goal 15:57:19 (yes it's got a lovely personality, good at dinner parities evrardjp :p ) 15:57:20 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 or at least lead into the latter 15:57:44 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 #link https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-timeline.html 15:57:57 yeah 15:58:06 yeah i feel so far all we've managed to accomplish is figure out the project deletion goal is not ideal 15:58:10 dhellmann, good to know 15:58:23 and then also it seems that everyone is half unsure about the OSC one 15:58:25 mnaser, lots to talk about? Perhaps an agenda might not have been such an bad idea o.0 15:58:31 I didn't want to bring py2 on the table -- that was just an example ! I should have shut up. 15:58:36 (strict agenda, I mean) 15:58:46 evrardjp, sorry I took that and ran with it. 15:59:09 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 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 Not at all mnaser - sorry for insinuating that. This was an office hours casual chat. 15:59:52 i also don't want us to just leap forward "just cause" 16:00:04 Fair 16:00:10 need to jump to release meeting 16:00:12 * fungi can't wait to read all 400 lines of this ;) 16:00:19 (after the release meeting) 16:00:26 * dhellmann also needs to change meetings 16:00:28 does anyone feel like we have some homework after this? 16:00:44 Indeed 16:00:51 i think i do 16:01:11 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 thanks adriant 16:01:49 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 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 zaneb : ++ 16:02:03 thanks adriant 16:02:13 * gmann need to jump to qa office hour 16:02:16 zaneb: full support for the SDK from each project would be amazing! 16:02:22 ok, i'll end for now and we can keep talking within office hours 16:02:24 #endmeeting