Cloud Native Computing Foundation TAG App Delivery / Bi-Weekly, 19 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: TAG General Meeting

Description

TAG web site: https://tag-app-delivery.cncf.io/
TAG Slack channel: https://cloud-native.slack.com/archives/CL3SL0CP5
TAG git repo: https://github.com/cncf/tag-app-delivery
TAG meeting notes: https://docs.google.com/document/d/1OykvqvhSG4AxEdmDMXilrupsX2n1qCSJUWwTc3I7AOs/edit

A

A

B

C

C

C

Hope everyone's all right.

D

Hello, everyone I think we have quite a packed agenda for today, so just checking whether all the presenters are here today.

D

uh Okay, we have presenters from pipe City who here today, Mike rocks is here today as well. Victor I already saw.

D

All right and I would actually kick it right off with the pipe City presentation. If you find Trend right.

E

Yeah yeah, thank you. So, uh let's start with me: okay, yeah.

D

That's fine, take it like probably 10 to 10 minutes plus questions. Ideally.

E

Okay, uh uh let me share the screen.

F

E

Okay, you guys see my slide.

E

Okay, so uh I will start with uh my presentation about 5 CD and uh my name is Pang and you you I can call me. Please and I want to lose I use the same slide and create all the peoplecon, but uh not yet use, because I cannot go offline there. So sorry for that and uh today the agenda will be like this and I will start with uh the reason for Five CD.

E

Is this and um the story start with our company, our company structure, and you can see that uh start from the top we separate to multi-department and each department has multiple team and interesting point here? Is our company?

E

We don't have any kind of guideline or something and standard and each team have their own, have a phone ownership for design what platform and what CD they want to use for their product and they maintain it for themselves, and the boy is uh one day.

E

Everyone you know that uh beat off is something that uh we owe one to have in our forecast, and uh our company decides that now we want to introduce the bit of style, CD system for the whole community and the standard and um we're facing the problem that faced many, so many platforms is using and so many different things are using across the company. So how can we have a single standard CD that followed the offside for every team that easily to adopt? That's?

E

Why we create pipe CD, because we do not find any existing solution for that and uh what we aim we have for CD at the time when we create by CD, is uh something I noticed here. We want a consistent process for all platform for our team, and um this might be easy enough for everyone and it's much uh as a modern CD. It should be provide fast and useful feedback loop for the safety uh in context of cicd, separate and a heat of style, CD I think is um profile.

E

Is the feature that provide by 84, so I don't have it here. The CD the pipe CD is uh privacy is the consistent it's followed by um in mind so uh yeah. The flow is straightforward and simple: you make a PR to the configuration the people and it is review and most and uh by CD will take care of the rest and um I post. Here is some example for cloud run: application type you can see here. The fly left the right off.

E

We have uh configuration directory for the program application and you have to Define service and have to define the confusion, 545 CD, and it's look like this and you will get the pipeline that running for the right bottom.

E

Interesting thing is for communities application. This is exactly the same. Just one confirmation file and the whole manifest Compact and uh you will get quite Sim pipeline. The different only different one is the pipeline contracts of different state. Let's check with the with the application type that's all and um for easy for everyone. The process is, is straightforward and NSS you access previously. We just need to prepare a confirmation and you need to install a package agent and that of 5pd will take the rest after the yeah.

E

Almost for the pipeline for the pipeline construction is easy and consistent for the application type. Currently, we have two kind of state that we use to construct a pipeline that is guys check, something like Community, run out primary run out and uh go run promos and something something and some kind of common state like with with approval analysis and a custom bind, is custom by mean that uh you can use binary to run the state and uh easy for you.

E

Everyone number two is maximum the visibility and it is the simple view of the pipe CD application detail base. You can see some interesting information here, like the application sync state and uh below is the different. uh The diff between the light and the heat manifest that's showing in detail and the below is application information plus the live state layer.

E

Rocd- and this is a simple deployment detail base- you can see that uh one pipeline is viewed by multiple States. Just like we write in the pipeline information and click to watch that then so the log for the point State as well for the next Point. uh Our solution need to have a I, don't need to provide a fast and useful feedback, and that's why we think useful feedback should be provide just not only just the time when we apply the manufacturing.

