Kubernetes SIG Service Catalog, 3 Aug 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Service Catalog 20170803

Description

- Scope of first beta release

A

Welcome everybody to the Thursday, August 3rd 2017 special meeting, because they're all special, all unique special meetings: kubernetes sync service, catalog I, believe our current formula dictates that I hand over in a ceremony which we rarely go through all the required steps on hand over control them of the meeting to Aaron, who will put his semi visible, objective, facilitator hat on there we go and now I will stop talking at the end of the sentence and let Aaron begin objectively facilitating at the end of the sentence which I am finishing now period.

B

Cool thanks Paul, so we're gonna do pretty much the same. The same process as we've done for the past couple weeks. Think maybe past two weeks, I put the agenda doc into chat. We're gonna be talking about the two items under August 3rd 2017.

B

We're gonna go with the speaker queue as we always have done in the past couple weeks. I will be taking notes, but not sharing my screen and as usual, if you have something to say, please comment with plus hand as I just did in the comments thread and I'll put you under the queue. I lack you in the thread and you'll get your chance to speak.

B

That's gonna be about it all. As usual, we'll be using my high tech, speaker, cue technology, and with that we've got our first item on the list from Paul is a proposal for the scope of initial beta release. I have typed in a few sub bullet points, but they should be fairly self-explanatory and, with that Paul I will hand it over to you.

B

A

Do we have anybody, that's gonna, take no.

B

And share their screen: I will be taking notes, but I won't be sharing my screen because.

A

I gotta handle.

B

The queue as well I'll.

A

Share my screen: how about how about dad sounds.

B

Good all right.

A

A

The zoom has this bucket, where it like you go to share your screen. It shares it gives the option to pick every window except the one that you want so I'm going to share my entire desktop and you might see what a what a mess it is actually I just had a hard reboot, so it's very nice and organized okay. So here's the agenda, I'm talking about issue number one, zero, nine, eight and so I we've been having these design discussions for a couple weeks and I. Think they've been like extraordinarily productive and I.

A

Think everybody who attended and participated in those who might be here and since we only have a few people most likely watching on the internet later I have been feeling as though we have been converging upon a kind of feel for what we think is in and out of scope and so I took a stab at actually writing it down.

A

So when I was doing, this I was thinking about what our goals are and I think the goals are to make it possible to support Service Catalog in production environments, to finalize the support for the core open service broker.

A

Fundamentals like parameter and plan updates to unblock users that need to use these things now and provide a smooth experience for users with robust handling of corner cases, and this is basically an alias for orphan mitigation and for, for example, another one that comes to mind is like what the business logic should be of when you realist a broker, what happens to services and plans go away and then another one?

A

That is something that we've recently I've gotten consensus around an open service broker, which I think is important, is allow service brokers to provision resources and kubernetes using the identity of the user that requested them so I. This is I have like a few points to go through about like the features. I wonder. If folks have any gut reactions are those the right goals? Do we have other goals that I didn't think of? How do people feel.

B

Can ever, could anyone not see those goals.

B

Take that, as everyone has seen them, has everyone read them over and.

A

By the way, I am fully aware, people might need a chance to think about this. I am I, did not expect it all to I'm not trying to force the decision right now. Please do think about them. I think that we should have another discussion on this on Monday, but it sounds like. Maybe people need some time to think but nothing's popping out so far. That's like ah there's another goal and it immediately comes to mind that it's not written down so.

B

We've got Doug saying that he needs some time to think if things are missing, yeah and Morgan says that he has not fully parsed them yep, so Morgan I, wonder so Doug, that's totally cool sounds like we've got some time built in for all of us to think about. Other things are missing: Morgan I, wonder if you have any immediate comments related to things you have or have not parsed yet.

C

Now just need time to look cool picture. It's totally feral.

B

Anyone have some comments going once.

A

Okay, so I also wrote a little bit about what I think our approach should be to finalizing the designs for these things, and this this is influenced. You know, most recently by art, design discussions that we've had so far and prior designs. That I worked on in kubernetes and I. Think that one important principle is that it's not it's necessarily not possible to imagine all of the different use.

