keptn Developer, 27 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keptn Community Meeting - November 27th, 2020

Description

November 26, 2020
Diary - what happened last week?
TravisCI stopped building on Monday (and still not building 😟)
Keptn Community Meetings now included in official CNCF calendar: https://www.cncf.io/calendar/
Keptn community meetings renamed → Keptn developer meetings
Are you speaking about Keptn? - let us know and get some swag!
Next Keptn User Group: Keptn Quality Gates with Argo and Jenkins for Distributed Load Testing – Lessons Learned from Intuit - register here: https://dynatrace.zoom.us/webinar/register/WN_aL8Y-KApSpmoGVmZtNP39A
Most probably: December 16, 2020
New Keptn Sandbox contributions:
Splunk Service https://github.com/keptn-sandbox/splunk-service
Selenium Service https://github.com/keptn-sandbox/selenium-service
Monaco Service https://github.com/keptn-sandbox/monaco-service
Sketch of new Keptn frontpage:
https://docs.google.com/drawings/d/1zEDuaEppkLJupgfdQrbmaGnykwhzPYRrTbYg2iiq6e0/edit?usp=chrome_omnibox&ouid=105860236658938557986
Noteworthy Issues & PRs (Review)
For each PR, please tell us if you updated the docs, or in case it was not necessary please say so.
Ermin
https://github.com/keptn/keptn/pull/2714 - Re-add the version check into the root command
Florian:
Updated Argo-service to use CloudEvents 1.0: https://github.com/keptn-contrib/argo-service/issues/12
Johannes:
(ready for review) Explain requirements for execution plane services: https://github.com/keptn/keptn.github.io/pull/665
(WIP) Formulate spec for Keptn CloudEvents for reserved delivery/remediation tasks and implement dedicated types in the go-utils: https://github.com/keptn/keptn/issues/2107
Roadmap → KEP / SPEC / Issues
KEP 06: The next generation of Shipyard: https://github.com/keptn/enhancement-proposals/pull/6
Work in progress:
https://github.com/keptn/keptn/projects/29
Backlog Refinement / Next Sprint:
https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Akeptn+user%3Akeptn-contrib+label%3A%22next-sprint%
Planning Board: https://github.com/keptn/keptn/projects/29

Learn more: https://keptn.sh
Get started with tutorials: https://tutorials.keptn.sh
Join us in Slack: https://slack.keptn.sh
Star us on Github: https://github.com/keptn/keptn
Follow us on Twitter: https://twitter.com/keptnProject

A

Hi everyone welcome uh to a new edition of our captain developer meetings. um As you might know, we are now also included in the cncf calendar. We are an official cncf sandbox project, so that also means we're following the code of contact of cncf.

A

That basically means please be nice to each other in the character community and in the whole cncf. Basically, as you might have learned also from last week, uh we are in the process of.

B

Renaming our captain community meeting.

A

To captain developer meetings, since we're.

B

Really focusing.

A

On technical parts here in this meeting, um we are still figuring out the best way to do it. So if you have any comments, please let us know we have our captain slack. We have our user group on google groups, so you can reach out to us on slack or on the user group. Also in this meeting, let us know um what do you think about and what would be the best format uh for you. uh Do you want to discuss more use cases?

A

Do you want to discuss more developer, related things like issues or help in uh building uh your integrations to captain? Just let us know um if you are speaking about captain publicly. uh Also let us know we are happy to send you. Maybe a captain t-shirt. We still have some. I think today I don't wear it. I sometimes know it's a cucumber this this time. Maybe we have someone on the call. Let me wear a captain t-shirt. Sometimes we have something. Oh johannes, disneyland.

A

But yeah, if you're talking about captain, if you're blogging about captain speaking at the meetup at the conference, just let us know that it would really help us and we're also starting um a new format, uh which we call the captain user groups and in this format we really want to invite everyone that is working with captain.

B

A

By contributing to captain extending captain or using captain, to share your story uh with the the broader captain community in, in our first edition of this format, uh we will have uh sumit joining from the company, an organization called into it, uh and he will be talking about captain quality gates uh with argo um and jenkins, actually their own distribution. They call, I think, distro and they will. He would share some lessons learned how they did it and how to integrate it captain into their bigger project. It will be most probably on december 16th.

A

You can sign up here um the yeah. That's that's! Basically everything that we can share. um That's already uh settled, and I want to just highlight and give a shout out to a couple of new captain sandbox contributions. As you might know, the captain sandbox.