E

But now we need that through the CD work, so um we decide to have I mean uh we have future to support and feedback through the deployment. On a brief on a post deployment for pre-deployment, we have brand preview feature. The plan preview feature is something that supports you to have a quick look at what will be changed in your cluster even before you actually must the chain to the with report.

E

So you can see what will be changed before the CD really cheaper, so it's safer and it easier to uh to review, because the Manifest changing is sometimes it's too much to just review five by five. But now we need a glance to uh actually understand what will be changed uh for the on deployment. We have Progressive delivery. uh Basically, it's not supporting Canary and uh moving button, and besides we also have the idea you call it idea. uh That's something. I saw you before.

E

This is one state deployment. You can see that we have an analyst State and the analyst set at the analyst that we use the metric that collect from Magic provider like data doc or premiers and promoters, and we use that metric to decide that the canary run out is okay or not. So if any problem exists, we can automatically run by easily for the Post deployment we have the deployment inside feature.

E

That's something that um the information below we uh follow the four key, the four key. um What can I say uh the faulty who I mean we need some as developer. We need something like uh deployment frequency for our application or the valuation rate and um the time from the start changing until the chain is applied to the to the rear cluster and something like that and uh the the deployment inside feature.

E

That's showing you all the things that you need, and next one is about maximum automation uh and I said 5cd is just CD and we're focusing only on CD, but it's not just like that. We also have a way to interact with CI as well and for the CI flow.

E

We finished, boosting the artifact to the artifact hub and after that we have uh a way to trigger the CD run automatically by a feature called even Watcher, and with this feature we can automate our flow from the code changing and uh running until you see the automatically trigger and uh we can plus with the plan preview, feature to understand exactly what will be changed and after we must start the CD we'll actually be quicker and run next. One is something I think is interesting for you guys.

E

This is the the point of having one interface for every application guide. Is the development chain feature, and you can see here in the telephone application configuration after the application of title from the thing successfully I can trigger to running the next deployment in chain, and the interesting thing is that the next application would would be cheaper can be whatever application guy that have been for the invite CD system.

E

The thing simply just look like this uh first thing is an interform application after each uh be checked so safely, the posting engine trigger the next application uh and, uh in my previous, uh simple config is cheaper by name. The name is application to Enterprise City win file, whatever application tool name, and uh this could be Humanities or Cloud run or whatever, as the group 2 and after that the front means the next one is application free of the communities just like that.

E

So uh you can view a phone um system of whatever type application missing in with a single, simple application configuration next, one I could say some status of my city at our company. Currently we have a buy viewing application, Plus platform provider, each platform provider support one kind of application. The type CD can deploy.

E

Currently is data from humidity's gcp cloud run, LS, Lambda and uh ECS, and we are trying to make it programming able and plug-invertible so that the community can contribute that for us and currently over 201 700 application ODB managing by by city in our company already for the future work uh the have something in our roadmap.

E

First, one is maybe block enabled the second one is uh some feature like Bridge mutation currently is not working well for ECF and Lambda application, so we'll be trying to bring it to the guys application as well, and um this one is we need. uh We we think is could be great if we can bring more information than the new feature so that the developer can easily review.

E

The sun is um thinking about make more provider for analyst set and, of course, the community ones. We apply for join cncf sandbox, and this is the end of the slide. Thank you.

D

Yeah, thank you for sharing I'm opening up for a couple of minutes of questions.

E

uh So uh yeah please.

F

I guess I can go first. um Thank you for the presentation it's really interesting to watch. Can you describe a little more around who the op typical operator would be writing these pipelines? Do you differentiate between um a product engineering team who just use it, or would you see this as being something that they would own as well? Would they write their their kind of their events that they're expecting? Would this be something that devops and SRE Engineers would do more.

E

uh Structure, I uh I think put a minute.

E

I have a graph for that question and you can see here that uh the bad City system, designed by uh two components, the big one, is the control plane and the second one is the the Asian and uh in our design, the platform team will be the host and uh operating for the control plane and each team in our company you stay, they will install apply the agent in our uh in their cluster and it can be whatever they want, and the developer I mean the product team will be in Chain of uh installing type B and they've been they've been right.

E