A

Cases that were eventually going to want to support I think that the sweet spot for an initial beta release and emphasis on initial, because I think we're gonna want to do multiple ones is that we should try to be really strategic about where we design for future extensibility, and we definitely need to have design documents that are checked in for major design. Work elements nas already started doing this, we've got another.

A

We've got some things that are issues right now that can easily just get turned into pull requests that have that contain the the text of the issue reformatted a little bit. So it's more like a design document, but I thought that would be a fairly good baseline for how to approach this work, and so I'm gonna stop hearing it and let other folks comment if they have anything to add or want to tell me what an idiot I am I will tell you in advance.

A

I am already aware that I'm an idiot so no need to necessarily rub it in.

A

A

Did it I did mean that I had had in mind that dock design documents are very convenient to check in I'm, not married to that at all? And honestly, if, like we've, we've gone around and around about this, an open serviceworker.

A

If people don't want to check a design doc in I, don't think we need to make a big federal case out of it.

A

B

Sorry I was muted, so Morgan you had the first hand up did Paul answer your question. Do you have more, you want to say no.

C

I'm, fine with checking the documentation, the design documentation in I just want to avoid this bizarro world thing that the course interests have where they check a design doc in and then we have no idea if it's if it's actually been implemented or not, and so you know fine, we check it into proposals, you know ongoing and then you know when it's done. It actually moves to it's done or there's something at the top. That says it's done because more than once have I gone to the features.

C

I, don't I can't remember it's a separate repo or for the directory and community, but you go there and you look at a proposal and you have no idea what's gone, what's happening with it, so yeah that I don't want to avoid.

B

That, okay, Niall, you had a comment right after Morgan. Did you want to verbalize or expand on that yeah.

D

I think that for the design proposals, raising pool requests is a good thing. I agree that we probably should separate proposals from the actual documentation and we can move these proposals to the do relations once we implement okay. This should be good enough. I think and I'm just saying that for the big proposals I think it's much easier to to decide what what we we all agree on, for example, with instance, parameters issue we just like even with the documenting stuff in the notes or the calls different people have different understanding.

D

Do we agree on and once you lgt am dpr, should we understood that this is exactly what he agree on and if you disagree, you just have to raise a question or improvement. Okay,.

B

Doug you had written a couple things starting with right. After Niall, can you verbalize those and and maybe at some commentary, Douglas.

A

Audio might not work super great right.

B

I mean I will I will verbalize what you said that at least ugh sorry I forgot you're on go, go so Doug says he'd prefer that they become documentation that isn't stale the minute they're merged then follow up to that. He says our Doc's should say everything a design. Doc says anyway. He doesn't think we need both, but it aligns what Morgan was saying. It's very confusing to follow the core documentation and design proposal process.

B

That's all about this, and then he says no I can't talk so Doug I, hope, I, hope, that's a decent overview. Verbalization of what you said great good, to hear so next is Paul. You've got your hand up so go ahead.

A

Yeah so I generally agree with what Doug and Morgan have said. I do think that it can be a little cumbersome to try to write a proposal that is like it's transformed.

A

Has the identity, identity transformation like it is itself that it's doc, so I I, don't really want to get hung up on this, except to say that I agree with Morgan that the the if we check stuff in we have to go back and say it was implemented in this issue later.

A

If we check a proposal in and it changes week, we need to update the proposal, and actually you can't see it on the screen now, but I do think that we should have at least minimal documentation for the general concepts and the use cases and how to use the API. So I think between those comments. We're probably pretty close that how does that strike? People like we don't need to?

A

We don't need to hash out a process for design proposals right now, as long as we agree that we should write things down and that we should eventually produce documentation, and if we check proposals in, we should circle back and say this is where we implemented it in these one or more polls is that is that cool for now.

B

Doug says quote: minimal Docs our Docs should be complete or full Doug. Was that a question or is there something you can expand on in there I think.

A

The I may have used a bad poor choice of words with minimal. My minimal is that they should be complete.

B

