Cloud Foundry CF on K8s Forum, 5 Apr 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cloud Foundry on Kubernetes Working Group Forum [Apr 5 2022]

Description

Notes from the meeting

• [GC] Testing testing testing
• Test against real clusters for integration tests?
• EnvTest is limited, but fast.
• Difficult to force errors from k8s api in integration tests.
• “Integration test” is an overloaded term.
• Try experimenting on one of the repositories? Abstract the Kubernetes client. • Need tests for abstraction.
• Are the integration tests still serving their purpose? Gaps in e2e & unit that need to be backfilled if we want to remove the existing integration tests.
• [GC] HNC v1.0.0!
• Label and annotation support.
• [DW] PR to skip a CATs test for cf-for-k8s.
• The “insufficient resources” test is quite flakey as “cf scale” often times out instead of returning the expected error response.
• [CC/EM] Project naming updates
• Trademarks in progress - can probably start using name publicly.
Linux Foundation will help with logo.
Korifi!
• Will need to rename GH repository.
• [Ram] Could we collectively help fill out the PR worksheet for Korifi?

A

A

Let's do that again uh welcome to another edition of the cloud foundry on kubernetes working group form here is the uh working group forum notes if you'd like to add any topics. Please do so if you cannot drop them in the zoom chat and I can add them for you we'll see if anyone else arrives in a few minutes and we'll just sort of bring them into the fold as that happens, but otherwise, let's get rolling on the various topics.

A

So the first one we have is test contest and testing.

B

Yeah, I think we've had some discussions recently about uh whether we want to write integration tests for our repositories. I think versus unit tests uh so kind of what are the pros and cons of mocking certain things versus not et cetera, et cetera, and uh at some point we decided.

B

Okay, we should have a dedicated meeting, but I figured this could be that meeting if you want to so I haven't scheduled anything yet because maybe we can just do it now but like if we don't want to, then I can schedule something separate uh up to the group. I guess.

C

Yeah we, we talked a little bit more about this on the us team and came.

D

To the realization.

C

That none of us actually cared enough about making that best thing change to be the champion for the change so like, and we don't have a lot of consensus about like what would be the best change to make. So uh speaking for myself, I sort of decided like this is not.

C

This is not this isn't something that I I want to spend my energy on, because I don't feel strongly enough about the merits of of the change we proposed.

C

um So my plan was just to let it die on the vine, but if anyone else feels strongly about it, it could certainly be taken forward with a new champion.

B

Yeah I mean I feel relatively strongly about keeping the integration tests, but also, I would like to see them against real clusters instead of amp test. I don't know what that entails in terms of like in terms of cost like, I know we're spinning up concourse so that maybe it's going to make it easier, but then what do we do locally? I guess we all have a kind cluster locally. So maybe it's fine. I don't know.

C

Yeah, I think the challenge there is just that f-test is so much faster than a real cluster.

B

Yeah, but it's also yeah, it doesn't have much finality and we have some some things that just don't work yeah, it's bit. It's been so great. I I I hope like if we have a decent, real cluster. It's I hope it's not that much slower, but yeah maybe setup changes. I don't know if you have to clean things up or if you have to create dedicated namespaces stuff like that toward collisions like mtest, is naturally self-isolated it's in process. It comes with its pros, I don't know, but it's kind of a different conversation almost like.

B

If we decide to keep the integration test, then we can, you can see how costly would be to move them over to real clusters and whether it would be worth it or you know.

E

Would that mean that we'd also want a unit actual unit test for the repository code to test drive.

B

I would, I would say, no, like I would say I have either or because they would overlap 90, and so I wouldn't and again like they come with the problems of mocking foreign code in a way.

E

B

Just really hard to.

E

To force some of the error cases when you're working with even a real api server and lcd, let alone a full-blown cluster, forcing the errors to to drive out that you know that that part yeah.

B

I guess that's the main. I guess that's the main problem. That's some area, some, some branches that you just can't hit like so like there are some air conditioners that come all together, so you either hit the first one or you hit none. So you can never like you can't you can't eat the you can't trigger the second air conditioner without triggering the first one because they always occur together.