Now the configuration for their own application, the team structure, type of software engineer and Si member shop with the same team. So they can easily I mean they. Can they already have their ownership of what they use and what platform they use so manifest creating is the is their own ownership and the green view that so uh you can see the graph is, and so what you question.

F

Yeah one follow-up question. Thank you. um You know what efforts have been made to lower the amount of knowledge that a team would need to to onboard to this I. Think that's what my first question was getting at like what what are the things that you've done in this project that really reduce that overhead of knowledge, complexity,.

E

What do you mean? You mean? uh What is that the projects.

F

As a as an engineer deploying in cluster a b or c, how much do I need to interact with pipe CD.

E

uh They have an UI for that. They have an UI on control plane and they they need only to use the the agent one, the 5D agent, one and after that, whenever they have a new application, they just need to create a simple application configuration and, after that, it's just like a normal eat off thing. We can just change. The configuration report must must request and everything else will be automatically handled by the 5D agent and they can build the deployment State view the deployment Pipeline on the UI CD platform.

E

They do not have to do anything else and we we want to bring it for any type application, not just the community, and we already done it for zero form. So I'll run ECS and Lambda.

F

One final question: thank you in the kubernetes app kind custom resource when there's a canary rollout. How are you able to determine the signals for a successful rollout? Is there a way to to hook into lightiness and health checks.

E

um Yeah you can see that uh um or the talking about the idea, I mean wait, a minute um wait a minute. We wait a minute.

E

F

uh That's okay, I can go, read the docs. If it's there.

E

Okay, I mean this one uh for the runner. Basically, if you do not I mean you can have two kind of uh apply, the first one is you just apply and um you don't care anyway. So basically, we do not have any kind of health check or something. But if you really care about that, you can add this kind of analysted instead check for the health hell check by uh regress or by Metric or log.

E

We currently support three kind of analysis and uh if I mean this configurable State and you can configure something like you want, this metric is the metric about these things is the 50 bus or something like that. You can config it and how long you wait for that. You all can appropriate via this one and because this one is independent from the application guide, you can use the thicknesses for the communities but yeah the application guy as well so uh yeah. That is supposed to make it separate from the application. Syntax.

E

Okay, so uh anything else: okay, four question: yeah.

D

I think, looking at the time, thanks for sharing it uh I'd also advised to stay in the delivery chat. You posted all the links in there, that's great, so that people can look it up.

E

D

Would propose moving on to the next presentation.

D

Which is obviously.

D

um The microx presentation yeah for pipe City, please add some links so that people can find all uh the details and, let's move on to Mike rocks. Please.

G

Yeah here we are awesome, um Yasin I'm, one of the co-founder of microx and we're going to share a short presentation. So this is a the second presentation that we have in front of the tag group. uh This is a follow-up of the first presentation that we we have done at the coupon Amsterdam and so I'm going to try to make it short on the intro, because maybe a recap for some of you.

G

It's um microx is um an open source project, kubernetes native, fully dedicated to API, mocking and testing, and we clearly focus on Enterprises pain and we we would like to help Enterprises to accelerate and secure the API and application Cloud native deployment, and to do so. uh Micros is not only a tool by developer for for developer, as we also aim to create a bridge between owners and asset within Enterprises and organization by owners. I mean all the parties within a company which means developers, of course, internal and external, but also Partners.

G

If you are using some and product owners, business owners, because that's important for us to have a collaborative tool between all this party within the same organization or multiple Organization for the same purpose, next slide. Please, um because by asset what I mean is all kind of apis. And why? Because clearly we we really think that the single type of API does not fit all there's a huge amount of diversity within the way you can use API, develop API, different specs and protocols, and this diversity is important from our point of view.

G

First of all to take care about the Legacy system and all the organizations who still have some uml and sub UI application in production to help them to migrate and modernize their application and move to open startup like open API or a solution like grpc and graphql, but also to mix and match with even driven system and reuse.

G

Postman collection for testing purpose, for example, and one of the biggest uh value and and brand for microbes and something we are really take care about- is the fact that we would like to provide the same and single approach in order to manage all this type of assets, specification and type of API or different type of protocols.

G

The next slide is yeah.

G