Got it okay and Doug says these were just reacting to your worrying, there's a smiley face in there and he also +1 to you so I think we're all good there.

B

What I have taken from your words Paul is that you put a proposal forward that design Docs should be put into the repo and checked in, and then they should be updated with their status on whether they were implemented with been implemented. Yet whether things have changed in them and so forth. But beyond that, maybe don't get too hung up on the proposal process for.

C

B

Does anyone so Paul is that about accurate, first yeah.

A

With the additional thing that I think, what were the way that we're working in these design meetings and in github is is really very effective, so I think I'm, basically reaffirming what we've been doing so far and I want to make it clear that I endorse working in that way. Okay, cool.

B

So again, the proposal that's put forth is that design Docs should be checked in and updated with their status as we go. Does anyone disagree with that that process? For now and again, that's what we've effectively already been doing so. Does anyone disagree with that process?.

B

Doug would like to check. I would like to talk more about checking in proposals in a future. Call Doug I'll put an action item forth for you to add at a talking point for Monday to talk about. That is that cool with you.

B

I'll, let go go and my voice up to 30,000 feet. Yeah.

A

We can we can talk about the specifics of what we're gonna do with these things, I'm generally in favor, of like I, think as long as everybody's comfortable with how we're working I don't think we need to have like a super detailed plan, but I will do whatever folks want to do. The most important point is that we write things down specifically.

A

B

So thanks good and yeah, so I saw Doug. You said yes, I put the action on for you. You're gonna take care of that Paul. We were you who you want to keep going down the list in your beta ticket yeah.

A

I'd like to I'd like to just we have 33 minutes, left and I, think that should be enough to talk through what these things are. So if we can do that, that would be great okay.

B

Yeah, take it away Paul, so.

A

Just for clarity, I am NOT I. In this conversation, I am NOT, supporting or endorsing or indicating that I don't support any way of solving a particular problem I'm. My goal here is for us to agree on which are on what the set of problems that we had to solve is for beta. So with that in mind, I think there are four main areas. The first one is. We need a beta level, API and I. Think the major design problems in that is that, in that area, are that we need to finalize the resource names.

A

There's still a question of exactly what the kubernetes names of service class and plan should be, and by this I mean is it the human readable name? Is a the open service broker ID and how? What? What are the ways that we're going to allow you to reference these from an instance and then I learned the other day and I put this into slack and I'm, pretty sure everybody? Here's has seen seen my comments about this. In slack, the checksumming thing, which was my brainchild, is the wrong way to do stuff.

A

I learned what the right way is and it's to use this feature of object, medical generation, so I think that we should do that, but those I think are the biggest API problems as far as providing a stable API and by the way, I also should have said. If anybody thinks something is missing or is in there that doesn't have to be I'm. Just gonna keep going through this list like collect your thoughts and put them into this issue, or we can talk about them here.

A

I'm I'm interested to know if anybody thinks like something needs to be added or subtracted from this list. So if.

B

A

B

You've got initial thoughts, just put your hand up, I'll put you to the queue.

A

Doug generation replaces checksum and is much easier and less complex to implement than checksum.

B

So Paul want to keep going I'll keep the.

A

Hands and I'm not even sure if the bytes have gotten up to Doug, yet so I'll keep going so for brokers. I think we need an API for refresh settings and that encompasses do it on a duration. Do a manual only and we've talked about- there's also, you know. Obviously, if manual only is an option, you've got to be able to manually trigger that it gets refreshed.

A

There's also the semantics of when you do a refresh. What's the business logic that you carry out and how do we handle things like? Oh, this broker removed this plan and we still have services that are on that plan and then there's also API surface, for which opens surface broker. Api version that we'll use to communicate with the broker, there's bearer token auth, to authenticate from the controller to the broker and then there's TLS verification of the broker's TLS, and some of these things.

A

We've actually got quite a bit of work done on and they're in progress to some degree, but I just wanted to list everything out. So it was. It was in there the so for instances there's the sourcing parameters, there's which I think due to the volume of discussion we've had on it this week, I doubt I need to re-explain there's orphan mitigation, which is preventing things like you.