B

uh There's this kind of coupling yeah. I don't know I honestly like yeah, and I it's a surprise that I'm worth that I'd be happy to pay versus having the marks just because I feel much more confident with tests against real apis than for this kind of code, like for the for the repository code but like if we decided to that, we really wanted unit tests. I would have just them and then like I wouldn't have both suites, because, like keeping them in sync etc is just too expensive. I think, like that code.

F

Is not that important.

B

That that it's, uh you know that it's worth to be covered twice, like literally two full test reads covering all of it.

G

uh Maybe we could have both of the best both worlds.

G

I guess because, like we had this discussion like casual discussion, while pairing with danny today uh that, like a long time ago in the really- I guess even really not the ring controller but the older irini, we introduced this these custom clients that would wrap the controller client that we're using.

D

G

The cage client using candy so that you can still like, and then you can unit test like if we did that we could unit test the repositories with like fakes as we're used to and then test the specific clients that we built. I guess one downside of this is that we're going to build a little bit of boilerplate, but I mean we could generate this code. We could use generics.

G

What not, and even if we do build the code, I guess it would be like a one-time investment or something that will not like will pretty much be done with it like. If you look at the draft pr, it's uh touching the app repository our proposal, it doesn't have the privilege client anymore. It's got an interface.

G

The namespace retriever can already fake that, but it also has the client factory, which is giving you this really powerful client, that's not typed in any way and really really hard to mock, really annoying like if we had a typed client that, like just declined for secrets and a client for apps, for example, might be enough for this repository. Then we can. Just you know, drive everything with unit tests and then we can just test our clients against the. I don't know like real cluster, maybe or.

D

G

Don't really know what the the right way would look like, but then we can have both of the best of both worlds or maybe, in other words, avoid the overlap by pushing the boundary a little bit like just draw the.

D

G

Really low and then we have a nice reach in our custom code. So I don't remember exactly why we ditched this approach back in irene, but I'm starting to think that it might be a.

D

Nice approach, I remember working on it. It was such a great day. We deleted about 3000 lines of code when we went straight to that interface instead of wrapping each one for each different type, so it made it maintainable and it just got rid of a whole load of boilerplate.

B

Yeah, the cost of this approach is, you need to introduce an interface for every type we manipulate, and then we need to introduce a test for every type of name like if you.

G

Create a secret.

B

I still need to test them one, but you need to test the implementations. You can make the interface generic, maybe, although I'm afraid you can't just because you would need generics supported at the underlying client level, like the underlying client lab, takes interfaces so like. If you take a generic type, you need to kind of feed it into an interface. I don't know if it's going to work.

F

um We can do all the ugly casting in one single place and just uh leave it under the carpet, like just don't bother about it if it works.

B

Yeah, but you would have to still test each implementation, provided you have like a generic interface that I'm not sure you can like. You still need to test each one of them like. So, if you create a secrets, client you need to. You need a secret client test.

B

Then you can mock that secrets, client, but then you need to test for it and- and ideally you need a test that pins every thing you mark right. So if you mark that this method called with a b and b returns c, then you want a real test that proves that that's true in certain conditions right, so that's the price. If you introduce a new boundary, that's a new! Basically, a new suite of tests to test the new.

G

Boundaries but at least they're all dead, simple right, like just just very small, so it wouldn't.

D

G

But this will be very simple: there'll be a lot of them, but they'll be easy to write easy to understand.

G

While if you draw the line higher, it becomes really huge because if you want a test on the repository level, there there's logic inside dependencies like many kinds of plans, the it's the the previous client is implied by the namespace retriever. Then there is a user client like it's way more complex and presumably slower as well.

B

Yeah, I'm totally totally up for mocking the name space retriever, because that's the thing that's a very narrow interface that we control. It makes all the sense in the world to market. uh If we want to, we could try to see what it would cost to introduce.

G

To do this, for everything.

B

G

How it started, I mean not do it in the club, but like just propose another draft, see I mean if, if it's terrifyingly bad, no one will be pushing for it. Just yeah, maybe.

