| *** lbragstad has quit IRC | 00:14 | |
| *** jamesmcarthur has quit IRC | 00:27 | |
| *** jamesmcarthur has joined #openstack-tc | 00:58 | |
| *** jamesmcarthur has quit IRC | 01:15 | |
| *** jamesmcarthur has joined #openstack-tc | 01:16 | |
| *** mriedem has quit IRC | 01:26 | |
| *** ricolin has joined #openstack-tc | 01:29 | |
| *** lbragstad has joined #openstack-tc | 01:35 | |
| *** jamesmcarthur has quit IRC | 01:39 | |
| *** jamesmcarthur has joined #openstack-tc | 01:40 | |
| *** jamesmcarthur has quit IRC | 01:44 | |
| *** jamesmcarthur has joined #openstack-tc | 02:35 | |
| *** jamesmcarthur has quit IRC | 02:59 | |
| *** jamesmcarthur has joined #openstack-tc | 03:04 | |
| *** jamesmcarthur has quit IRC | 03:18 | |
| *** jamesmcarthur has joined #openstack-tc | 03:19 | |
| *** jamesmcarthur has quit IRC | 03:49 | |
| *** whoami-rajat has joined #openstack-tc | 04:11 | |
| *** diablo_rojo has quit IRC | 04:12 | |
| *** marst has joined #openstack-tc | 04:28 | |
| *** marst has quit IRC | 04:45 | |
| *** ricolin has quit IRC | 05:15 | |
| *** ricolin has joined #openstack-tc | 05:32 | |
| *** lbragstad has quit IRC | 06:06 | |
| *** e0ne has joined #openstack-tc | 06:06 | |
| *** e0ne has quit IRC | 06:07 | |
| *** Luzi has joined #openstack-tc | 06:44 | |
| *** e0ne has joined #openstack-tc | 07:45 | |
| *** openstackgerrit has quit IRC | 08:17 | |
| *** dtantsur|afk is now known as dtantsur | 08:24 | |
| *** tosky has joined #openstack-tc | 08:27 | |
| *** jpich has joined #openstack-tc | 08:31 | |
| *** e0ne has quit IRC | 08:48 | |
| *** e0ne has joined #openstack-tc | 08:51 | |
| asettle | Morning o/ | 09:01 |
|---|---|---|
| evrardjp | morning | 09:03 |
| *** whoami-rajat has quit IRC | 09:10 | |
| *** whoami-rajat has joined #openstack-tc | 09:18 | |
| ricolin | morning | 09:26 |
| mugsie | o/ | 10:06 |
| *** cdent has joined #openstack-tc | 10:08 | |
| *** zbr has quit IRC | 10:08 | |
| *** zbr has joined #openstack-tc | 10:10 | |
| *** e0ne has quit IRC | 10:14 | |
| *** zbr has quit IRC | 10:16 | |
| *** e0ne has joined #openstack-tc | 10:17 | |
| *** openstackgerrit has joined #openstack-tc | 10:47 | |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Appoint Weng Hao as Zaqar PTL https://review.openstack.org/645121 | 10:47 |
| ttx | hmm missed the appointed key. Will repost | 10:49 |
| *** jaosorior has quit IRC | 10:53 | |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Appoint Trinh Nguyen as Telemetry PTL https://review.openstack.org/645122 | 10:53 |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Appoint Weng Hao as Zaqar PTL https://review.openstack.org/645121 | 10:55 |
| *** e0ne has quit IRC | 10:58 | |
| *** e0ne has joined #openstack-tc | 10:59 | |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Appoint Divya K Konoor as PowerVMStackers PTL https://review.openstack.org/645126 | 11:03 |
| ttx | tc-members: those ^ should support the Train PTL appointment discussion. If you have alternate solutions please post them as reviews as well | 11:04 |
| *** whoami-rajat has quit IRC | 11:30 | |
| *** whoami-rajat has joined #openstack-tc | 11:34 | |
| *** zbr has joined #openstack-tc | 11:39 | |
| *** jaosorior has joined #openstack-tc | 11:51 | |
| *** cdent has quit IRC | 12:04 | |
| *** jamesmcarthur has joined #openstack-tc | 12:11 | |
| *** jamesmcarthur has quit IRC | 12:30 | |
| *** jamesmcarthur has joined #openstack-tc | 12:31 | |
| *** jamesmcarthur has quit IRC | 12:35 | |
| *** ijolliffe has joined #openstack-tc | 12:36 | |
| dhellmann | asettle : I added a few items to the ptg planning etherpad and added lines for folks to sign up to lead the discussion and express interest so we can see what people actually want to talk about | 12:37 |
| *** mriedem has joined #openstack-tc | 12:38 | |
| dhellmann | mnaser : am I right that the outcome of the poll for the goal discussion was to use today's office hour slot? | 12:49 |
| mnaser | dhellmann: yep, I think I updated the ML on that. I hope I didn’t just update the ML in my head only | 12:50 |
| dhellmann | I think I remember seeing that, but I'm a bit behind | 12:50 |
| dhellmann | thanks for confirming :-) | 12:50 |
| *** e0ne has quit IRC | 12:51 | |
| *** dtantsur is now known as dtantsur|brb | 12:52 | |
| *** lbragstad has joined #openstack-tc | 12:54 | |
| *** irclogbot_2 has quit IRC | 13:07 | |
| *** irclogbot_2 has joined #openstack-tc | 13:09 | |
| fungi | mnaser did post the results to the ml. i know since i responded to them about being unavailable | 13:10 |
| fungi | but looking forward to seeing the outcome of the discussion | 13:10 |
| *** jamesmcarthur has joined #openstack-tc | 13:10 | |
| fungi | i may still lurk, but also have some stuff i need to bring up in another irc meeting at the same time *and* scheduled to be on a conference call at that time too | 13:11 |
| *** marst has joined #openstack-tc | 13:21 | |
| asettle | dhellmann, thank you | 13:21 |
| *** altlogbot_3 has quit IRC | 13:23 | |
| *** e0ne has joined #openstack-tc | 13:23 | |
| *** altlogbot_0 has joined #openstack-tc | 13:25 | |
| *** e0ne has quit IRC | 13:37 | |
| *** altlogbot_0 has quit IRC | 13:39 | |
| *** whoami-rajat has quit IRC | 13:40 | |
| *** altlogbot_3 has joined #openstack-tc | 13:41 | |
| *** marst has quit IRC | 13:42 | |
| *** irclogbot_2 has quit IRC | 13:45 | |
| *** e0ne has joined #openstack-tc | 13:45 | |
| *** jaypipes has quit IRC | 13:46 | |
| *** irclogbot_2 has joined #openstack-tc | 13:47 | |
| *** adriant has quit IRC | 13:51 | |
| *** adriant has joined #openstack-tc | 13:52 | |
| *** marst has joined #openstack-tc | 13:56 | |
| adriant | mnaser: that goal related discussion, isn't that nowish? Or did i get my NZ vs UTC times wrong? | 14:14 |
| *** jaosorior has quit IRC | 14:15 | |
| adriant | in like 45mins right? | 14:15 |
| lbragstad | i believe so adriant | 14:16 |
| adriant | alright, cool, will stick around as being the person suggesting one of the goals it may be worth hanging around for that | 14:17 |
| * lbragstad nods | 14:17 | |
| lbragstad | thanks | 14:17 |
| *** whoami-rajat has joined #openstack-tc | 14:23 | |
| *** jamesmcarthur has quit IRC | 14:29 | |
| *** jamesmcarthur has joined #openstack-tc | 14:35 | |
| *** altlogbot_3 has quit IRC | 14:35 | |
| *** altlogbot_2 has joined #openstack-tc | 14:37 | |
| *** dtantsur|brb is now known as dtantsur | 14:37 | |
| *** irclogbot_2 has quit IRC | 14:38 | |
| *** irclogbot_0 has joined #openstack-tc | 14:39 | |
| mnaser | adriant: can i buy you coffee | 14:56 |
| mnaser | because right now that's aw hole another definition of being a goal champion :) | 14:56 |
| * gmann sorry for late | 14:59 | |
| mnaser | tc-members: office hours are here! | 15:00 |
| mnaser | do we feel like using meetbot to get some sort of referencable logging? | 15:00 |
| evrardjp | I don't mind | 15:00 |
| mnaser | unless someone is opposed to it, i only see benefits | 15:00 |
| asettle | Ditto. | 15:00 |
| * jroll doesn't mind | 15:00 | |
| gmann | o/ | 15:00 |
| evrardjp | I think we didn't do it because people could consider it was too formal to start to casually speak during office hours | 15:01 |
| mnaser | yeah | 15:01 |
| ricolin | mnaser, that give you the benefits to get `action` recorded | 15:01 |
| dhellmann | o/ | 15:01 |
| asettle | That's a good point too | 15:01 |
| mnaser | sounds good to meh | 15:01 |
| gmann | as this is adhoc meeting too so we can do | 15:01 |
| mnaser | #startmeeting tc-goals | 15:01 |
| 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 |
| lbragstad | o/ | 15:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| *** openstack changes topic to " (Meeting topic: tc-goals)" | 15:01 | |
| openstack | The meeting name has been set to 'tc_goals' | 15:01 |
| mnaser | cool thanks for coming here everyone | 15:01 |
| adriant | yay! i'm online | 15:02 |
| ttx | o/ | 15:02 |
| * fungi is trying to lurk, but also in a couple other meetings | 15:02 | |
| adriant | my home internet died minutes before the meeting... | 15:02 |
| adriant | i'm hotspoting off my phone... | 15:02 |
| evrardjp | better than during it adriant :) | 15:02 |
| evrardjp | adriant: limited data plan? | 15:02 |
| mnaser | i've got _some_ sort of very basic etherpad to start on | 15:02 |
| mnaser | https://etherpad.openstack.org/p/project-goal-meeting | 15:03 |
| 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 |
| 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 |
| dhellmann | o/ | 15:03 |
| zaneb | o/ | 15:03 |
| 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 |
| mnaser | i'll let him take it from here | 15:04 |
| 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 |
| 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 |
| dhellmann | this feels like a much much smaller thing that could be done iteratively by a small group | 15:04 |
| 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 |
| dhellmann | what do the rest of you think? | 15:05 |
| lbragstad | i agree, and i think this thread is applicable to the other goal under review as well | 15:06 |
| gmann | dhellmann: you mean the part-1 of this goal, in that i agree with your point. | 15:06 |
| gmann | but part-2 still need interface from each services | 15:06 |
| evrardjp | lbragstad: I think it's even smaller grasp for the other goal | 15:06 |
| 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 |
| dhellmann | are we talking about doing part 2 during train? | 15:07 |
| adriant | jroll: that's why the original plan was a plugin based solution | 15:07 |
| zaneb | I think this is highlighting (again) that we don't have a process for driving changes like this | 15:07 |
| jroll | sure | 15:07 |
| evrardjp | jroll: plugins? | 15:07 |
| adriant | we can always reconsider doing part 2 in train | 15:07 |
| gmann | ok, let's leave the part-2 separate (away from train) | 15:07 |
| evrardjp | haha ok adriant :) | 15:07 |
| dhellmann | adriant : I think the plugin solution was adding unnecessary technical complication just to make it fit the goals process | 15:07 |
| dhellmann | zaneb : yes, you're right | 15:08 |
| 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 |
| adriant | dhellmann: I don't disagree that plugins over-complicated it | 15:08 |
| dhellmann | it seems to fit a popup team or even help-most-needed item better than the community-wide goals process | 15:08 |
| 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 |
| adriant | and if this ultimately isn't right for a goal, then it isn't. | 15:09 |
| lbragstad | at the same time, i wonder if we feel pressure to actually have community goals? | 15:09 |
| adriant | but it does need some TC support to get done | 15:09 |
| adriant | because any official attempt to solve project deletion has sadly kind of failed before :( | 15:09 |
| evrardjp | that's a different problem adriant | 15:09 |
| evrardjp | imo | 15:10 |
| ttx | I think release goals involve some overhead to track that work lands in every project team | 15:10 |
| ricolin | dhellmann, popup indeed, if we only consider doing phase 1 in train | 15:10 |
| adriant | I agree, and that's why maybe it isn't idea for a goal | 15:10 |
| dhellmann | adriant : I think the SDK team (at least via mordred) have expressed that they would be interested in supporting this feature | 15:10 |
| ttx | Here we get the goal overhead, but for stuff that ultimately does not require that much coordination work | 15:10 |
| ttx | It really needs $people, not $coordination | 15:11 |
| 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 |
| lbragstad | that and it leaves several projects wondering "um, what are we supposed to do for this, again?" | 15:11 |
| dhellmann | the OSC centralization goal is slightly different, in that we would be asking every team to deprecate their client (IIUC) | 15:11 |
| ttx | yeah, it seems to have at least /some/ per-project work | 15:11 |
| evrardjp | I guess it depends if we consider part2 or not | 15:11 |
| ttx | it's just a bit pessimistic and assumes only one team will complete the goal :) | 15: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 |
| 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 |
| 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 |
| ttx | zaneb: ++ | 15:12 |
| adriant | there are actually some services which don't have admin level delete resources as an admin | 15:12 |
| adriant | so that is needed and could be goal driven potentilly | 15:12 |
| adriant | potentially* | 15:12 |
| dhellmann | zaneb : it depends on what "the feature" means? is that the OSC or deletion goal? | 15:12 |
| zaneb | dhellmann: deletion goal, but it means OSC support for deleting the resources IIUC | 15:13 |
| gmann | adriant: and we need project team involvement in at least 'dependency tree build for their resource' ? | 15:13 |
| adriant | dhellmann: as in, full service/resource support in the SDK would be needed so we can actually query/delete it. | 15:13 |
| dhellmann | adriant : depending on how many, yes. we may want to document expectations for admin APIs more formally than we have | 15:13 |
| adriant | gmann: maybe | 15:13 |
| dhellmann | which services does that apply to today? | 15:13 |
| adriant | dhellmann: some one commented about it in the review, but I forget who (will look later). | 15:14 |
| gmann | i think sahara it was if i remember | 15:14 |
| adriant | yeah Sahara sounds right | 15:14 |
| 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:14 |
| 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 |
| dhellmann | and then get someone with some sahara knowledge to help with that part | 15:15 |
| 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 |
| mnaser | i agree with adriant that this is something that seems _so_ obvious, but not inside openstack | 15:15 |
| adriant | API level changes probably would | 15:15 |
| ttx | mnaser: sure, that requires stuff to land everywhere, and then the tracking overhead in goals is justified | 15:16 |
| adriant | but API level changes needs A LOT of thought and design work | 15: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 |
| adriant | bulk deletion APIs would solve a lot of the issues | 15:16 |
| ttx | We should definitely not adopt a weird implementation just so that it can fit the artificial goal process | 15:16 |
| 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 |
| adriant | and allow the SDK work to become the core of the deletion logic with efficient ways to do it. | 15:16 |
| mnaser | i agree, ttx. | 15:16 |
| gmann | yeah, either way API or any other intrerface that need project side implementation | 15:17 |
| dhellmann | it makes the "just go away" mode simpler, but introduces more complexity with dealing with dependency cleanup between services | 15:17 |
| 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 |
| dhellmann | we do allow them, we just don't have them | 15:17 |
| mnaser | these apis just don't exist | 15:17 |
| asettle | (probably shouldn't call myself a moron on a recorded meeting) | 15:17 |
| mnaser | we do have a lot of cross-project dependencies though | 15:17 |
| asettle | Gotcha. | 15:17 |
| gmann | yeah not all project have bulk deletion API | 15:17 |
| 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 |
| mnaser | so that can fail miserably | 15:17 |
| lbragstad | it also requires projects to grok new authorization concepts | 15:18 |
| ttx | asettle: too late | 15:18 |
| asettle | ttx, *shrug* how bad could it be | 15:18 |
| evrardjp | ttx: :) | 15:18 |
| adriant | which is where building some dependency stuff is useful. and find the points where you can bulk delete :/ | 15:18 |
| gmann | lbragstad: you mean scope type things ? | 15:18 |
| asettle | adriant, makes sense | 15:18 |
| asettle | Thanks all | 15:18 |
| lbragstad | gmann correct - in the API level approach for each service | 15:18 |
| mnaser | i agree in the value, but i feel what dhellmann brings up is a strong point | 15:18 |
| mnaser | which is, for train, if we do step 1 only, it seems like a community effort | 15:19 |
| 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:19 |
| zaneb | yeah, I really really really want this to happen | 15:20 |
| 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 |
| adriant | essentially, yes we need this | 15:20 |
| zaneb | (I think we have a Forum session to discuss other ways we might drive these sorts of changes) | 15:20 |
| adriant | but once we have it, the services have to commit to helping maintain it and their resources in the SDK | 15:21 |
| adriant | it can't just be on the SDK team | 15:21 |
| 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 |
| 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:21 |
| gmann | adriant: that is hard part. project team maintaining it in SDK would not success always | 15:22 |
| mnaser | unless SDK team builds tests | 15:22 |
| adriant | yes each service owns their own python-<service>client, but that's soon to be deprecated | 15:22 |
| mnaser | which run in gates | 15:22 |
| adriant | the SDK will be the main and primary client | 15:22 |
| adriant | so shouldn't all the services have some ownership there? | 15:23 |
| adriant | and in turn, support deletion features for their existing and new resources there? | 15:23 |
| adriant | that's a bigger topic, but applicable to this | 15:23 |
| 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 |
| zaneb | yeah, that's the part where it seems like a goal might be most applicable | 15:24 |
| 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 |
| gmann | Combining both part together as goal is something we should do even that can take 2 cycle | 15:24 |
| adriant | the issue is finding a consensus on what part 2 looks like | 15:25 |
| adriant | what should the delete API be? | 15:25 |
| *** Luzi has quit IRC | 15:25 | |
| adriant | bulk delete? Orchestrated deleted? | 15:25 |
| lbragstad | what was something we brought up in berlin's forum session | 15:25 |
| adriant | that's why I want to put that off until we have the client side work | 15:25 |
| lbragstad | s/what/that/ | 15:25 |
| adriant | because we can look at the dependencies in a better light, and then thing about where the APIs would help | 15:26 |
| adriant | think* | 15:26 |
| lbragstad | there was an action item to write up what the delete APIs would look like, then we can pick them apart | 15:26 |
| dhellmann | maybe we should focus on the scope of work proposed for this cycle | 15:26 |
| 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 |
| gmann | yeah, i think we need to decide the best interface which project team can maintain and comfortable with. | 15:27 |
| mnaser | like say, maybe, RBAC support which keystone has put the foundation to | 15:27 |
| *** jamesmcarthur has quit IRC | 15:27 | |
| 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 |
| adriant | I'd support a readonly rolein openstack as a goal :P | 15:27 |
| ricolin | mnaser, that sounds like a popup team material | 15:27 |
| mnaser | RBAC is something each project can implement in their policy | 15:28 |
| zaneb | mnaser: they really can't | 15:28 |
| mnaser | huh? | 15:28 |
| adriant | some have hardcoded policy logic | 15:28 |
| adriant | at least I think that's what he means... | 15:29 |
| zaneb | mnaser: if other projects don't respect the same RBAC policies then they're worse than useless | 15:29 |
| 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 |
| zaneb | mnaser: correct | 15:29 |
| 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:29 |
| 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 |
| mnaser | aka i cant have 'domain' admins | 15:30 |
| dhellmann | are we talking about a new goal now? or did we drift off track? | 15:30 |
| 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 |
| evrardjp | dhellmann: I have the impression | 15:30 |
| mnaser | my (non committed idea) was that we can split the delete one into two goals | 15:31 |
| mnaser | the first one is just to get a group of people to prepare for it | 15:31 |
| zaneb | mnaser: lbragstad has been plugging away at that for a while now | 15:31 |
| asettle | mnaser, +1 | 15:31 |
| mnaser | and that way we have a _proper_ infrastructure for U goal to bulk delete | 15:31 |
| mnaser | so rather than having a goal in a cycle where only 1/2 of it is done.. | 15:31 |
| adriant | I can live with that | 15:31 |
| mnaser | but then again, im just throwing this out there. | 15:32 |
| zaneb | I agree that any goal that doesn't fit in a cycle should be split into smaller goals that do | 15:32 |
| dhellmann | so how do we structure whatever portion of that work we want done in train? | 15:32 |
| mnaser | dhellmann: this is where we can discuss at the ptg/forum to come up with that "platform" | 15: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 |
| mnaser | that allows us to get work done on *community* work that is not yet goal level | 15:32 |
| mnaser | or whatever infrastructure we want to put in place, as what zaneb was talking about earlier | 15:32 |
| dhellmann | mnaser : I'm confused. Are you saying we should wait until the PTG to pick goals? | 15:32 |
| ttx | sounds too late to me | 15:33 |
| 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 |
| ttx | teams need to know what they are up to as they discuss other priorities | 15:33 |
| dhellmann | ok | 15:33 |
| 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:33 |
| dhellmann | ok | 15:34 |
| 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 |
| 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 |
| dhellmann | I added "popup teams" to https://etherpad.openstack.org/p/tc-train-ptg | 15:34 |
| adriant | a cross project project? with their own stories/bugs and PTL? :P | 15:34 |
| asettle | Gawd | 15:35 |
| 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:35 |
| 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 |
| lbragstad | s/you/if/ | 15:36 |
| dhellmann | standardizing roles feels like a good goal, but do you think we'd have time to organize that for train? | 15:36 |
| lbragstad | maybe? it will be close | 15:36 |
| * lbragstad looks for a magic wand | 15:37 | |
| 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 |
| 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 |
| dhellmann | mnaser : is it? or would it just not be done yet? | 15:37 |
| zaneb | mnaser++ | 15:37 |
| 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 |
| 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 |
| * dhellmann nods | 15:37 | |
| zaneb | dhellmann: it's essentially useless until everybody does it, so that's a good candidate for a goal | 15:37 |
| mnaser | so we can pretty much _never_ get rbac if $foo decides they dont want to get it done | 15:37 |
| dhellmann | ok, that makes sense | 15:38 |
| 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 |
| 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:38 |
| lbragstad | ++ | 15:39 |
| lbragstad | RBAC fits that bill, imo | 15:39 |
| jroll | mnaser: to be clear, you mean "never get good default rbac", right? | 15:39 |
| ttx | (for some definition of "every". Can be "most") | 15:39 |
| jroll | we can still have lame manual rbac by editing policy files and such | 15:39 |
| 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:39 |
| evrardjp | I am confused what's here proposed | 15:40 |
| gmann | good defaults RBAC is not there and it may needs lot of work depends on how good/bad projects policy are | 15:40 |
| mnaser | when in reality, you wanted to give someone admin access to a project | 15:40 |
| jroll | mnaser: ah right, gotcha. | 15:40 |
| jroll | thanks | 15:40 |
| dhellmann | evrardjp : we've gone into the weeds of rbac implementation again | 15:40 |
| 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 |
| evrardjp | yes indeed | 15:40 |
| mnaser | well then let's take a step back | 15:40 |
| evrardjp | so basically we'll need to go through the details of personas and stuff? | 15:40 |
| mnaser | evrardjp: keystone team already did all of that | 15:41 |
| mnaser | teams literally just have to implement the policy, thats all | 15:41 |
| evrardjp | but we change it, for the new usage :p | 15:41 |
| mnaser | admin/member/reader and system/domain/project scope | 15:41 |
| adriant | I think we NEED rbac work, but remember that ultimately policy and which roles are created is up to the deployer | 15:41 |
| zaneb | adriant: isn't that better than the current insane defaults and deployers can still screw it up? | 15:41 |
| mnaser | ok let's take a step back | 15:41 |
| adriant | zaneb: I totally agree | 15:41 |
| gmann | mnaser: "implement the policy" or "improve the policy" ? | 15:41 |
| adriant | I we need something better | 15:41 |
| evrardjp | gmann: good question. | 15:41 |
| 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:41 |
| adriant | any saner default rbac and roles is better than what we have now | 15:42 |
| 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 |
| 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:42 |
| 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 |
| asettle | mnaser, no disagreement. But ack ricolin - need to make sure it's owned by a central body before we move on. | 15:43 |
| mnaser | i'm saying it doesn't fit under "cycle goals" | 15:43 |
| asettle | Or at least, an action item somewhere to ensure it's covered. | 15:43 |
| adriant | mnaser: as the person proposing the goal, yes I agree that it does not fit the goal process | 15:43 |
| 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:43 |
| 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 |
| zaneb | adriant++ | 15:44 |
| ricolin | adriant, + | 15:44 |
| mnaser | adriant: absolutely, hence the discussion at ptg/forum which i think dhellmann mentioned they added | 15:44 |
| adriant | because there are a lot of small things like this, which need that push to get done | 15:44 |
| mnaser | https://etherpad.openstack.org/p/tc-train-ptg <-- popup teams here | 15:44 |
| mnaser | so we're def going to make sure we cover it | 15:44 |
| mnaser | and "Goal selection retrospective" in there too | 15:44 |
| ttx | yes, something that makes at least as much noise as the goals process, to attract as much attention | 15:44 |
| mnaser | absolutely | 15:45 |
| adriant | ttx: ++ | 15:45 |
| adriant | yes, that | 15:45 |
| 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 |
| mnaser | ok, so that means we're in a place where we need a 2nd goal | 15:45 |
| ttx | but better suited in recruiting a small dedicated team of people to accomplish one objective | 15:45 |
| *** jamesmcarthur has joined #openstack-tc | 15:45 | |
| mnaser | or rather a goal to replace the project delete one for Train | 15:45 |
| adriant | ttx: so a working group? :P | 15:45 |
| dhellmann | mnaser : what's the status of the testing platform upgrade? | 15:46 |
| ttx | adriant: I think it needs a more shiny name | 15:46 |
| dhellmann | that lingered during stein, is it done now? | 15:46 |
| jroll | dumb question: do we *need* 2 goals? why? | 15:46 |
| ttx | not "YAWG" | 15:46 |
| ttx | (yet another working group) | 15:46 |
| asettle | jroll, not dumb question. Would be good to know. | 15:46 |
| mnaser | dhellmann: so moving towards bionic? i think we're in a good place and that's mostly done | 15:46 |
| ttx | Maybe "DAWG" (dang, another working group) | 15:46 |
| ricolin | ttx, common! it can be YASIG! | 15:46 |
| dhellmann | ttx: YAWN: yet another working (group) name | 15:46 |
| ttx | Yo Dawg | 15:47 |
| mnaser | gmann: probably can comment better about that | 15:47 |
| mnaser | !addquote <ttx> Yo Dawg | 15:47 |
| openstack | mnaser: Error: "addquote" is not a valid command. | 15:47 |
| mnaser | this one is for the books | 15:47 |
| gmann | mnaser: dhellmann we left with 5-6 patches to land on project side to move project specific jobs to bionic | 15:47 |
| mnaser | :P | 15:47 |
| gmann | and trove and networking-midonet are the one which need some work to do before that | 15:47 |
| dhellmann | gmann : ok, so that's done enough that we probably don't need to consider it a goal this time? | 15:48 |
| 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 |
| ttx | https://imgflip.com/i/2wlm8n | 15:48 |
| adriant | Oh, actually a goal suggestion: Move off Paste | 15:48 |
| gmann | dhellmann: yeah, thats does not need to be in goal | 15:48 |
| adriant | Paste is pretty much used by almost all services, and is on life support | 15:48 |
| gmann | one I idea am thinking for goal is moving the legacy jobs to zuulv3 | 15:48 |
| * smcginnis imagines ttx with cornrows | 15:49 | |
| ttx | disturbing | 15:49 |
| adriant | and a lot of services also use eventlet, which also should go away... | 15:49 |
| dhellmann | as a reminder, here's our goal backlog: https://etherpad.openstack.org/p/community-goals | 15:49 |
| gmann | legacy jobs are pain whenever any updates we need to do on gate things | 15:49 |
| adriant | either of those could be community wide goal | 15:49 |
| adriant | goals* | 15:49 |
| smcginnis | Paste seems like a good start. | 15:49 |
| dhellmann | do we have enough of any of those worked out to have them documented before the ptg? | 15:49 |
| *** jamesmcarthur has quit IRC | 15:50 | |
| jroll | dumb question: do we *need* 2 goals? why? | 15:50 |
| * jroll asks again | 15:50 | |
| dhellmann | jroll: not really | 15:50 |
| ttx | jroll: no | 15:50 |
| dhellmann | do we have any at all right now? | 15:50 |
| mnaser | we have the osc legacy client killing | 15:50 |
| ttx | I'm fine with a single large goal | 15:50 |
| mnaser | well okay | 15:50 |
| mnaser | legacy client deprecation in favour of osc | 15:50 |
| 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 |
| dhellmann | maybe we should talk about the client goal in more detail then? | 15:50 |
| * dhellmann looks at the clock | 15:51 | |
| smcginnis | Not even deprecation, right? Just getting osc caught up. | 15:51 |
| ttx | maybe we can be a bit more optimistic if that's the only train goal | 15:51 |
| asettle | Line 290, "Add Configuration References to Project Doc Trees" is this not complete? | 15:51 |
| * smcginnis hasn't read the latest proposal | 15:51 | |
| ttx | (a train goal is called a destination) | 15:51 |
| dhellmann | https://review.openstack.org/#/c/639376/ | 15:51 |
| asettle | dhellmann, see note above | 15:51 |
| mnaser | it seems to me that this goal fits the fact it's team-based | 15:51 |
| smcginnis | asettle: I believe so | 15:51 |
| mnaser | so i am not really opposed to it | 15:51 |
| dhellmann | asettle : that etherpad may be out of date | 15:51 |
| asettle | Ah right. Cause that wasn't the only one I thought had been done | 15:52 |
| dhellmann | maybe mnaser wants a volunteer to prune the backlog there | 15:52 |
| asettle | That would be really heplful. | 15:52 |
| asettle | helpful* | 15:52 |
| * mnaser takes notes | 15:52 | |
| adriant | number 3 is basically: Get rid of Paste | 15:52 |
| 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:52 |
| asettle | adriant, heh | 15:53 |
| asettle | yes | 15:53 |
| adriant | that is a legitimately good goal | 15:53 |
| adriant | and doesn't need a major amount of work to define | 15:53 |
| mnaser | does anyone object under the the "Move legacy client CLIs to OSC goal to Train" goal? | 15:53 |
| 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:53 |
| adriant | evrardjp: paste is deprecated and unsupported | 15:54 |
| adriant | so you should | 15:54 |
| lbragstad | mnaser i think that goal needs to have it's criteria broken into separate lists | 15:54 |
| evrardjp | yes, so will python2 next year | 15:54 |
| *** jamesmcarthur has joined #openstack-tc | 15:54 | |
| jroll | evrardjp: as an operator, paste is annoying | 15:54 |
| mnaser | we can discuss the other goal soon | 15:54 |
| dhellmann | it could use more detail, yeah | 15:54 |
| evrardjp | jroll: yes kinda | 15:54 |
| asettle | We don't still have any projects on py2, do we? | 15:54 |
| jroll | mnaser: I don't object to the idea, I haven't read the latest iteration | 15:54 |
| asettle | That was a ocata/pike goal | 15:54 |
| lbragstad | otherwise it feels similar to the project deletion goal in that it is very specific to only a handful of projects | 15:54 |
| evrardjp | asettle: we still carry it | 15:54 |
| dhellmann | asettle : some teams have had technical issues completing the work, but it's still in progress | 15:55 |
| ricolin | mnaser, so are we keep the community-goals etherpad so we can looking for goals for future releases? | 15:55 |
| 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 |
| evrardjp | I think my intent was not clear in what I said -- We need to think the user facing value | 15:55 |
| mnaser | yes ricolin that's how we kinda maintain it overall | 15:55 |
| smcginnis | asettle: We currently support both 2 and 3, with the stated plan of looking at dropping 2 in the U release. | 15:55 |
| 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 |
| ricolin | mnaser, than I think we should put RABC and paste into that etherpad:) | 15:55 |
| mnaser | paste is already there under #3 | 15:55 |
| 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:55 |
| evrardjp | It's a nice thing to remove paste, don't get me wrong | 15:56 |
| mnaser | please, let's try to focus if the osc client goal removal is a thing | 15:56 |
| asettle | It would also help push projects to finish the original goal | 15:56 |
| mnaser | we can decide about those details later of another second potential goal | 15:56 |
| asettle | Sorry, yes | 15:56 |
| evrardjp | mnaser: I think it's a nice goal | 15:57 |
| *** tdasilva has joined #openstack-tc | 15:57 | |
| asettle | (yes it's got a lovely personality, good at dinner parities evrardjp :p ) | 15:57 |
| 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 |
| adriant | or at least lead into the latter | 15:57 |
| dhellmann | we've said we weren't going to drop python2 support until the U cycle | 15:57 |
| * dhellmann looks at the clock again | 15:57 | |
| dhellmann | #link https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-timeline.html | 15:57 |
| gmann | yeah | 15:57 |
| mnaser | yeah i feel so far all we've managed to accomplish is figure out the project deletion goal is not ideal | 15:58 |
| asettle | dhellmann, good to know | 15:58 |
| mnaser | and then also it seems that everyone is half unsure about the OSC one | 15:58 |
| asettle | mnaser, lots to talk about? Perhaps an agenda might not have been such an bad idea o.0 | 15:58 |
| evrardjp | I didn't want to bring py2 on the table -- that was just an example ! I should have shut up. | 15:58 |
| asettle | (strict agenda, I mean) | 15:58 |
| asettle | evrardjp, sorry I took that and ran with it. | 15:58 |
| 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 |
| 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 |
| asettle | Not at all mnaser - sorry for insinuating that. This was an office hours casual chat. | 15:59 |
| mnaser | i also don't want us to just leap forward "just cause" | 15:59 |
| asettle | Fair | 16:00 |
| ttx | need to jump to release meeting | 16:00 |
| * fungi can't wait to read all 400 lines of this ;) | 16:00 | |
| fungi | (after the release meeting) | 16:00 |
| * dhellmann also needs to change meetings | 16:00 | |
| mnaser | does anyone feel like we have some homework after this? | 16:00 |
| asettle | Indeed | 16:00 |
| lbragstad | i think i do | 16:00 |
| 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 |
| *** diablo_rojo has joined #openstack-tc | 16:01 | |
| mnaser | thanks adriant | 16:01 |
| 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 |
| 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:01 |
| dhellmann | zaneb : ++ | 16:02 |
| evrardjp | thanks adriant | 16:02 |
| * gmann need to jump to qa office hour | 16:02 | |
| adriant | zaneb: full support for the SDK from each project would be amazing! | 16:02 |
| mnaser | ok, i'll end for now and we can keep talking within office hours | 16:02 |
| mnaser | #endmeeting | 16:02 |
| *** openstack changes topic to "OpenStack Technical Committee office hours: Tuesdays at 09:00 UTC, Wednesdays at 01:00 UTC, and Thursdays at 15:00 UTC | https://governance.openstack.org/tc/ | channel logs http://eavesdrop.openstack.org/irclogs/%23openstack-tc/" | 16:02 | |
| openstack | Meeting ended Thu Mar 21 16:02:24 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:02 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/tc_goals/2019/tc_goals.2019-03-21-15.01.html | 16:02 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/tc_goals/2019/tc_goals.2019-03-21-15.01.txt | 16:02 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/tc_goals/2019/tc_goals.2019-03-21-15.01.log.html | 16:02 |
| mnaser | zaneb: that would mean we're getting some sort of agreement that the sdk goal is the way to go? | 16:02 |
| mnaser | err osc goal | 16:02 |
| adriant | I think we can't really separate that goal from the SDK | 16:03 |
| mnaser | and seeing smcginnis comment that glance or cinder wouldn't be able to do it seems to be setting ourselves up for failure :\ | 16:03 |
| adriant | the OSC is moving to using JUST the SDK | 16:03 |
| adriant | so deprecating the standalone clients in favor of the SDK and the OSC is pretty much a given | 16:03 |
| zaneb | mnaser: I don't know. I have been slack about reading the comments on the goal reviews | 16:03 |
| mnaser | i just feel rbac is a much stronger goal than all of these and it fits our structure much more | 16:05 |
| dtroyer | mnaser: 2 out of 20-some is failure? | 16:05 |
| mnaser | but i think i should have spoken up earlier, but i just recently started realizing how bad the situation seems to be | 16:05 |
| mnaser | dtroyer: well, 2 fundamental projects | 16:05 |
| mnaser | most clouds rely on cinder and/or glance, if folks have to still use their CLIs to do $some_op -- i dont know if we've succeded at providing a unified cli | 16:06 |
| ricolin | mnaser, I agree with you on that, and we should do some action even it's not a goal | 16:06 |
| zaneb | mnaser: I agree that RBAC is the most urgent of the potential goals. I'll defer to lbragstad on whether there is some part of that that is ready to be a project-wide goal for Train | 16:06 |
| ricolin | mnaser, I mean the RBAC one | 16:06 |
| mnaser | RBAC seems big too, so it can be a single goal. also, i know that some folks expressed interest in putting in the work to make it happen | 16:07 |
| dtroyer | If you see the deprecation ans the only goal, then yeah, we'll never succeed | 16:07 |
| dtroyer | projects just work that way | 16:07 |
| dtroyer | users don't care if the 'cinder' command exists, they want 'openstack volume create' to work | 16:07 |
| dtroyer | the two have co-existed for 6 years, which is more important? | 16:07 |
| mnaser | right but if they can only do operation X via cinder command because its where the cinder team implements things... | 16:07 |
| lbragstad | zaneb mnaser i think rbac will be too big and isn't specific | 16:07 |
| mnaser | lbragstad: ah, okay :( | 16:08 |
| adriant | is there a good reason why cinder and glance won't drop/deprecate their cli? | 16:08 |
| smcginnis | dtroyer: ++ | 16:08 |
| dtroyer | which -> deprecation of parity | 16:08 |
| dtroyer | sof/or/ | 16:08 |
| zaneb | mnaser: don't feel bad, I remember being in a design summit session in Austin (2015) when we agreed on it... I don't think lack of people speaking up earlier was the obstacle | 16:08 |
| lbragstad | mnaser that's not to say we couldn't find a "piece" of that work to do | 16:08 |
| mnaser | lbragstad: well, updating policies to use scopes and the new roles | 16:08 |
| dtroyer | adriant: I quit caring about their reasons a long time ago, I don't knwo what they are now | 16:08 |
| zaneb | lbragstad: I think if we can find a piece that we can feasibly move forward, then we should | 16:08 |
| zaneb | otherwise it will always be out of reach | 16:09 |
| mnaser | so start implementing system/domain/project scope for policies AND using the new roles | 16:09 |
| lbragstad | pre-reading: https://docs.openstack.org/keystone/latest/contributor/services.html#why-are-authorization-scopes-important | 16:09 |
| lbragstad | how-to: https://docs.openstack.org/keystone/latest/contributor/services.html#how-to-i-incorporate-authorization-scopes-into-a-service | 16:09 |
| adriant | dtroyer: but that makes no sense in a large community driven thing like openstack... if it makes sense for 18/20 to do it, then they should too | 16:09 |
| lbragstad | ^ those were written specifically for developers so that doing a multi-goal push would be easier | 16:09 |
| gmann | mnaser: lbragstad that need policy granular work also to adopt the new roles. (at least for nova lot of policies to be granular) | 16:10 |
| *** e0ne has quit IRC | 16:10 | |
| gmann | lbragstad: does scope thing work/benefit alone without default roles ? | 16:10 |
| mnaser | yeah maybe adding scope to all policies as a step 1 i guess | 16:10 |
| lbragstad | gmann it can | 16:10 |
| gmann | ok | 16:10 |
| lbragstad | but... there are a bunch of services with rbac enforcement scattered through out the stack | 16:10 |
| dtroyer | adriant: projects have independence, some have it much stronger than others. | 16:11 |
| lbragstad | nova and cinder are examples of two | 16:11 |
| gmann | at least to separate the system-admin and project-admin right ? | 16:11 |
| lbragstad | imo - refactoring that into a single compartmentalized layer is a good step, but doing that should probably be validated by tests | 16:11 |
| lbragstad | https://docs.openstack.org/keystone/latest/contributor/services.html#ruthless-testing might be a good first goal | 16:12 |
| adriant | dtroyer: I mean, you aren't wrong, but a lot of OpenStack doesn't exist or make much sense outside of the scope of OpenStack, and Glance and Cinder kind of feel like they don't make sense as standalone projects... | 16:12 |
| dtroyer | Cinder actually kinda sort is already used outside of OpenStack | 16:13 |
| mnaser | yep with standalone stuff | 16:13 |
| mnaser | and k8s csi afaik | 16:13 |
| dtroyer | OSC exists exactly because it took 5 months to get the 4 auth environment variables into all 5 (at the time) CLIs | 16:13 |
| dtroyer | and FWIW, Keystone has by far been our biggest supporter project-wise (I blame dolphm for agreeing with me in the first place) | 16:14 |
| * mnaser wonders how we could speed up osc too at some point | 16:15 | |
| mnaser | time openstack --help => 4.79s user 0.16s system 99% cpu 4.978 total | 16:15 |
| adriant | dtroyer: would it be possible to maybe allow both... Cinder can maintain their part of the CLI in their codebase, and the OSC imports and includes it? | 16:16 |
| adriant | if installed standalone, it has it's own CLI, otherwise it's a plugin of the OSC | 16:16 |
| dtroyer | mnaser: yup, we know basically what the problem is there and we're not going to re-write setuptools entrypoint to fix it | 16:16 |
| adriant | it would be a complex solution, but if the service can work standalone then yes it does make sense to have a standalone client... but duplicating the work/code is a mess | 16:17 |
| dtroyer | adriant: absolutely. osc-lib exists to support stand-alone CLIs, Ironic asked for it a long time ago, I'm not sure if they ever changed over though | 16:17 |
| adriant | then maybe that's the soluton | 16:18 |
| adriant | ... I serious can't type toni... today | 16:18 |
| adriant | maybe we do this goal, and as part of the deprecation work, we look at which clients make sense as standalone, and move the OSC code out to them instead of merging it into the OSC | 16:19 |
| smcginnis | adriant: The problem with having one code base is osc makes some changes for consistency that would require a lot of changes on the cinder CLI part. | 16:19 |
| dtroyer | it is not (quite) the solution for the existing CLIs, they are not command-compatible. could they be? maybe…it would likely be less work to just ocnvert the cinder command to use the SDK if that's really what you are after | 16:20 |
| dtroyer | the big win for them was using ksa, using SDK's connection/adapter would be useful too, but less so | 16:21 |
| adriant | because we have two competing problems. We want a unified client which is supported by the services, and some services want a standalone client for legitimate reasons | 16:21 |
| adriant | and yes ultimately those service devs would prefer not to have to maintain both... | 16:22 |
| adriant | smcginnis: so can we maybe deprecate the current cinder cli and make a new on that is OSC compatible and is both a standalone cinder cli AND a plugin for the OSC? | 16:24 |
| smcginnis | That may be a hard sell. | 16:25 |
| smcginnis | We could bring it up though. | 16:25 |
| adriant | but is there a way to otherwise solve this? | 16:25 |
| smcginnis | Consistency is good, but I know some folks really do not like some of the choices for consistency done in osc. | 16:25 |
| adriant | that isn't a good solution, but we're smart enough to find a way to make it work. | 16:26 |
| smcginnis | Other way to solve it is just have parity between the two and see what folks use. | 16:26 |
| dtroyer | Why is it such a problem for cinder to keep its CLI? | 16:26 |
| dtroyer | smcginnis: ^^^ that should be the priority | 16:27 |
| smcginnis | What's the priority? | 16:27 |
| adriant | it isn't? But if they are only maintain their own one, will it not ultimately end up feature complete more often than the OSC? | 16:27 |
| dtroyer | parity | 16:27 |
| smcginnis | dtroyer: Oh, yep. Big +1 | 16:27 |
| *** jaosorior has joined #openstack-tc | 16:27 | |
| zaneb | dtroyer: I don't think it's a problem Cinder having its own CLI, but if Cinder spends all of its effort on keeping its own CLI up to date at the expense of neglecting OSC, that's a problem | 16:28 |
| adriant | zaneb: +1 | 16:28 |
| adriant | that is the worry | 16:28 |
| adriant | who is responsible for parity | 16:28 |
| dtroyer | adriant: yes, that has been a problem since day 1. Will continue to be one as long as there are two. and is ultimately Cinder's problem because OSc doesn't have the resources to keep up | 16:28 |
| *** jamesmcarthur has quit IRC | 16:29 | |
| adriant | that's why I'm thinking find that middle ground of: "we do it the OSC way, but you keep the code ownership and can still have a standalone client, but the OSC also exposes those commands" | 16:30 |
| adriant | so they ultimately still maintain it | 16:30 |
| adriant | and the OSC gets the benefit too | 16:30 |
| adriant | it may well be a stupid idea | 16:30 |
| dtroyer | the problem seems to be the command choices I made | 16:31 |
| dtroyer | naming resources, option names, etc | 16:31 |
| dtroyer | I've gotten an earful more than once about not including them in those choices, 4 years after I made them | 16:31 |
| adriant | can we alter that? Does the CLI need as strict a contract as an API? | 16:31 |
| dtroyer | adriant: yes, that is the whole point here | 16:31 |
| dtroyer | we (OpenStack) already treat it that way | 16:32 |
| dtroyer | even sricter than some REAT APIs | 16:32 |
| adriant | ouch | 16:32 |
| dtroyer | the CLI _IS_ the OpenStack API for a lot of cloud consumers | 16:32 |
| adriant | but hopefully in an interactive sense, where we can deprecate and warn about changes? or is the worry people automating things with it using bash or exec actions in automation/config management tools? | 16:33 |
| dtroyer | it's the automation/scripting | 16:33 |
| dtroyer | user expectations is also quite high though. We did UX testing at two summits, that was huge in the responses | 16:34 |
| adriant | yeeesh. They we're screwed | 16:34 |
| adriant | then* | 16:34 |
| dtroyer | no, we're not screwed, we have to be thoughtful about what we put out there and be willing to live with it for the forseeable future | 16:34 |
| dtroyer | OSC still supports Juno (in theory, I haven't tried it in a while) commands from then still work as long as the underlying service hasn't broken them | 16:35 |
| dtroyer | aka, nova-net | 16:35 |
| adriant | oh well. I should legitimately go get sleep. | 16:37 |
| *** jamesmcarthur has joined #openstack-tc | 16:55 | |
| *** ricolin has quit IRC | 16:58 | |
| openstackgerrit | Tobias Urdin proposed openstack/governance master: Update my email address https://review.openstack.org/645233 | 16:59 |
| *** jamesmcarthur has quit IRC | 17:01 | |
| *** mriedem is now known as mriedem_grooming | 17:16 | |
| *** jpich has quit IRC | 17:23 | |
| *** dtantsur is now known as dtantsur|afk | 17:30 | |
| *** gmann is now known as gmann_afk | 17:43 | |
| *** e0ne has joined #openstack-tc | 18:05 | |
| *** e0ne has quit IRC | 18:12 | |
| *** whoami-rajat has quit IRC | 18:23 | |
| *** gmann_afk is now known as gmann | 18:40 | |
| *** mriedem_grooming is now known as mriedem | 18:53 | |
| *** ijolliffe has quit IRC | 18:58 | |
| mnaser | tc-members: there was talks about setting up an adhoc meeting for leaderless projects but it looks like it won't be necessary as we have candidates for all, i'll skip on that if no one objects, i added an item for the ptg to discuss 'community lead projects' rather than those that have a specific PTL as some discussion surfaced around that | 19:00 |
| lbragstad | cool | 19:01 |
| gmann | +1 | 19:01 |
| jroll | ++ cancel the meeting unless the reviews for those candidates come to blows | 19:01 |
| TheJulia | +1 | 19:08 |
| fungi | agreed | 19:11 |
| *** cdent has joined #openstack-tc | 19:15 | |
| *** cdent has left #openstack-tc | 19:17 | |
| *** whoami-rajat has joined #openstack-tc | 19:26 | |
| gmann | tc-members: I have started the Report for Bionic migration activity (Summary 6 projects left) - http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004113.html | 19:26 |
| mugsie | mnaser: makes sense | 19:26 |
| *** e0ne has joined #openstack-tc | 19:30 | |
| fungi | thanks gmann! | 19:38 |
| gmann | trove seems to be in risk, i pinged lxkong and discuss about it once he is online | 19:40 |
| *** e0ne has quit IRC | 19:49 | |
| *** e0ne has joined #openstack-tc | 19:52 | |
| *** e0ne has quit IRC | 20:04 | |
| *** e0ne has joined #openstack-tc | 20:28 | |
| *** e0ne has quit IRC | 21:17 | |
| openstackgerrit | Lance Bragstad proposed openstack/governance master: Describe the business value of basic RBAC https://review.openstack.org/645361 | 21:21 |
| lbragstad | mnaser i had a note to do that ^ a while ago, but after today's meeting i decided i should probably bump that up the priority queue | 21:21 |
| *** bsilverman has quit IRC | 21:41 | |
| *** whoami-rajat has quit IRC | 21:45 | |
| *** irclogbot_0 has quit IRC | 22:05 | |
| *** marst has quit IRC | 22:09 | |
| *** Sundar has joined #openstack-tc | 22:35 | |
| *** mriedem is now known as mriedem_afk | 22:50 | |
| *** tosky has quit IRC | 22:59 | |
| *** lbragstad has quit IRC | 23:46 | |
| *** jamesmcarthur has joined #openstack-tc | 23:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!