B

Is the first starting point when uh developing.

A

A new extension and integration to captain um the we have three new services from the last one or two weeks. First, one is this spline service. You can find all the details here. It's basically synchronizing data from captain uh to splunk.

A

um The second one is a selenium.

B

Service um here we don't see.

A

Or if the code has not been yet contributed back to, captain it'd still be a work in progress. um It's the it's, an organization called vitro. They are working on this and uh they want to execute selenium tests uh whenever captain is triggering the test execution, so not only genital tests or video loads tests uh or litmus chaos tests.

A

But in this case it will be selenium tests and they will be contributing the service and then also we have a new service just created today, the uh it's a placeholder right now uh it's called the monaco service. I believe monaco is for monitoring as a code, I'm not yet sure, but we have christoph here. Maybe you can share a sentence or two about this new service.

C

Yeah sure thanks uh thanks jorgen yeah, so monaco indeed stands for monitoring as codes, which is basically it's an open source uh project that dynatrace has started that allows you to to do configuration as code for dynatrace yeah. So you can. You can describe your configuration in a set of uh json files as a template, and then you can create instances of that template by replacing variables and things like that. Not much unlike a terraform does and then apply that on mass to many dynatrace environments.

C

Basically, to make your configuration a bit more manageable when you're doing it at scale over multiple tenants or multiple projects, uh it's uh yeah, it's a way how we can follow into that key tops methodology, and so um we uh in our in our ace team. uh We did a hackathon this week and I took that upon me as uh as a challenge to write a monaco service for captain.

C

So the idea is that you can give it a zip file with your configuration and then as part of your captain deployment. When you deploy a new service it can, it can actually apply that configuration to a target target tenant. uh I'm still finishing up on the uh uh on the documentation, and once I once I do that, I will upload it to the uh to the sandbox repository.

A

Pretty cool thanks for for sharing and thanks for contributing to captain, uh I think that's so. The the main idea is to basically allow scaling, since you automate the the configuration part of the tenants right.

C

Yes, exactly yeah you can you can automate that piece, and so you can actually create some consistency. If you have multiple captain projects, for example right, you can actually create some sort of baseline template configuration that for each project then gets applied right.

C

So if you have a certain set of let's say management zones that you need inside a trace or dashboards or or application definitions that are using, you know certain captain placeholders for its configuration right, then you can actually automatically set that up and it's always there always synthetic tests, for example, if you need them um yeah, so so the reason why we created that is that I think you guys probably read the state of devops 2020 report and one of the key factors that came out of that was that successful teams actually provide monitoring configuration alerting as a service to their team.

C

All right. So it's just you want some uh on demand monitoring. You don't have to do anything for it. It's just part of of your cicd pipeline, for example, that you have, and then we want to do something like that with captain as well.

A

Pretty cool uh yeah thanks for sharing, I'm really looking forward to test this new monitor.

D

Service- maybe just one note from my end. um What I really like on this approach is that you can then specify on project level and also maybe also on on stage level, how your monitoring configuration should look like, because right now, at the time address service and also the the promesa service, they were gonna kept an installation scope and it yeah.

D

There is not that much flexibility to also uh customize it for for projects or stages, but with your approach, that's pretty cool, because um there is definitely the need that for certain projects you maybe want to do something different, and this gives you then the flexibility.

C

Yeah yeah, it's it supports the same kind of methodology that you have for the dynares service, where you can specify a dynatrace.com.yaml file with all the with the tenants, oh with the credentials that uh that contains your tenant's token and and environment url. uh I support the same thing right, so you can actually say hey. I want to uh point it to this tenant or to that tenant, and you can do that on the uh like.

C

You said on the project and on the stage level, because in a lot of environments that we see at our customers, we noticed that they have separated production and non-production tenants. So here we support that quite easily.

A

Cool um christoph I'm also inviting you already to one of our next user groups uh to maybe present this. uh I think it will be really helpful for the broader captain community, especially those that are also um having uh dynatrace in place to to see what this integration can do, and uh so I, I think, that's really useful.

A

Okay, sure that would be cool thanks right.

A

Are there any questions on like the first part of the announcements and also the new contributions.

D

Well uh yet the first point I think it's worth to get it mentioned it's the problem that currently the code base of captain on the master branch cannot be built because the driver ci does not allow us to do this because we consume too much credits in the last month and if you're wondering why you don't get the latest images when you do a pull uh of of late dust, that's the pro!