B

Just try one morning see how far you get see how annoying it is.

B

Maybe it's not bad, but like it's the kind of thing that needs to be done on the code in order to be judged, so it might.

H

B

Great in words, and then when you try to do it, it's a mess.

H

Yeah I'd be interested in seeing how that how that looks, um but one concern I do have, though, is if we get rid of the integration test entirely and we just have units they. Those tests are less useful for refactoring, for example right.

H

So, if you think about, we have a fair number of methods in the repos right now that do things like they list all of the resources in a space and then they iterate over them to filter them down, say we want to change those so that we're using index fields or so that we're using gets. If we have this integration style testing that we have now with test m, the test could stay identical and we can just change the implementation and we have confidence that that everything is.

H

um However, if we switch to more of a moccase style unit test, you have to completely change the um the test side to support that, and then you've also had to do a lot of work to get to the point where everything's marked out. So I'm not necessarily convinced of the value of what we're talking about. For that reason,.

F

One of the things that uh draw my attention on the talk that giuseppe mentioned several times about integration, test being scum and I didn't realize, is that unit tests are pushing your design decisions, which means that if you want to change the implementation so drastically, it is worth paying the price of changing your tests as well, because otherwise, integration tests are just verifying the behavior but they're not challenging your design.

F

B

Maybe yeah keep in mind that what he talks in what he calls integration tests or integrated tests is uh not what this thing like integrated tests. What he calls integrated test is test the test, multiple components that you own together. Well here we are testing one component that we own with the with with its associated third party, and this is a problem with the overloading of the term integration test, which is used pretty much for everything, because.

F

The end results whether integration or integrated test is that it doesn't challenge your design. You can.

D

Write a completely.

F

Terrible code and your integration test might still work.

H

Yeah I mean the challenge here is that we we don't actually have control over the case client interface right like we could make a wrapper on it like we're talking about, but ultimately that's just adding a layer of abstraction on top of something we don't control so yeah. I I feel the same.

B

Way that was just happy yeah, so the the argument about, I think design pressure applies, I think very well in, for example, in the case of handlers like when we test handlers and integration, then we have this problem because we're testing that whole, like we're, testing the handler the repository everything all the way down to kubernetes also all is one blob and that I think, is not applying the design pressure that we need on our thing, because it doesn't allow us to define, I think, the repository interfaces properly, for example, but like for the repositories being at the boundary of the system.

B

I think the argument doesn't apply as much because, as as matt said, everything beyond that is not under our control anyway. So there's we would. We would there'd, be pressure on an api that we can't change anyway, right.

G

Then again, there is the thing that we want to simulate certain error cases in his heart, uh yeah.

F

That's amazing: it's all about.

G

Drawing where you want to draw the line between things that we don't own things we do on, and I guess if we try and draw the line uh on a lower level it we might have more control over our stuff, and I guess what matt said is true about refactoring, but also, if we kind of have like we have the e-twist test test suite, which I think maybe we're overloading a little bit. It's become too slow. We had to optimize it's still not too fast and it will probably become slow.

G

Again, I mean if we were to cut the sweet down to just happy parts. So basically one test per story just checking that stuff works, then we'll check all the wiring, and I mean if you want to refactor something you just pick. Your use case focus your end-to-end acceptance, whatever you want to call it see.

G

If that remains green, and then I mean, if you want to refactor stuff, obviously the units will have to be changed as well, because they're, coupled to the current design that could be kind of a middle ground compromise way to address this problem. Sort of thing.

B

I would say we could try it, but I suspect that what we have now is actually the best compromise, but like we could try, we could try to introduce this.

B

uh Our own interfaces around the clients and see how it looks like my suspect, is that it's gonna be very busy like it's gonna, be lots of new interfaces, lots of new tests to be introduced, and not necessarily because we also have to keep in mind that, like the lower the closer you get to the thing that you're trying to abstract on the less you're abstracting so like, if we make such interfaces they'll, be you know nominally that we will.

B