I, just want to to drill down a little bit on async API, because something it's something which we're missing from open, View and and we've embraced the async API specifications since day, one because we clearly think that is it's important to have something in order to specify async protocol like we, we've been able to do it with swagger and open API, and that's why we micros has been at the good teenage of async API specification, and today we already have a support and integration of eight different async protocol, Within microx I'm not going to name them, but the latest one we have added and the commit has been done today- is AWS sqs and SNS, and that's based on community user requests and next slide.

G

And that's where we're going to change the way we're going to do our second presentation, because we really would like to Showcase what we have in n and what microx is so long up to human.

H

Thank you Yasin, so hi everyone, I'm Laura I'm, also the co-founder of the project with Yasin and I'm on the technical side of things. So here's a brief demo on the project features. So uh here you can see there is a an empty microxine sense and I'll try to illustrate the best. The different use cases micros.

H

So first you can use it in uh with the UI or in a pure and less blue apis, and what we have is obviously an empty repository and with my crops you can fit the repository using different methods. You can push Channel recommits your artifacts to micro, so you micros can pull your git repositories for you in order to to discover it and update API definitions, or you can also use a hub and we are going to use a hub here.

H

It's like a public Community Marketplace when you can put products, standards or Regulatory apis and thus share your marks and test shoots for your apis, so very ND for Distributing test shoots for open banking or open Insurance toggles, for example. So this is the way we distribute our own samples and we start with the mandatory API.

H

Everybody must have the one related to pastries, so I can easily install it into my microcene sense and once I have imported my API definitions, I will have an API plus three endpoints, and this is a live Imports, with all the operations being simulated and being available uh cool as yes live endpoints as they like they have been developed.

H

So you can see that it's very fast to deploy sandboxes to allow people to try out new apis.

H

So it's really shortened the feedback loop during your design, iteration, because the MOG definitions is always in sync with the latest revision in your repository, and it's also is the life of developers because they can start developing without waiting for API or microservices to be ready and so so very handy to build complex environment.

H

You can see right here that these are Dynamic mocks for each and every operation, and the nice thing is that microx is inferring Behavior dispatching rules depending on your artifacts, and it provides a smart departures to implement tricky things. So, for example, you can route on different uh yeah some different parts of the URL. You can route on the body content on other content, and you can also Implement your own routing rules, micro snows, the the different specificities of the different protocols.

H

So, for example, he is able to realize content negotiation for rest apis, but also to to realize um attribute selection for graphql apis to realize, of course, protable serialization for group for grpc, and it can also simulate your response time of your API. So really provides a a handy and uniform approach, whatever the different kinds of API.

H

So let me, for example, install a new grpc API definition, and you can see that the same way of doing things right here: Let's, Stop, Now, with uh with graphql, and if I now check the repository, you can see that I have all these types of apis that are managed the same with ready to use.

H

Let me show that ready to use endpoints like here if I want to play, to discover with to play with and to discover some some apis so really easy.

H

um Next thing we are going to see it's uh not the samples, but talking about a real life application.

H

Let's say, for example, we have a real application with a rest API that resistors users and we are going to see the Second Use case of microxin action- is about testing, so here I'm going to use the the import for from git feature to just import. My new registration API, so I can activate and connect to git and it retrieve the API definition. So this is my user registration API right here with a just one operation for registering users, and this application in fact has been already deployed onto my kubernetes cluster here.

H

It is this: is the user registration with the Ingress, and this is my application, and what I'm going to do right now is use. My Crocs to check that what's have been deployed is actually consonant to my open API contract, so really easy with micros I can launch a new test.

H

Okay, just putting here my endpoint, my ingression point of the real API I want to I want to check okay and right here, just choosing a runner, so a runner allows you to apply a testing strategy so right here we're just going to test what everything that has been deployed is confirmed with my open API schema, so really easy just to test I've launched it manually.

H

But of course you can load this into your cicd pipelines to be sure that with each and every deployment you do not introduce breaking changes or regression into your your API or specification. So, for example, I've record everything. So it's also very handy to be used to compare behavior of API into different environments and troubleshoot things.

H

So, just to finalize the demo, we can now add some more events, because in my real life, application I also want to send the event each and every time I register a new user and I'm going to send it onto a Kafka broker. That is just right here. A Kafka broker. Yes, that hosts topics for gathering this.