D

That's the the reason um travis is currently not working for us, and but we are of course, are looking for a solution to get it done.

D

All right yeah, that was it from my end,.

A

Okay, yeah thanks johannes um okay, so with this uh I'm handing over um to airmen to and we will go through, the list of noteworthy issues appears so please give away.

E

Yeah, thank you very much. I'm going to present a poor request today from an environment. I'm usually not used to it's some go code in the cli and you already existing feature that was now re-edit.

E

It's the version check in the root command and um yeah. Let's have a look at the issue here. The problem was that if the cli did not require a connection to the cluster- and there was not- a connection could not be established. um For example, even if you executed captain minus minus help, so just the help comment. uh It was stuck there and therefore this version check was yeah removed and um yeah. Now we have improved this one and also added some new functionality.

E

So the new uh implementation now only executes um for comments, um or let's say, if that you, you execute the help command. It's not executed. uh Only if you uh yeah run um other captain comments, and it is uh now also limited with.

E

It caches the results for 24 hours and will only do the check once a day, and there is also a timeout configured now. So I think after um two or three minutes it will timeout and uh one more uh feature added here is that there is now a comparison between cli and cluster version. So if they they mismatch, uh you get a warning that your cli version and the cluster version do not match and that this can lead to problems and to make sure to yeah use the same versions here.

E

Yeah, that's all from my side. Are there any questions.

D

um Are we ready to to close this issue or to to approve it.

E

Yeah I'm waiting for approval here since yeah. There was some discussion here because yeah first, I just checked for the help for help yeah inside the comment, but this could also trigger for service helper. So now I changed this and actually just waiting for um a review here. Okay, yeah.

E

Yeah, that's all from my side, then I'm heading over to florian.

D

I mean before you jump back, uh you have two bug fixes. uh Oh.

E

You've worked on.

D

Two bug fixes: do you wanna, uh say a wood.

E

Yeah we can mention those two uh also, so uh I fixed the problem in the bridge, um so we added this feature in zero: seven, one that uh if there is a new captain version, we notified a user also in captain bridge about this new version and uh yeah. This was not migrated to the master branch correctly, so in the latest release zero, seven three: this is a known issue and this was now fixed for uh our current master.

E

um uh So for the latest version of the bridge um yeah. Now we are showing this information again as a notification on top of the bridge. So when there is a new version available- and uh we had one more issue here in the bridge since the bridge is loading only um 20 root events uh on on load.

E

So when you initially load the bridge and if those 20 route, events in a service or, for example, all 20 problem events, uh the last configuration change and actually the last deployment finished event was lost and the bridge was previously yeah fetching those events and uh checking for this config deployment finished event to provide the information um which service is deployed on a stage and now the bridge is using the get service, get services, end point and also polling for the services every 30 seconds, and here we have the deployed image which is stored in a in the mongodb data store, mongodb data store and yeah.

E

We now use this information to display the currently deployed uh image of the service in the environment screen.

E

Okay, so yeah that's from my side and next is florian all right. Thanks.

F

Okay uh in this meeting, I want to show you one pull request, uh so uh this is about again updating all the captain contrib services in order to use the new cloud events 1.0 that we're going to be using in captain zero, eight and this time I've updated the argo service. So basically, the procedure was similar to all the other cap and contribute services.

F

So mainly what needed to be done was to update to the latest version of the go utils and then use the helper functions provided within that library that basically uses cloud events 1.0 and also in addition to that, I upgraded the used go version for this service, as you can see here here in the travis yaml and in the docker file. So now we're also up to date in that area and yeah.

F

Basically, here what I did is uh yeah upgraded all the dependencies to the guru, utils and also what I've done in addition is since we are using the started and triggered and finished events in order to uh control workflows within captain 0 8. I also added the functionality of sending started and finished events from this service. So hopefully, this is now ready to be used within 0.8 and take over release actions, for example with argo all right. So that was the one for request.

F

I wanted to show you now: let's have a quick look at the working items, because there were also some bugs that were fixed, so the first one is here, so this was storing the credentials does not work with linux and openshift combination.

F

So basically, in the recent weeks we have uh gotten a contribution that supports using multiple contexts, so multiple human ethics kubernetes context and switching between those with the captain, cli and yeah in case one is using openshift.

F