We would own them, but like if 99 of the behavior, if you're, just delegating you're, not really obstructing much. You know like when we mock those we're still making lots of assumptions right unless we test them again and like to test them. We need to choose a whole new test stream.

B

um I would try see how, like we take like the one of the busiest repositories we have tried to do. This experiment see what would come out of it. My suspect is that it would the cost would not.

B

uh It would be not worth it if what it gives us is yeah. We can test a couple of error cases that are otherwise not reachable provided again. Like perfectly, we will we're not going to find the perfect switch yeah. We can try and spend the morning and see how it looks.

C

That that's the that's the wrap is we were already at 95 test coverage so that that pr we made took us from 95 to 100 test coverage at the cost of turning our our test into a franken test right which nobody, nobody wants.

B

Yeah and like again, it takes confidence away like if you're mocking something again you need to have a test on the other side like.

B

I think this is something that, in that talk, everybody skips, because it's the last bit but like like, if you're mocking something you need a test that pins down that mocking that you're doing like if you're lying like if you're, if you're pretending to be someone else, you also need to have a test that proves that that someone else would do that in that mocking scenario uh and given we don't have tests for the kubernetes client, that would mean we are marking something that we don't really know.

B

If it's true, if we introduce these like thin abstractions on top of the kids client and then mock that again, we need tests for that and it's a whole new set of tests. So it could.

D

B

I would try it it could be worth trying it, but I suspect that uh again the if it gives us two three percent more coverage at the cost of. uh I don't know how many thousand lines of code it would result, because that was what we had in irini right. We had that extra coverage that extra mocking opportunity, but at the cost of thousands of lines of code. At some point we just decided to ditch so.

G

H

I was just gonna say if people still feel strongly about one of these approaches. I think I like giuseppe's, idea of spending. You know morning writing up a pr on this. It's a lot easier to have these discussions on concrete code than at this high abstract level. So I'd suggest that path.

G

It's not a very strong feeling, it's just something that, uh like we just recycled this idea today, and we will definitely give it a go and if it's worked, we'll open a draft pr, I guess to trigger more available.

C

Discussions, okay, so, while we're on the topic of testing and integration tests, we've been running this experiment now for about a month and a half where we don't add new api integration tests.

C

So I guess I wonder, is it time to get rid of them.

B

How did it go like? I know that I guess people have were surprised about. You know, defects that emerged just by writing more end to ends, but other than that, like did you feel like you were missing. Something in your development process.

B

Did you feel like it was harder to dry, stuff out or drive stuff out, or I don't know.

H

I was very reticent to try the experiment, but I I honestly don't have any complaints and I'm I'm on board to to tear out the old integration tests and just go with end to end personally.

B

Nice, so I guess we might have gaps, though right like if we just delete them stuff will be uncovered, so we need to actually go into.

H

B

We need to do an inventory.

H

Of what we might be missing for sure.

B

So that's another chore about uh basically yeah getting rid of the integration test, but first make sure that.

C

Essentially, try and backfill uh test coverage with.

B

With unit tests, I would say I I think I did one I did. I did it once for the for that. uh What was it for that action that had that bug about the flipped arguments?

B

I think that one was tested in that style. I went in and introduced the unit test, so it took me a morning by myself uh to do it for one file, so it's probably not a cheap change but worth it on the long run for sure.

B

Because it depends like that code was full of ifs because it's yeah it was the manifest one. So it was the one that was particularly hairy to test because it has like, I don't know, 20 parts and I had to test them all.

B

C

B

Think the actions.

C

Are probably going to be the worst of it right.

B

Yeah, but the manifest one particular because it's like okay, if there is an app if the app exists, if the operator doesn't exist, if the environment variable exists, like there's lots of conditionality, I I assume most of our handlers are not like that they're just delegating.

H

And that's it. I think in that case I think at this point we have a fairly um we test all this paths in the unit test for the action itself. I think and the handler we just only test, you know, does an error come out. We use a success case, so hopefully we're already a good place there, but we should definitely double check.

B