H

This events, so thanks to the async API support in microbes I, can also import a new async API definition, and you can see that I have now a new event driven API with mock messages that are published to my connected Kafka broker. So as a consumer, I can easily grab those events that are produced each and every 10 seconds, for example, this is default and I can start playing with it without having to wait for the the producer to be ready. So you can now yes gather some new events.

H

Let's wait 10 seconds if the Democrats- yes, they are with me, okay, so as a consumer I can start working without having to wait for um for the even producer.

H

Okay, um you can see by the way that there are some Dynamic thoughts in my events, to allow some better simulations, so using some expression, I can Generate random things to have better illustration of a real life and smartmox.

H

The final question is how I'm going to test all this scenario, how to be sure that my rest API is conformant, but it also triggers the publication of an event. That is also confirmed, and that's the nice part with microns, because you can have all these kind of uh testing scenario with micros we've previously seen the the synchronous part, but microx is also doing the same things for events is able to connect to your application broker to listen for messages, and then it tries to validate them according the schemas, that is in the spec.

H

So it could be your own schema, Json, avoskima or Cloud events based schema, for example, and of course you can put everything in a pipeline. So that's what I've just Illustrated right here. So you can see here that there is a tecton pipeline that is using this feature. So, just after having deploy my app I am launching new microbes test, and these are parallel test on one hand: I'm testing, open, API stuff. Regarding my register API and on the other Branch I'm testing, the Sync API steps checking that there are messages.

H

Events that are published are calling me to my specification, and the nice thing also is I can do exactly the same things if I'm a gitlab users. So basically we provide a tecton task, but also plugins to be able to to plug micro's check in each and every pipeline series uh possible.

H

That's it for the remote. So just a quick summary uh trying to be be very, very short: we've seen the three goals we are we tackle with micros. The first one is that we are using microx tool to shorten the feedback loop.

H

We are deploying smart simulations of your API before it exists, so that you can iterate very quickly on your specification.

H

We are also using microcs to to ease the developer experience to allow parallel developments and but also twist, the the build and the deployment of sandbox, and we know that this could be a huge pain when turning to microservices and trying to to cope with dozens, hundreds of microservices, it's regularly a huge pain and the the third one is that we are using microbes to to check that everything we've deployed is confirmed with the spec, but also we did not introduce breaking changes.

H

If we want to to follow semantic version is principles if we don't want to to break the the compatibility rules, for example in Yasin up to you for the conclusion, yeah.

G

Just just to wrap up I mean this is just to illustrate that we are really ecosystem focused and we already support and our fully fully integrated with some cncf project and open source Solutions, and we also have a public run materialist purpose. So that's just to let you know that there's plenty of tool which are already supported and and stuff which are coming in in the in the roadmap and the the latest slide is just to to to to to to Showcase that we already have some adopters.

G

So we have a list online, uh that's something that we have created a few weeks ago. So it's brand new to be honest, and it was to support our sandboxing mission as well. But this is a testimonial from uh JB Hunt, which is from openview very, very interested based on the fact that we are clearly expressing where they are coming from why they have selected microcs the pain it has been able to sold out and and win and what it, what we've again from an application life cycle development point of view.

G

So here it is, uh and thanks for listening, hope, we've not been too long and happy to answer any question you guys may have yeah.

H

F

I, just have one very quick question because we're very short on time um are you going to create exporters to generate client sdks eventually.

H

uh Yes, very um so um currently we are working to enrich the the set of crds that already exist into our operator based deployment, so this is a way to to interact with microbes and to even more automate the creation of sandbox, for example.

H

This is a very, very frequent use case that is asked by the community, and we also during the during this work around the crd, we're also working on creating some kind of uh um SDK or official client to be able to yeah to allow more interaction with uh with micros between design tools between also catalog tools. We, we recently published an integration with backstage so that you can gather API definitions from microx in order to sync them into backstage. So, yes, this is definitely on the on the roadmap.

B

C

What did you mean by secure I, just I noticed that you called out that these can accelerated development and secure apis.

H