The name of the current context contains slashes in its name and therefore, when the cli tried to create a file with the name of the current context, that name was, of course interpreted as a directory and therefore the cli wasn't able to create that, because we didn't plan for that scenario, and that has been fixed with that for request. So basically the the helper function that returns the name of the context now replaces all the slashes, and uh now it it's ensured.

F

That uh name is not doesn't represent a directory of any sort, but it's just a plain file all right, and I think there was another one I think.

D

I already moved it uh to the to the column on the right. I think I'm sorry for that. Yeah.

F

No problem that was the one I was looking for, so basically that one caused the our our travis builds to stall when installing captain on, for example, mini shift or mini cube, or it's at any platform, because.

F

Also, due to the feature we've added of supporting the management of multiple contexts when the captain auth command was executed for the first time, this is uh was detected as a change of the current kubernetes context, because initially it is empty and due to that change, the cli uh asked the user to confirm whether he or she will wants to continue with that context.

F

So it was waiting for confirmation by the user and of course we do not have that in the travis pipelines, and here I've added the fix that if the context is empty, so the context the captaincli is currently pointing to then this uh change will now be accepted automatically and also in case. You do want to switch contexts, for example during some sort of automation within a script. You can now use the minus y flag in order to overwrite or to automatically accept this switch of the context.

F

So this minus y flag has been added to the odd command all right, and I think that's it from me for this week. I think all the other pro requests are under review, so hopefully they will be presented during the next development meeting. All right and now I will hand over to johannes all right.

D

Well, um last week I could not join the meeting, and this week I was not actually working that much on issues and on backlog issues. More other captain related things, but still uh what I'm have open is my pr that explained that explain. That explains the requirements for the execution plane services me. I can kindly ask someone to give me a review on that.

D

Because what I'm explaining there, um the requirements for writing a custom service and with the changes that are coming with captain auto date, we have also the support for allowing a captain service to run outside the control plane, meaning that he has to call the control plane for open tasks.

D

And this is explained here in this pull request.

D

We already did a jointly review on this pull request a couple meetings ago, but I still I want to get it merged and and need a final approval is someone up for doing that.

F

Yeah, I can have a look at that.

D

Thank you very much, florian thanks a lot all right, yeah, then. The second issue I'm working on is the the spec for the captain guard events, the new format, but this one is still a work in progress as I want to test it out with the latest master branch to check whether the implementation aligns with the specification all right yeah. This was it from my side.

D

Then, let's jump over to the working items. Let me quickly remove the filter.

D

Yeah, we discussed almost all ready for reviews, except of that one from burnt um burnt. Since you are on the call. Do you want to tell us what you did with the with this issue?.

B

Yes, I can um say a couple of words about this. um Maybe I'll share my screen yep. Let me stop.

B

B

B

As johannes already mentioned, we currently have some troubles using travis ci, meaning that we are not able to actually build our stuff using travis.

A

Can you zoom in a bit.

B

Better yeah, that's better! Thank you good, um so um we thought it might be a good idea to slowly migrate, some of our tasks of of our automation, tasks from travis to github actions.

B

One step here was to think about: can we actually actually run the unit tests for the go for the whole go code, as well as the node.js angular code for from the bridge on github actions, and this was done in the last week and I can quickly show you what I've done so the definition of done was here that the unit tests actually are removed from the from the travis c I yammer file so that they are not executed in the travis context anymore, but at the github actions level and, of course, implementing the github action and also putting in place some branch protection rules which are leveraging this github actions.

B

If we just maybe.

B

Go to the let's just take a look at.

B

The main repository of captain uh here we see the actions tab and we have here all the github action we currently have and there's new one called unit tests, and this one is triggered whenever a pull request was opened.

B

Let's take, for example, a look here this one, this execution, and here we see it, has basically two jobs. The first job is unit test go and the second job is unit test node.

B

I think we are also able to see the.

B

The actual file workflow file here, as you can see the first job, simply goes into every directory of all our go projects and executes the unit tests uh in coverage mode so that we also have test coverage for all of these and the second one just executes the node.js tests.

B

One different difference to the workflow it was before, and travis is that actually now we are even saving more minutes by executing those two jobs in parallel. So if you make a pooper request, you will notice that the tests for the unit test for go and the unit tests for node are running a barrier, saving saving already some five or six minutes of build time, which is always good, um and you can see here uh each of the project in the each of the gopro check this year, a separate state step.

B

Actually, so, if one unit test of one project fails, you can easily see which one uh which which go project uh orgo module, has a problem, and if you open it here, you can yeah take a look at the tests.

B