Yeah, maybe we could like. Maybe we could check coverage like by running the streets alone and see and look for gaps. I guess like running just the units should not give us a lower number than running just the integrations for starters, but also yeah, like the coverage of one, should be a subset, a superset of the other right, so that we don't leave anything that was previously tested untested.

B

A

Cool lots of good discussion that sounds like it's slowing a bit. So if you have last minute thoughts, you want to make sure you get in bring them up right now or we'll move on to the next topic.

A

Alrighty sold next topic is hnc v 1.0.0.

B

Yeah, just a quick one: uh they released the hierarchical namespace controller version 100., so they think it's production ready.

B

um I think their only major feature change. Is they finally introduced labels and annotations support? I don't think we need it, but now you can you know you can apply. You can ask the agency to tag the namespaces. It creates with custom labels and annotations, which I think is which I think is something that we wanted to have at the beginning when we implemented it, but now I think it's probably not needed, but yeah I mean personally.

B

I was just very happy that this happened, because I, for a long time we've been unsure about whether it was a bit of a debt project or whether it was making progress, but it looks like they actually felt confident enough to release one all so that it's a good sign that we're, depending on you know something that is actually maintained.

A

Yeah, definitely don't want to be in the business of relying on code. That's abandonware.

B

Yeah exactly yeah they've been talks about. You know replacing it with something custom, but it's not gonna happen soon. I think so it's good to be able to rely on this until then, if, if any like, if we're gonna, do it.

A

Yeah and the interim- it's definitely nice. I think the discussion about replacing it with something custom is still ongoing, um since hmc does a lot of nice things, but it doesn't completely fit what we want. So we still need to do a bunch of manual stuff, so um yeah, but, like we said very nice to have something that's still supported.

A

While we depend on it cool moving along, we have pr to skip a cat's test for cf for cates, uh for those of you that are joining us and are not totally aware of all the distinctions. Cf furcates is a specific product. This is this cloud foundry on kubernetes working group forum, which is covering the conceptual space right now focused on the newer projects, but uh we still discuss all of the umbrella projects so anyway, heading back to. If dave is here yeah I'm here.

E

Yeah, this was just a uh a note because um I'm part of the working group that maintains cf deployment and cacs and the cats pipeline is frequently blocked because of the testing we do with surface gates, and it's always this one test that that flakes, because it doesn't seem to always return the appropriate, insufficient resources, error message it just times out, and so the test flakes and that's probably 75 of the time.

E

So, given that we're in sort of heavy maintenance mode with that project, I figured the easiest thing would be to just skip that test. I don't think it's something we plan on, addressing to try and fix it. um So I don't think there's any value in continuing to win that test. When we run cats against yeah against cf gates,.

B

And we could even consider just not running cats at all. I guess it depends on how much we want to.

E

Yeah the concern I had there was that we we do still have users that we know are using cfocates and I didn't want to completely abandon knowing if we'd broken something major by not running cats at all against it.

E

You know, given that we're still doing things like bumping, build packs and bumping components as they they come through, um and we do have automation around that. I wanted the coverage of at least running the basic set of cats that we run. It's just this one test. That's particularly annoying yeah. It makes.

B

Sense and just turn that one off.

E

Yeah so yeah. If someone could approve the pr, then I can go ahead and merge that and shepherd that through ci, so that we're in a good place that way we can cut a new cat's release and yeah.

E

We can go from there.

A

C

You I'll definitely.

A

Take a look if anyone else wants to take a look as well, then that'd be great moving forward. We have project, naming updates, take it away. Friends.

I

I did this um kind of dragged chris into this too. I believe we have more definitive updates about the project naming.

J

Well, uh I haven't gotten clear word that the trademark applications have been filed as soon as that happens, we can use it publicly, but I think we can it's probably pretty safe to use it publicly now. So I don't think we need to be super hush-hush on this, um and I put in a request to uh you- know: linux foundation, creative services, which can help with a logo. um If any of you all want to talk about a logo, we can dig into that. um I also connected with eric.

J