um Secure in a way that um uh it allows you to really enforce all the checking all the complements, checking that are absolutely necessary when you develop apis, because we all know that the the hardest thing is not to deploy the 1.0 version of your API. It's to deploy the 1.8 and being sure that you do not break anything regarding the 1.7 and 1.6 or the the the all the consumers are still using the 1.4 contract for interacting with your API.

H

So that's what we mean really by secure in a way that, yes, you are securing the delivery process.

G

And, and also being able to facilitate and fully automate the QA process as well.

A

I personally, like the idea of using this in Industries like healthcare, um where I as a developer, might not have access or need access to personally identifiable information and stuff like that. But I need parity with the apis as they're developed. So I really like that use.

G

Case so we hope that some of our community users can express publicly what they are already doing in this type of area with micros. Yes, because we already have a pretty nice use cases and users in you know we're doing Healthcare, Solutions and and same as a and by the way, that's an important command regarding all the personal data and the data set that you can use, as example with microx.

G

You can use that on-prem in a closed environment, with a set of of data which are maybe sensitive for the for production, but that you can use, as example, within microx and and share with the others, without, let's say, less worries about exposing real data.

D

I think this is super interesting I think there's way more questions, though, first of all, I'd invite you really to try and attack ability, reflection in the cncf, where people can uh ask you questions. Maybe we come back for a more deep dive based on the question as well, so you always invited to do so, thus post any additional supporting links as well. Please it's really. We have a very busy agenda right now and I'm, definitely deliberately holding back on questions that I don't want to ask offline in as part of the chat all right.

D

The next topic for today, Victor.

I

Okay, I know that we are almost out of time, so our questions shall we do it now or.

D

At least I would like better understand where you want to go with this. One I mean we still have I mean we can go almost on top of the hours. If you can't give us just maybe a 10 minute, rundown sure.

I

Okay yeah, so what we did is uh basically summarized in this image. We were discussing for a long time we're in gitlab. How should we discuss the environment because everywhere we stay discussed it's about the pipeline and gitlab has a TI pipeline, so at git love as well.

I

It was about the pipeline um uh on slack when I wrote about it, Justin brought back uh with a link that shows you very well how much it is pipeline focused because the CDF created these two amazing resources that you can really if you want, but what we wanted to look at is really how our from the user's perspective, how does it look like so from the environment and and what what's there and we came up with this glossary uh up to this point, I haven't seen uh similarly documented process to discuss the uh environment and and the whole uh domain.

I

If we are not focusing on the pipeline, which, in a better world, would be an implementation detail. So my question is: if this sounds interesting, put a tag whether we should we are definitely happy to move it over to the uh tag. If it's interesting for us to document it there and and actually gitlab would just refer to that, so that's totally uh fine for us and that's why I thought to um to propose this little topic for you to to think about it.

I

um I thought all of you have to lean forwards to see the font size, but if I increase the font size, then it won't fit the screen. uh Let me stay, do it? I will skip the the bottom part, because those are very uh basic elements and then this way it might be easier to see. So, basically, what we say is that there is something we call an environment uh that has a Target infrastructure, that's where in the end deployments will happen through the environment and there's a rollout stage of each environment deployment pair.

I

Of course, environments have configuration, that's attached to them. Deployments includes applications that have a configuration as well and the application is built up of artifacts. So, like that's, the these are the core entities that we that we managed to identify um in the past years. I would say, um and- uh and we think it's quite generic- to be useful for uh parts of a white paper or the common vocabulary to to speak about application delivery.

D

uh Yeah I mean there's lots of projects to like use very various points in here in like the different, even with different meanings like. Even if you look at the term, what an application is as.

C

D

Depending on the tools, depending how the different meaning the same for rollouts and and others, so my question is: what would be your desired outcome of this uh instead of crds that describe this.

I

um I'm not sure whether that's uh for me, it's really it's to to have to make it easier to discuss for our for the users what what what's happening in in this Fair, because, as you said there are, there- are lots of different uh tools with different vocabulary. Actually, what what you see here is not the gitlab vocabulary, so gitlab doesn't have anything. That's called rollout. It doesn't do anything, that's called an application.

I