A

You did a provision and it timed out, but it actually did complete and you don't want that instance: that's just floating around there to be consuming resources. It's part of the spec open, serviceworker spec, there's plan updates, parameter updates and user impersonation.

A

Then there's clear handling of what to do. When you get a deep provision request for an instance that has bindings there's ensuring no other operations can start during a sync operations which I actually think that we we might be covered on, but I'll just keep going and then there's reject plan changes for instances of service services that aren't planned updatable.

A

So then, for bindings, it's actually a fair degree of overlap, but those things for bindings parameter api orphan mitigation, user, impersonation, I'm gonna skip over the next one and come back to it, then determining whether we're gonna send the applet on bindings and then last, but certainly not least, is I. Think that we should remove the pod preset integration and that, given the changes that are in progress with pod preset moving that the only degree to which the beta scope should include pod preset is that we're removing this alpha pod, preset stubs. So.

A

Basically, in that regard, or the facet that that's related is that we should be focusing on just the open service, burger, API, primitives and the right, the right things around those in the API surface to make a smooth integration in kubernetes around things like when I say that I'm referring to like how often do you refresh a broker stuff like that and then last really less and also really, not least, documentation.

B

Cool, so now you now had a hand up so now go ahead. Doug I've got you act you as well for next now go ahead. Yeah.

D

I just wanted to said that the migration from TBR's to Sierras is missing. Lewis I.

D

Think we need it for the better right, I mean like it's not dependent on the other features, but we needed to get merged like in one two months from now.

B

Any reactions to adding CID support to the beta list.

A

I'm not sure that we need to necessarily block the first beta on it. I definitely would like it to happen in the in a beta release.

A

My only hesitation is that it it took an incredible amount of time to do the TPR stuff I, don't think it will take that much time in to do see our DS, but I'm not positive, that it has to be a block, a blocker on the first beta I'm willing to hear arguments for it. That is my own personal subjective reaction. I.

D

Guess it depends on whether we want to do release Service Catalog with the latest or one of the latest releases of communities. It was like if we do then at some point, so stoic will be incompatible with the latest release of communities. If we want migrate to cities.

A

So I I think that we had some folks that were ready, willing and able to staff this in the community. Is that right, Erin? You, you handled a lot more discussion on that than I have yeah.

B

So Nile myself and minke from Google all discussed Nile I think you crime wrong. Thank you or someone else that lassie and might be able to do some work on it. Soonish minke a little thick mink. He said he could do some, but I, don't I, don't think he knows exactly how much yet.

A

I guess my reaction to that is I think that we need to look at who who can stat that and what level of commitment they can bring to it before we say that we should block an initial beta.

B

Release on I would suggest that the group does the opposite and decide whether this is something we need for beta and Nile your question of: do we want to release? Can you repeat your question about? Do we want to release for the latest version or not, I, don't remember exactly how you worded so.

D

Do we want to regularly migrate until the latest release of communities, at least the major release, I.

A

Think that it depends on how regularly I mean I'm I, definitely think that we should I think I think that we should decide what minimum version we're gonna target and that we should talk about how regularly we begin depending on new features and I would be in support of trying to stay stay in sync, with, like the latest release version. Definitely.

C

Does that mean the minor or the I don't know whatever the things called patch release? The third.

A

C

A

I'm thinking like latest minor version is my own personal opinion, so.

A

D

A

Should maybe be a note Aaron about, we need to decide what version were targeting.

B

B

Are we are we good? Do we have any other discussion for the C or D support before we move on?

B

Are there any action items that someone needs to take for a future before a future discussion about CRD? Let's.

A

Let's think about it and let's come back and discuss it on Monday, both CRD and what version we're targeting and what? What how often we're going to or how we're gonna position ourselves for use in future versions.

B

Okay sounds good all right, so then, moving on to Docs Doug has a hand up. So I will speak for him. He says on the last one, meaning the docs one. Can we get in the habit of requiring doc updates for all new pr's? We really should get into the mode of operation where our Doc's are always up-to-date with the code. We agreed on this process when we first started, but we've been a bit loose on doing it. So.