Yesterday we talked a little bit about you know pulling in vmware uh marketing folks for this, but um yeah karify is it and um that should be no problem, uh we'll have the trademark applications filed if it hasn't already happened, then, certainly this week so anyway glad we figured that out. Naming things it turns out is hard, so well done.

B

Nice, do you so do you think we can start with the renaming? Because I think our main concern is. We have a bunch of things to rename.

J

Yeah, I guess that's it's a yes, uh like the the main repository. Do we want to rename that from yeah.

B

Maybe the slack channel and the slack channel yeah well.

J

I can't think of anything else, there's two things like there's the working group, which I think should probably stay cf on yeah right, yeah,.

B

J

Makes sense should be the primary project there um underneath that working group so yeah I'm, you know I'm not super opinionated on what you want to rename, but I would think that you know the the controller's repository would probably make sense and yeah the slack channel. I suppose, would also make some sense.

B

We need to figure out what that means like uh if there's links around or I don't know, if can we.

I

Just rename it.

B

We need to create a new one, I don't know how it works. I think.

I

I think you need to rename it if you have a link to it. I mean it's using some internal slack id anyway, so that won't break any links, so it can be just renamed. Oh yeah, maybe that's easy, then.

B

Yeah I mean my concern: is: can we do it now? I can, can I stop putting trolls in the backlog for people to do this, or is it too soon? No, because.

J

B

Consider this we consider this like a blocker for releasing, and we are very close to release like I think the milestone is like 95 done. So, if I need to add these things to the backlog, I want to do as soon as possible so that we can release as soon as possible.

J

Yeah, I think you can go ahead and do that um cool nice.

J

Another question like um I actually haven't, showed this on here, but there's a I've got a list of cloud foundry, orphaned repositories, um there's a and there's about a dozen or so cf for kate's uh repositories.

J

I guess now that this is going to reach ga I'm wondering which of those if any, this working group is going to maintain or what needs to be maintained or should can those all be like as soon as we have the initial release for this, do we want to officially archive those?

J

I don't know: okay well,.

B

I'll yeah, I.

C

Don't know like I don't know in general, I.

B

Don't know what it's it ties back to. You know the level of support we want to provide for cfk. It's um right.

I

I think I think that we we might need to just consider. You know there are a few ongoing users of cf for gates and it seems like it'd, be a little bit rude to you know. We've had announcements that you know this is the the creepy stuff that that we think that that's the future, but it'd be good to validate that they can start moving that or onto that or start playing around with it right before we just like nope. Sorry, you don't get that istio update or you don't get.

J

I

Cloud foundry, cvd updates or anything.

J

But in that case, then the the cf4 case repositories that are going to be somewhat maintained. You know, need a home. So I'm wondering if this working group is going to be that or uh because right now, they're sort of just on their own.

B

J

B

At this point, if, if we want to maintain them for a little bit longer, then maybe it's better to make it explicit that they're ours, because otherwise they're like no one's land and.

J

Yeah right now, they're just sort of you know they're there and uh but but no one's explicitly responsible for them. So.

B

Yeah I mean you: can pr the working group uh thing on the community repository to make this explicit. If everyone agrees.

J

B

You can provide me with a list.

J

Of the repositories yeah I'll, actually I've pinged a couple of the working groups about this, but I'll just drop this. um I don't know if you might need to write edit access, but if you want to take a look at this there's about a yeah about a dozen cf4case repositories that are they're named that, um and so, if you want to take a look at that, we can figure out which of these could maybe be archived cool.

B

Yeah I sent you an access request.

J

Granted granted nice good cool.

A

I'll worry about that later, yeah, not this isn't urgent, but um figured I'd just bring it up now: cool yeah. I do think it makes sense for this working group to absorb those, since they do fall under the umbrella and then.

D

A

At that point, there's some tracing for what decisions have been made and we can actually sort of justify what we want to do with them. Cool.

I

Yeah and then that's a little more explicit now now you can have that pressure and the working group charger and set of responsibilities to say like okay. We want to retire this stuff and focus on the new thing.

I

Yup makes sense.

A

Cool all right, so moving on to what looks like our final topic of the day, could we collectively help fill out the pr worksheet for creefy.