So it's it's not our vocabulary. This is what we have claimed that uh resonates very well with our users and that's how most of our users spoke about these things and uh we tend to move towards this vocabulary. For that reason, um but actually it's uh my essentially my impression was most not as we recently the the platform uh white paper and and stuff like that it.

I

It could help a lot to have uh a common vocabulary to discuss these terms and not technology focused so not focusing on the pipeline and those details there, but pre-focosting on the on the end user uh primary entities that that uh flow across those pipelines.

D

C

Mean a little bit on API, which is what I think Eloise is alluding to with saying, crds and stuff like these are names that could apply to an API.

I

Could yeah they could.

C

It's more about demand like semantic medium, meaning meaning or for human discussion, is what you're we're.

I

Getting exactly that's what I'm? That's what I mean so we didn't have. We were thinking about about introducing, for example, application crd for gitlab uh for kubernetes rated uh things, but we have. We haven't made the decision yet whether we want it or not,.

I

It's more it's more for human discussions.

C

um One thing: wherever we go right now, it might be good. We want to encourage people to open GitHub issues for these things, so people want to discuss asynchronously.

C

um They can so maybe maybe open an issue on this I.

D

I think this is a good and vocabulary is helpful and somebody would need to do like the extra work and look at how which different application definition exist. I think that another thing and I know that Thomas has already done some of this work like out of our rollout definitions and therefore are different, different and and the same and like what people really specify there I mean this goes obviously Beyond. Just the human description, but like algor rollouts has a rollout descriptions.

D

Flagger has rollout descriptions yeah and we could go on like this and how they're the same and how they are different, and that might maybe result in a more standardized, API, Downstream I'm, just saying right, because obviously don't think it's uh that I'm not entirely sure how far we can get there. uh But my proposal would be to also socialize this with the projects uh as well. So I think they could definitely open an issue that people comment and I think is a very good idea.

D

We might have to just break it, maybe down later on into smaller chance. It's just application definition. Since we started to talk about this, it is really challenging by itself not even including robots, environments and others. Also, some people have very strong opinions like Cuba people, for example, too.

D

um Others do as well. um Yeah I think raising the issue and uh I mean it would be fine to see okay, what's the commonality- and maybe were some more common API- might get out of this eventually and yeah, maybe just starting with okay, what it is and even like listing the different possibilities. That's where I think quite some work started in the beginning, just listing okay. This is how different people see things which would be helpful, but my proposal would be to socialize.

D

It also with see the other projects, because I think if you have them on board- and you see that there's some willingness to agree on some topics- there I think it could be super helpful or even just for people understanding the different uh of those special specifications.

D

Yeah. Maybe let's discuss it in the next meeting, also giving you more time and seeing maybe what the feedback of especially the project is that use these definitions. Obviously Beyond gitlab.

I

Perfect thanks for the quick feedback and the early feedback.

D

Oh I think we were heck yeah. It was slightly over time uh here, uh Lots going on today, uh thanks again for the presentation please again feel free to post. Any additional links in the agenda uh also check that Gap delivery selection, less people might come up with questions after those meetings. Some are also watching the recordings later on and are not joining the meeting. So uh I would appreciate if you make yourself available, and it just.

B

D

At least infrequently check uh on these topics, thanks in the beginning, yeah um all right, I think we'll meet again in uh two weeks. From now.

C

A few weeks, actually, three, the first and third, oh yeah, one we miss uh May 31st, is a Wednesday first, five Wednesdays.

D

Okay, yeah good and, uh by the end, just as a quick catch up, uh I also work on preparing, because we have to now run the the re-election out of the TUC chairs uh and I'll show you some updates on the process and in the next meeting already all right thanks everyone for joining very interesting uh presentation, great for the new projects as well um go to see more happening in the app delivery space. All the great we have now testing, also appearing pipe CD, also looks very interesting.

D

Some of those Concepts look incredibly familiar to me so also looking forward to trying out those uh those tools as well. Also, if you have a getting started tutorial, please also post. This, that's I think most likely the easiest way for people to get started, uh because you know people usually want to try it out with some examples. If you have those and I think it's generally a good idea to have an easy, getting started to work on those topics.

D

Yeah- and what's this thanks, everyone for joining today see you again in a couple of weeks and yeah.

F

See you otherwise. It's like bye.

G