A

I think that's a good point and I'm sorry I didn't have my hand up. You can send me one demerit I'll, give you my physical address. What.

B

I was what I was gonna ask next is: does anyone have any reactions to this statement that Doug is made.

A

Sounds like you do, Paul I do I support going to that mode, but we currently have just about zero dock. So I think somebody needs to like one or more people need to allocate time to making getting dock to a baseline.

A

But overall yeah I think that once we have good baseline docks, we should definitely move toward dock updates.

B

Okay, so it sounds like at least from Paul and Doug what you've said. What you've said is that we do need to get to that baseline first, and then we can start adding this requirement. Does anyone disagree with this called baseline idea.

B

I'm gonna going once I'm gonna, take that as a no I will set up an action and for that to create an issue. Meta issue essentially.

B

For creating a baseline.

B

Alright, so the next hand I have up is from you Paul. You have said it's regarding Docs. Do you have anything more? You wanted to say in that realm yeah, getting the getting.

A

The Docs to a good baseline is probably something that we can parallelize, and it might also be a place for folks that are less interested or able to do technical contributions to help make a contribution, so I I think to maybe put a little English on your action item.

A

Maybe part of that can be that we might break down exactly what we think a good knock baseline is, and at that point it should be pretty obvious out of the meat falls off the bone and might be easy to paralyze or at least split into chunks that don't have to be done in one mega PR, because I suspect such a mega PR might be hellaciously difficult to get merged.

B

Alrighty, so in that issue, I will just propose a few places where we could improve talks, and then we can have discussion on the issue and then potentially bring it up in a new design meeting down the road to figure out how to paralyze it and do some of those things you mentioned Paul.

B

Any objections to that going once.

B

Okay, I have Doug, you had a comment about cube versions: I put your hand up for you, but you said no need to talk about it. So I'm gonna cross you off the speaker queue list. For that the next hand I have up is Paul.

B

You say that you're considering doing something, I have your quote off time and then you put a hand up so go ahead. Now.

A

We're replaying events in the queue are we yeah, you're JMS connection had a durable subscription. Okay, you reconnected and you're getting the the durable events that you didn't clear. All right.

B

Well, your hand is now down okay, so we've got couple action items out of this big bullet point about beta release. I would encourage everyone to think about these things. Some more we're going to bring this up again sounds like on Monday specifically consider what's missing and what should it be in the proposal? We've had some discussion about that already, so that's great does it. Anyone have some final sections comments. Questions about this big beta bullet point before we move on now, I'll go ahead.

D

So, regarding the recommendation, do we require every PR or that well, whether it's a code change or something else to update the corresponding dogs like for every new feature, so.

B

We'll discuss just previously was that we first get to that baseline and then we move forward with coming up with a way to require Docs and age. So I didn't I'll share what my interpretation was from. That discussion, which was I, didn't get the impression that we were going to require Docs as a hard and fast rule on every PR.

B

Does anybody else have comments on that? Paul go Doug, says plus one. Yes, once we get a baseline, I I'm, not exactly sure, specifically what you mean Doug so do you do you want to kind of specify what you mean in chat or follow up later I.

B

Will take yes to all PRS needing Docs once we get a baseline okay, Paul your hand is up next, so go ahead. I.

A

I do think that we should find a way to account for the fact that, like some people are are just at different strengths. Right and like some people do have are like able to slam out code that works and is correct and will become extremely blocked if they also have to write doc, because it's just not one of their strengths.

A

So we should. We should think about that and like if somebody.

A

If someone recognizes this about themselves- and we make it very clear up front- maybe they can get a doc buddy on there pull requests to like make it's easy to collaborate on branches right, and so one person could tackle the code and another person could tackle the doc. Maybe once the code is getting to a state, that's good or some other arrangement I'm not trying to push back at all on.

A

We need doc updates with code I'm, only trying to say that like people do have different strengths and that we should avoid a situation where people feel like they absolutely have to write both the doc in the code, especially since well I'm I think I'm about to start repeating myself. U.S.