Yeah. I think, there's not much more to say about the this topic. We will see what will be that. Probably the next thing we will shift to github action. uh Not everything will probably shift to github action. Some things will remain in driver's ci, but there are definitely still some parts. We will shift to github actions.

D

Cool great, this gives us at least a confidence that we are building code that does not break the tests. Awesome.

B

And while I'm already sharing, I have, I think another.

B

What is this updating yeah there was. There was a bug report that it was not possible using captain to update an already existing git upstream, uh so it has the captain update command and there you can pass the coordinates to a github repository, and previously it was the case that, uh if you let's open this, if you have your project already configured to use a git upstream, and you want to change it by issuing again the update command, then it was failing, and with this pull request, this is now fixed.

B

It was not so much to do.

B

Basically, you can now apply the captain update command multiple times with different git up streams, and it will just reconfigure the the project and you can so to say, switch or migrate. Your project to another github stream.

D

Are you missing an approval there.

B

um Yes, since we have changed to minimum two approvers are missing one, and then we can average. This.

D

I can take care of of reviewing the code for you. Okay,.

B

Good, I think that was it for my saturn stop share.

D

Okay, then, let's continue taking a look at the working items. um Ready for review is done in progress and assigning committed, we will skip, and then we will jump over to those that are in the backlog for the next week. Let's just have a look at this issue. This is kind of the issue that keeps track of our migration process, for the captain, contributing captain, dynadress and and captain sandbox services, and here we can see that the dynadress service has been successfully migrated to be 0.8 compliant.

D

The unleashed service is done. The promesa service is done.

D

And a couple of others are missing, but really really great progress thanks a lot for for this task.

D

Great all right, yeah, those that are still mentioned here in this issue and and um ready to to be implemented, are here that one it's about updating the service to use cloud events 1.0 for the notification service. This one is written in a typescript um yeah. When someone likes to write type 3 code, then please feel free to to work on that one and, I think, all the others they are currently in progress or already assigned what is pretty cool.

D

All right, then yeah. Let's jump to the issues that are in the backlog and are waiting for for getting um done and getting implemented. The first one is about documentation of the new shipyard version are.

E

You on a different screen, johannes or sorry,.

D

Because we see that backlog.

E

D

E

Was not talking.

D

Sorry I was not talking uh with the wrong screen because what I did, but you couldn't.

E

See your code: now we see the visual studio code. Now. Sorry, then,.

E

D

Now you can see it perfect that.

E

D

What it did was, um I just went through this list and um yeah those that has been migrated. I I marked this as resolved.

D

Okay, yeah: let's continue here on my on the other screen, then let's go on. uh The first issue I want to discuss and want to bring up is about quality, about making kept no.8, also able to execute the quality gates use case, since there are minor issues, um still not working and need to be addressed.

D

First of all, the cli will not um work with an evaluation.finished event, but will work with an evaluation.finished event, but right now it's implemented in the way.

D

That's listening for an evaluation, minus danny went this needs to be changed, and we also need to mark this captain get event evaluation done as deprecated as will not be the way of fetching events from captain with autodate and with this issue we also need to update the integration test, as well as the docs section for for all those references that are made to a captain get event command, because this has then be changed.

D

Is someone up for working on on this issue.

B

I can take this one.

D

All right thanks a lot.

D

D

Okay, then, the next one is about the remediation service, because, right now the remediation service does not include the triggered id into the payload of a remediation.triggered event, which is technically not needed, but in order to be aligned with the new spec, we want to have it in there and what's now, the task to do it's? Basically, just adding the trigger id to the metadata of our remediation dot status changed as well as I do as well as remediation.finished.

D

As we already introduced in this spec change,.

D

The code that need to be touched is in the remediation service and this gentleman has to handle the events, probably.

D

Who wants to work on that one? I.

F

D

All right, thanks, flo.

D

Okay, then, let's move on yeah about this issue started to talk about, but you could could not see my screen. It's about updating the documentation for the new shipyard, as we have now changed a lot on the master branch and also implemented the new shipyard format. We need to reflect it on the documentation as well and by getting started on that. The first task is to change all the shipyard files that are referenced and used in the documentation to the new format.

D

Here I did a quick search on that and I identified two spots where we need to update the shipyard. It's the continuous delivery multi-stage multi-stage page and then here on the manage project to create a project there. Obviously the ship, it is needed and needs to be updated.

D

D