K

That's what this looks like yeah, so I think this is a different pr than the group is uh typically used to um so pr in this context being uh press release. So one of the things that the foundation is basically chris and I do is we work with the pr team who basically assist with a lot of the marketing sub functions, and so, if I have not said it enough times before, there's a lot banking on this iteration of uh the cf on kubernetes effort.

K

So one of the exercises that we have going at the foundation is having our pr team help us position. This put out a sufficient number of bylines get enough eyeballs on the project and basically help spread the word as much as possible.

K

So they have a sort of set of ideas and questions for us to be able to work backwards and get the project ready um for uh quote, unquote, public viewing and one of those things is a bunch of pr's that they typically send out to their usual channels.

K

So this worksheet that has been shared that thanks andrew for putting that up, has a bunch of questions that would really um benefit um some answers. um But what we're looking for is basically some uh good inputs. Now we could go through uh some of the questions, if that's okay with folks or if people want to put their inputs in um individually and maybe want to circle back to it at a later date.

K

um That's kind of okay as well again, it's all anonymous so feel free to put whatever um you want in there um well within um permissible community guidelines. But um I guess a couple of the more important uh inputs that we're looking for is in terms of the date that we want to announce um if it's a beta release or if it's a v 1.0 or if it's a v, 0.1 or whatever it is that we want to do.

K

I think it would be great to have some answers about that and start working towards making that information available publicly again. Some of the questions in there might be kind of out of scope, for the group feel free to ignore those. But if folks want to, you know, start taking a stab async.

K

You know you're more than welcome to do so.

B

Do we want to have this filled out like before we release as we release like you know, or in other words, should I consider this as another blocker for for the release or.

K

um It's not quite a blocker, I guess um it will definitely be filled out and submitted to the pr team before the release. um It's um it's just. I guess um one of those things that that would benefit from uh input from the team as a whole.

I

Yeah, it might help to distinguish between gcp. I think you're thinking about the github release like getting bits out that are stamped 0.1 right, yeah you're. Maybe thinking about what inputs do we need for a press release from the foundation yeah.

B

Yeah, I know what I'm saying is like: would it be better if, before we made the thing public on github, this was ready, so that or like? Is it fine for us to just put stuff out of on github tag that zero one and then like? We can do this with time, because the thing is even if we put it on github, it does like it's not like we're spoiling anything.

B

It's like it's there and then, if, if the press release comes out a week after I don't think anything is gonna happen, and then the name was the main blocker, because we want to release with the new name to avoid having like a release with a name and then the next release, with a different name, which would have been weird but yeah. Maybe we shouldn't wait for anything else, just to put stuff on github, we can put stuff on github and then it can be.

B

You know it can be publicized at that later point. If, if we need more time to to get the stuff right.

K

In that sense, definitely not a blocker gcp. So, okay.

B

K

The project announcement as a whole, so I think the incremental github releases can happen in parallel.

K

A

Yeah, um I think, from my standpoint it's probably best to have a look over the document and do some thinking and generate a little bit asynchronously. But I'd be happy to schedule like another meeting. If you want to walk through some of that, once we at least once I've had a chance to think about it, um not sure how others feel we can take a stab at a few of the questions really quickly. But uh yeah might just take a little bit of thinking and I think.

B

Yeah, maybe you.

A

B

Review it together and then at the next meeting in tweaks like provided there is something in there by that time,.

A

Does that work uh ron, if we.

D

Absolutely fill.

K

A

Next meeting have it as an item to review what we've come up with sure.

K

um I'll follow up on the slack channel and post like a reminder or something folks and uh yeah.

A

K

Review during the next painting.

A

Cool perfect feel free to uh reach out directly to me as well and I'll try to make sure that I uh get some people adding some text in sure. Thank you cool. So it looks like we are at about the end of our list. If you have any last minute topics you'd like to bring up, please do so otherwise we'll wrap it up, and everyone can have a little bit of time back.

A

Going going gone awesome well, thank you. Everyone for attending again the cloud foundry on kubernetes.