B

Cool, so this guy Aaron had his hand up as well. I'm gonna take off my hat and just say briefly: I believe we should probably get to a baseline first and then discuss specifics on what we should do: policy wise for Doc for every PR kind of policies that are kind of around that I've got thoughts, of course on that as well they're, fairly similar to whatever one is said already, but I would rather that we focus our energy on getting to the baseline and then figuring out what to do from there.

B

So I see quite a few comments after I put my hand up, put the hat back on so Doug to verbalize what you said. Doug says: +12 a doc buddy. It's that important on the same PR Nile then says his question was whether we require to make both co2 design changes in a single PR.

B

Morgan I view that as a common courtesy, there's some overlapping conversation now Nile says to guaranty. Doc's are in sync with code, so on and so forth. So I would love for people to put their hands up again and verbalize. Some of this stuff in in contiguous conversations, the Paul you've got your hand up go ahead, so.

A

Remember that, if we're writing design documents, those should include what the API is going to be and so I it should be. It should be such that the design is finalized before the code is merged, obviously, and since the design should be finalized really before people start thinking hard about the actual code.

A

Maybe another permutation is that someone can open a dot PR and another person can open an implementation PR and we've got to make sure that they get merged together around the same time, I think it might be a little bit of a handicap if we insist that they have to be in the same PR I think that we should be flexible and allow for different arrangements. I do agree that maintaining quality dock is very important to our overall long-term success and since I think this project is important to the wider community.

A

I think it's also important to kubernetes overall success. So it's very important to maintain good dock. We just have to be smart about, like not being so specific that it turns people off or makes it a pain in the rear end to contribute. That's all.

B

Okay, so, since I don't see any hands up, what I've heard so far is that everyone seems to have consensus that we should get to a baseline of documentation before we start doing something along the lines of requiring docks. Her PR does it before we move on. Does anybody disagree with that particular consensus.

B

Go and while that's.

B

Okay, Doug you've written something in here since you're. The only one who can't talk I will assume that your hand is up if anyone else has something to say. Please do put your hand up, though Paul that's a knack for you. So Doug says, as with most most things, I believe it's okay to define our process as our goal and be a hard-ass in what we document. But then, in practice we know there might be exceptions and so Paul. You have your hand up so go ahead.

B

Think you're, muted, still Paul.

A

Okay, so my my the point that I was gonna make is I think it might be detrimental to our overall productivity if someone has to rebase a lot of code, because people can't agree on the wording for a doc and I think that might not be the best use of time. So I I agree, I, guess with what Doug is saying is that there might be exceptions, maybe one possible exception would be enormous, pull requests. That is good from a code standpoint.

A

The doc isn't finished or has some minor disagreements on wording? Maybe we could pull the doc out of that one and make a separate PR for it, or maybe this isn't an issue. If the moment we feel like the design is done, we immediately start making a doc pull request. I do think something that is very useful in projects. Is that certain people?

A

You know, in addition to having different strengths, they have different interests and some people are very opinionated about documentation and other people are more like well I'm, a hacker and when I want to know when the thing, what the thing does I'll read the code, and so it would be really convenient if we had some folks very interested in making sure that the documentation maintained a high bar that would be willing to to help write documentation for features so that people who were primarily interested in coding or that felt like I'm, a really strong coder but I hate, writing, doc or I feel like like I'm terrible at it, and it's really really hard for me so that we can kind of accommodate all different work.

A

Styles and strengths. That's all.

B

Okay, no hands up so I will just ask we have four minutes left. Does anybody have any other comments that can be fit into a four minute window about anything in the beta element and sorry, then beta bullet point.

B

: once all right, four minutes is a sense, so I don't think we're gonna make it to issue 1075 about instance. Parameters. I will move that Nile into the next meeting, which is Monday and with that I believe that we're gonna get four minutes back on the day. Please look at your action items follow up on those I will be following up on mine later today to create the issue. Otherwise, I will see everyone on the Internet take care. Everybody.