And um we also want to add a new page with this um issue, a page that explains how to update the new shipyard, because with captnota date, you have the flexibility to add an additional step, or we call it task to a sequence.

D

You can also remove it and how this can be done should be explained by an additional page, as this will also be a key feature with the new release.

D

Is someone up for writing documentation about the new.

D

D

All right, otherwise, I would leave it here in the backlog for now, then, the next one is also a documentation issue which is more about the architecture of captain itself, because it also has changed in the way that a couple of components disappeared and the shipyard pro controller came alive and right now, this architectural diagram shows how the architecture looks like in capped node.7 with a couple of old components, and, as I said, for example, the event broker service has gone and instead of that, the shipyard service came alive, and this also needs to be changed here in this diagram and next to updating the architecture.

D

There also needs to be, or we want to provide information about the cluster size.

D

I already started working on this issue, it's kind of almost done, meaning that it's more about reviewing this pr for the second task of this issue and to give me feedback on that one, but still for the architecture.

D

I would like to ask someone to to update this.

F

One yeah I can draw the architecture.

D

Cool. Thank you very.

D

D

And I will also add myself, as I will take care of the second part, which is about the cluster size.

D

Okay, then, last but not least, but I think this is the last issue in regard to the documentation.

D

This is kind of a of a double check, because, with the upgrade of the cloud events from version 0.2 to 1.0, we also need to double check that the examples that we use in the docs are updated.

D

I think- and I hope that this is a find and research replace uh task where you just look for a specification, auto 2 and replace it by 0.1.

D

This is the first task and additionally, we also need to double check the links to the cloud event specification, as they also will change.

D

But, to be honest, I think for doing this, my pull request needs to be merged first, which is all about the specification of the cloud events, and I think, let's keep it keep it in the backlog, as working on that issue would not make sense right now. I think, let's, let's leave it where it is all right, then we have two um again or technical issues.

D

The first one is about docker hub, because christian realized that a couple of our images, old ones they get got staled by docker hub, meaning that docker will then delete them in about six months, and this is not what we want and to overcome this problem. We just need to pull them again.

D

Well, that's not that's the approach that we also want to go with this issue, meaning that we maybe once a week or every second week. We pull all those images that have a release tag on it, and maybe it would also be a good idea to check when the last pull happened and this, let's assume it happened four weeks ago, then we pull it again when it already happened this week, then it's not worth to pull it, but we need to have some automation in place that does this job for us.

D

Maybe a good candidate for for another github action. I think because we don't want to go too much with travis.

D

Anymore, someone up for working on this automation step in the next week.

D

I can take a look.

D

Okay, uh who of you once please go ahead? Okay, I think I have a second one. uh Also that goes in this direction. We all love guitar,.

C

D

Because the last one is also related to um docker images that we produce, but don't clean up on the docker hub side site because yeah it happens due to development and due to the pull requests that we make, that we create a lot of dirty images. They are here labeled with with -30.

D

They end up at docker hub and uh create a lot of tags there and what we also want to do. We kind of want to follow a clean repo, and we want to clean this up, meaning that there also need to be automation in place that takes a look or that checks out.

D

Are there images with a dirty tag on it or with just a git hash and another release tag? Then we just remove this tag from the repository, and this should also be done by a chrome job that runs every week every second week and cleans up all the images that are not forced to get stored stored over a longer period of time.

D

Okay, yeah this week we have a couple of automation, tasks um yeah, to do the problem we are currently facing with stalker hub on the one hand and travis ci. On the other hand, um someone up for working on that one.

F

Yeah, I can take that one all right, thanks, flo.

D

Okay, then yeah, I'm here at the bottom of this column, no more issues for this week, um but still, if you find some time or a good first issue, that you want to work on, feel free to just um leave a comment there on the issue, and we are happy to assign it to you, and we will then um give you more information in case. You need more information to work on it.

D

This was it from from my side, I'm back to jurgen. Do we have additional announcements for this week.

A

uh I don't think so I think we're good um I just want to. Maybe let you know that we are still working on updating our captain.sh front page. So if you are having, if you have any feedback and how you want to have it look like which information it should include, please also reach out to us.

A

I think the link was shared already in the doc. I can again paste it into the documentation. Maybe I put it in the first section here um sketch of let's say, captain sketchup, page and yeah. I will put the link in here. If you have any ideas or any feedback.

B

On this, we're happy.

A

To receive this, and, but I think, that's it for today, thanks everyone for joining uh and yeah have a great week.

D

See you next week see you later bye.