Date   
Ask for CF Community Process of building light stemcell

"李冰(张嶷) <zhangyi.lb@...>
 

Dear BOSH team,


I am seeking for helps on how to get Alibaba Cloud Light Stemcell Builder and Stemcell CIs integrated with the CF community process of building light stemcells.

 

I have the following questions and sorry for asking them in one batch, so adding #number for easy tracking.

 

1)      Do we need a Cloud Foundry active project for AliCloud light stemcell builder in GitHub CF org, like this one https://github.com/cloudfoundry/bosh-aws-light-stemcell-builder? Or can we just use AliCloud light stemcell builder in Aliyun org, like this one https://github.com/aliyun/bosh-alicloud-light-stemcell-builder/tree/dev

 

2)      There is one step in Stemcell CI pipeline to upload full stemcell to an object storage bucket. In our case, we need to upload it to an AliCloud OSS bucket. The question is that who should be the owner of this OSS bucket. Is it owned by AliCloud BOSH team or CF Community? This is about how to fetch the Access Key (AK).

 

3)      After the step of light stemcell verification in Stemcell CI pipeline, if passed, it’s about to publish this light stemcell to S3 bucket then generate a meta4 file. For this S3 bucket, is it owned by CF Community?

 

4)      Once the meta4 file is generated, what is the process to update it into bosh.io/stemcells-cpi-index (https://github.com/bosh-io/stemcells-cpi-index)?

 

5)      At the end, AliCloud will make the custom image public available, however, there is a manual process sitting behind. Is it acceptable? If not, we’d better to know any best practices to automatically make a custom image public.

 

6)      Finally, how to publish light stemcell to bosh.io? Assume someone from CF community will make it happen, right?


Thanks for your time and looking forward to your feedback.


李冰(Bing LI)

电话:+86 13691202002

邮箱:zhangyi.lb@alibaba-inc.com


Two questions about BOSH CPI Certification

"李冰(张嶷) <zhangyi.lb@...>
 

Dear BOSH team.


I have another topic about BOSH CPI Certification. We aim to get Alibaba Cloud BOSH CPI passed BOSH CPI Certification (https://github.com/cloudfoundry-incubator/bosh-cpi-certification). Now we are still in development, but assume very soon we will submit a PR to include Alibaba Cloud directory into this repo, and corresponding pipeline yml file and CI tasks will be there.


Now, I have two questions regarding the integration process.

 

1)      At the beginning of certification, CI will run Terraform to build network environment. The question is about who owns the IaaS infrastructure, saying Alibaba Cloud BOSH team will own the account or CF community should own the account

 

2)      Per our understanding, a new CPI release (bosh-cpi-release) will trigger BOSH CPI Certification CI. If CI failed, what is the follow up procedures to get CPI release roll-back or be fixed?


Thank you in advance.


李冰(Bing LI)

电话:+86 13691202002

邮箱:zhangyi.lb@alibaba-inc.com


Announcement: Regular BOSH PMC meetings

Marco Voelz
 

[cross-posting lists for visibility]

 

Dear Friends of BOSH,

 

We are about to have our first BOSH PMC meeting!

 

When?

Thursday, March 21st, 8AM Pacific Time

Afterwards: Every third Thursday of the month in the same timeslot.

 

Where?

http://zoom.bosh.io

 

What is this all about?

Similarly to the existing PMC meetings, the BOSH PMC meeting is for announcements, updates, and outlook for all active projects within the BOSH PMC [1]. After a meeting, you can find the meeting minutes in pmc-notes/bosh on github [2]. If you want to see topics discussed at the meeting, we appreciate a heads-up a few days before the meeting, either via mail on cf-bosh@... or by making a pull request to the agenda document.

 

According to the Cloud Foundry Foundation's Governance documents, all companies with at least one full-time contributor on an active project get a vote to be issued by a representative. Others can join, but not vote on decisions, such as incubating new projects or promoting a project from incubation to active.

For more information on the organization within a Cloud Foundry PMC, please refer to the official Cloud Foundry Foundation Governance Documents [3].

 

Warm regards

Marco

 

[1] https://docs.google.com/a/pivotal.io/spreadsheets/d/1hg0EA3aB9wiCq8SgCU90ft4qrHvczsUjK0W_31APWxM

[2] https://github.com/cloudfoundry/pmc-notes/tree/master/Bosh

[3] https://www.cloudfoundry.org/wp-content/uploads/2015/09/CFF_Development_Governance.pdf

Re: Moving BPM out of Incubation

Marco Voelz
 

Thanks Christopher!

 

I haven't forgotten about your proposal, we're going to vote on it during our BOSH PMC meeting on March 21st. Sorry it took so long, we had to sort out some logistics around all of this.

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of Christopher Brown <cbrown@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Tuesday, 5. February 2019 at 01:26
To: "cf-bosh@..." <cf-bosh@...>
Subject: Re: [cf-bosh] Moving BPM out of Incubation

 

I work on it 1-2 days per week. BPM v1 is pretty much feature complete and I anticipate that most of the work from now on will be refinements.

At some point we'll start seriously considering what the next steps for v2 are. At that point I expect the time spent on it and the feature work to ramp back up again.

Thanks and all the best,
Christopher

Removing Support for v1 Style Manifests

Morgan Fine
 

Friends of BOSH & CF,

In the olden days of BOSH, all IaaS configuration was done in individual deployment manifests, a la "v1 manifests". This became tedious and difficult for operators to mange. 

In order to abstract IaaS configuration, and simplify the operator workflow, BOSH added support for "v2 manifests". This introduced a concept called Cloud Config in order to consolidate IaaS configuration in a single file. The new "v2 manifests" reference IaaS concepts/objects from the Cloud Config and were more reusable across infrastructures.

Support for "v2 manifests" was added over 2 years ago. We believe this has given ample time for operators and release authors to migrate and stop relying on v1 syntax. Thus, the time has come where the BOSH team would like to simplify the code base and formally remove support for "v1 manifests". 

If you have any feedback about this change, please let us know.

For reference:
v1 manifest documentation: https://bosh.io/docs/deployment-manifest/
v2 manifest documentation: https://bosh.io/docs/manifest-v2/

Best,
Morgan Fine
CF BOSH

Re: Removing Support for v1 Style Manifests

Ronak Banka
 

Great job BOSH team 👏🏻

On Tue, 19 Mar 2019 at 12:36 AM, Morgan Fine <mfine@...> wrote:
Friends of BOSH & CF,

In the olden days of BOSH, all IaaS configuration was done in individual deployment manifests, a la "v1 manifests". This became tedious and difficult for operators to mange. 

In order to abstract IaaS configuration, and simplify the operator workflow, BOSH added support for "v2 manifests". This introduced a concept called Cloud Config in order to consolidate IaaS configuration in a single file. The new "v2 manifests" reference IaaS concepts/objects from the Cloud Config and were more reusable across infrastructures.

Support for "v2 manifests" was added over 2 years ago. We believe this has given ample time for operators and release authors to migrate and stop relying on v1 syntax. Thus, the time has come where the BOSH team would like to simplify the code base and formally remove support for "v1 manifests". 

If you have any feedback about this change, please let us know.

For reference:
v1 manifest documentation: https://bosh.io/docs/deployment-manifest/
v2 manifest documentation: https://bosh.io/docs/manifest-v2/

Best,
Morgan Fine
CF BOSH

Re: Removing Support for v1 Style Manifests

Corey Innis
 

+100 ... big proponent of making v1 manifests obsolete.

Cheers,
Corey

On Mon, Mar 18, 2019 at 6:29 PM Ronak Banka <ronakbanka.cse@...> wrote:
Great job BOSH team 👏🏻

On Tue, 19 Mar 2019 at 12:36 AM, Morgan Fine <mfine@...> wrote:
Friends of BOSH & CF,

In the olden days of BOSH, all IaaS configuration was done in individual deployment manifests, a la "v1 manifests". This became tedious and difficult for operators to mange. 

In order to abstract IaaS configuration, and simplify the operator workflow, BOSH added support for "v2 manifests". This introduced a concept called Cloud Config in order to consolidate IaaS configuration in a single file. The new "v2 manifests" reference IaaS concepts/objects from the Cloud Config and were more reusable across infrastructures.

Support for "v2 manifests" was added over 2 years ago. We believe this has given ample time for operators and release authors to migrate and stop relying on v1 syntax. Thus, the time has come where the BOSH team would like to simplify the code base and formally remove support for "v1 manifests". 

If you have any feedback about this change, please let us know.

For reference:
v1 manifest documentation: https://bosh.io/docs/deployment-manifest/
v2 manifest documentation: https://bosh.io/docs/manifest-v2/

Best,
Morgan Fine
CF BOSH

Re: Removing Support for v1 Style Manifests

Stanislav German-Evtushenko
 

How to know what exactly is planned to be removed? I remember some overlaps between v1 and v2 as well as not explicitly documented features which worked.

What happens to bosh create-env manifest, will it be documented separately? As of now, it's a mix of both (v1 and v2) because it should support cloud properties.

Good time to update bosh-deployment btw.

Re: Removing Support for v1 Style Manifests

Morgan Fine
 

Hi all,

A few clarifications and questions that have come up. While the create-env flow is still using "v1 manifest" structure, that code path does not involve the BOSH director itself as create-env is done in the CLI. To that end, we are not intending to change the create-env manifest structure at this time, only the manifest structure used in `bosh deploy` commands. 

In regards to what are we intending to remove, at a high level, we are intending to remove the sections from the v1 manifest page that have migrated to v2 syntax:
  • Deployment Identification i.e. "director_uuid"
  • Networks
  • Resource Pools
  • Disk Pools
  • Compilation
  • Jobs becomes Instance Groups
Best,
Morgan

On Thu, Mar 21, 2019 at 8:10 AM Stanislav German-Evtushenko <s.germanevtushenko@...> wrote:
How to know what exactly is planned to be removed? I remember some overlaps between v1 and v2 as well as not explicitly documented features which worked.

What happens to bosh create-env manifest, will it be documented separately? As of now, it's a mix of both (v1 and v2) because it should support cloud properties.

Good time to update bosh-deployment btw.

Re: [CAUTION] Re: [cf-bosh] Moving BPM out of Incubation

Marco Voelz
 

Dear Christopher,

 

I'm happy to announce that BPM has been accepted as an active project within the BOSH PMC at yesterday's PMC meeting.

You can reach out to @Chris Clark for the logistics of moving the repository and updating the list of projects in the BOSH PMC.

 

Welcome onboard!

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Thursday, 14. March 2019 at 10:10
To: "cf-bosh@..." <cf-bosh@...>, "cbrown@..." <cbrown@...>
Subject: [CAUTION] Re: [cf-bosh] Moving BPM out of Incubation

 

Thanks Christopher!

 

I haven't forgotten about your proposal, we're going to vote on it during our BOSH PMC meeting on March 21st. Sorry it took so long, we had to sort out some logistics around all of this.

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of Christopher Brown <cbrown@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Tuesday, 5. February 2019 at 01:26
To: "cf-bosh@..." <cf-bosh@...>
Subject: Re: [cf-bosh] Moving BPM out of Incubation

 

I work on it 1-2 days per week. BPM v1 is pretty much feature complete and I anticipate that most of the work from now on will be refinements.

At some point we'll start seriously considering what the next steps for v2 are. At that point I expect the time spent on it and the feature work to ramp back up again.

Thanks and all the best,
Christopher

Re: Ask for CF Community Process of building light stemcell

Mukesh Gadiya
 

Hi Bing Li,

My name is Mukesh and I am the PM for BOSH Systems team in San Francisco which is responsible for Stemcells, DNS and CLI. We talked about this in pre-IPM meeting with team and your request looks similar to how IBM Softlayer builds stemcells. Below are some questions for Marco on the SoftLayer process that should help us figure answers for your question.

Marco, 
  1. Should the stemcell builder & metalink repository be in the cloudfoundry github organization?

  2. Should the foundation own the credentials for the artifacts?

  3. Should we include the artifacts on bosh.io/stemcells?

Since, IBM does this with Softlayer, we're curious what the answers to the above questions are for softlayer.

Thanks,
Mukesh

Re: Removing Support for v1 Style Manifests

Jeanyhwh Desulme
 

Hey Morgan -

This is unfortunately a breaking change for our implementation of Bosh. We looked at fully implementing V2 some time ago but found that there was an issue in how we wanted to use it. For example our pipelines combine both a CFT and a deployment manifest. So that when we run a deployment of a given application we are passing down physical ids of native aws resources directly into the manifest itself. The following open Github issue has some more specifics in what were looking to do and what we currently have in place today.

Ideally we would love to move but only if we can override some of the deployment configuration at deploy time. 

https://github.com/cloudfoundry/bosh/issues/2094

Regards,
Jean 
Liberty Mutual

[CFEU2019 Registration] Contributor Code

Swarna Podila
 

I love some of y'all's excitement when you asked for the Contributors' Code to register for Cloud Foundry Summit EU in The Hague (Sep 11-12).

Please use CFEU19CONT to register for the EU Summit, if you are (or were) a Cloud Foundry Contributor (code, docs, bugs -- all contributions count).  See you all there!

-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.

Cloud Foundry Operators SIG

Swarna Podila
 

Hello Everyone,
It has been recently brought up that it would be useful to have a forum for Cloud Foundry operators to come together and discuss regularly.  The folks at SAP took the lead and have scheduled a call for April 24th, 11AM CET, and repeats every fourth Wednesday of the month.  The appointment is now on the Community calendar; it has the conference bridge info so you can all add it to your own calendars.

Thank you, Gowrisankar and team, for taking lead on this.

-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.

Re: Cloud Foundry Operators SIG

Swarna Podila
 

Kicking off in a few hours is the first cf-operators sig meeting.  Don’t forget to join: at 5AM US Eastern | 11AM CET. 

Topic: Cloud Foundry Operators SIG Meeting
Time: Apr 24, 2019 2:00 AM Pacific Time (US and Canada)

Join Zoom Meeting

One tap mobile
+16699006833,,4084184280# US (San Jose)
+19292056099,,4084184280# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 929 205 6099 US (New York)
Meeting ID: 408 418 4280
Find your local number: https://zoom.us/u/ali1NKUd8


On Thu, Apr 18, 2019 at 19:08 Swarna Podila <spodila@...> wrote:
Hello Everyone,
It has been recently brought up that it would be useful to have a forum for Cloud Foundry operators to come together and discuss regularly.  The folks at SAP took the lead and have scheduled a call for April 24th, 11AM CET, and repeats every fourth Wednesday of the month.  The appointment is now on the Community calendar; it has the conference bridge info so you can all add it to your own calendars.

Thank you, Gowrisankar and team, for taking lead on this.

-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.
--
-- Swarna Podila
Senior Director, Community | Cloud Foundry Foundation
spodila@...
@skpodila

Migrating Bosh-Acceptance-Tests to v2 manifests

Charles Hansen <chansen@...>
 

Hi Bosh community,

tldr; BATs is now on v2 manifests. If you run BATs in your pipeline, please try running against the v2_manifest branch before it is merged into master and let us know if you have any feedback. Hopefully it should just work.

We are migrating BATs (https://github.com/cloudfoundry/bosh-acceptance-tests) to use v2 manifests + cloud config. Using v2 manifest to deploy on bosh has been the standard for a while, but BATs has never been updated. We hope to deprecate v1 manifests very soon and need to upgrade BATs. Much of the v1 manifest that relates to vms, networks, disks etc is now in cloud config in the v2 world.

Specifically, the BATs previously had deployment manifest templates for every IaaS. We have migrated the IaaS details into IaaS specific cloud configs instead, and all BATs will deploy a generic deployment manifest. These can all be found in https://github.com/cloudfoundry/bosh-acceptance-tests/tree/v2_manifest/templates with the `cloud-config-` prefix.

We tested vSphere, AWS, GCP, and Warden in our own pipelines, but Azure and Openstack remain untested. BATs also has an Oracle configuration which we did not touch. Additionally, BATs can be configured with a variety of different network topologies, and we only tested a few. Ideally these changes should not affect anyone, but there may be some unforeseen issues. If you are a CPI author and have feedback on these changes, please reach out to the BOSH Director team. Otherwise, these changes will be merged into master next week.

Thanks in advance for your feedback,

Charles and Belinda, BOSH Director team (SF)

Re: Migrating Bosh-Acceptance-Tests to v2 manifests

Mike Lloyd
 

Charles and Belinda,

 

Is there a reason Azure and Openstack are still untested?

 

Thanks,

 

Mike.

 

From: cf-bosh@... <cf-bosh@...> On Behalf Of via Lists.Cloudfoundry.Org
Sent: Wednesday, April 24, 2019 5:46 PM
To: cf-bosh@...
Cc: Belinda Liu <bliu@...>; Morgan Fine <mfine@...>
Subject: [cf-bosh] Migrating Bosh-Acceptance-Tests to v2 manifests

 

Hi Bosh community,

 

tldr; BATs is now on v2 manifests. If you run BATs in your pipeline, please try running against the v2_manifest branch before it is merged into master and let us know if you have any feedback. Hopefully it should just work.

 

We are migrating BATs (https://github.com/cloudfoundry/bosh-acceptance-tests) to use v2 manifests + cloud config. Using v2 manifest to deploy on bosh has been the standard for a while, but BATs has never been updated. We hope to deprecate v1 manifests very soon and need to upgrade BATs. Much of the v1 manifest that relates to vms, networks, disks etc is now in cloud config in the v2 world.

 

Specifically, the BATs previously had deployment manifest templates for every IaaS. We have migrated the IaaS details into IaaS specific cloud configs instead, and all BATs will deploy a generic deployment manifest. These can all be found in https://github.com/cloudfoundry/bosh-acceptance-tests/tree/v2_manifest/templates with the `cloud-config-` prefix.

 

We tested vSphere, AWS, GCP, and Warden in our own pipelines, but Azure and Openstack remain untested. BATs also has an Oracle configuration which we did not touch. Additionally, BATs can be configured with a variety of different network topologies, and we only tested a few. Ideally these changes should not affect anyone, but there may be some unforeseen issues. If you are a CPI author and have feedback on these changes, please reach out to the BOSH Director team. Otherwise, these changes will be merged into master next week.

 

Thanks in advance for your feedback,

 

Charles and Belinda, BOSH Director team (SF)

Re: Migrating Bosh-Acceptance-Tests to v2 manifests

Jason Stevens
 

Yes, I’m curious about that, too.  I would think we’d want to test on Azure before a merge.

-jps

Create clarity. Generate energy. Find solutions.


From: cf-bosh@... <cf-bosh@...> on behalf of Mike Lloyd via Lists.Cloudfoundry.Org <mike=reboot3times.org@...>
Sent: Thursday, April 25, 2019 7:25 AM
To: cf-bosh@...
Cc: Belinda Liu; Morgan Fine
Subject: Re: [cf-bosh] Migrating Bosh-Acceptance-Tests to v2 manifests
 

Charles and Belinda,

 

Is there a reason Azure and Openstack are still untested?

 

Thanks,

 

Mike.

 

From: cf-bosh@... <cf-bosh@...>On Behalf Of via Lists.Cloudfoundry.Org
Sent: Wednesday, April 24, 2019 5:46 PM
To: cf-bosh@...
Cc: Belinda Liu <bliu@...>; Morgan Fine <mfine@...>
Subject: [cf-bosh] Migrating Bosh-Acceptance-Tests to v2 manifests

 

Hi Bosh community,

 

tldr; BATs is now on v2 manifests. If you run BATs in your pipeline, please try running against the v2_manifest branchbefore it is merged into master and let us know if you have any feedback. Hopefully it should just work.

 

We are migrating BATs (https://github.com/cloudfoundry/bosh-acceptance-tests) to use v2 manifests + cloud config. Using v2 manifest to deploy on bosh has been the standard for a while, but BATs has never been updated. We hope to deprecate v1 manifests very soon and need to upgrade BATs. Much of the v1 manifest that relates to vms, networks, disks etc is now in cloud config in the v2 world.

 

Specifically, the BATs previously had deployment manifest templates for every IaaS. We have migrated the IaaS details into IaaS specific cloud configs instead, and all BATs will deploy a generic deployment manifest. These can all be found in https://github.com/cloudfoundry/bosh-acceptance-tests/tree/v2_manifest/templates with the `cloud-config-` prefix.

 

We tested vSphere, AWS, GCP, and Warden in our own pipelines, but Azure and Openstack remain untested. BATs also has an Oracle configuration which we did not touch. Additionally, BATs can be configured with a variety of different network topologies, and we only tested a few. Ideally these changes should not affect anyone, but there may be some unforeseen issues. If you are a CPI author and have feedback on these changes, please reach out to the BOSH Director team. Otherwise, these changes will be merged into master next week.

 

Thanks in advance for your feedback,

 

Charles and Belinda, BOSH Director team (SF)

Re: Migrating Bosh-Acceptance-Tests to v2 manifests

Belinda Liu <bliu@...>
 

Hey Jason and Mike,

Thanks for calling that out. We don't have any environments on hand to test Azure and Openstack, and have synced up with the Openstack CPI and Azure CPI team to test these changes. We don't intend to merge before we get feedback from them. 

Thanks,
Belinda

On Thu, Apr 25, 2019 at 8:06 AM Jason Stevens <Jason.Stevens@...> wrote:
Yes, I’m curious about that, too.  I would think we’d want to test on Azure before a merge.

-jps

Create clarity. Generate energy. Find solutions.

From: cf-bosh@... <cf-bosh@...> on behalf of Mike Lloyd via Lists.Cloudfoundry.Org <mike=reboot3times.org@...>
Sent: Thursday, April 25, 2019 7:25 AM
To: cf-bosh@...
Cc: Belinda Liu; Morgan Fine
Subject: Re: [cf-bosh] Migrating Bosh-Acceptance-Tests to v2 manifests
 

Charles and Belinda,

 

Is there a reason Azure and Openstack are still untested?

 

Thanks,

 

Mike.

 

From: cf-bosh@... <cf-bosh@...>On Behalf Of via Lists.Cloudfoundry.Org
Sent: Wednesday, April 24, 2019 5:46 PM
To: cf-bosh@...
Cc: Belinda Liu <bliu@...>; Morgan Fine <mfine@...>
Subject: [cf-bosh] Migrating Bosh-Acceptance-Tests to v2 manifests

 

Hi Bosh community,

 

tldr; BATs is now on v2 manifests. If you run BATs in your pipeline, please try running against the v2_manifest branchbefore it is merged into master and let us know if you have any feedback. Hopefully it should just work.

 

We are migrating BATs (https://github.com/cloudfoundry/bosh-acceptance-tests) to use v2 manifests + cloud config. Using v2 manifest to deploy on bosh has been the standard for a while, but BATs has never been updated. We hope to deprecate v1 manifests very soon and need to upgrade BATs. Much of the v1 manifest that relates to vms, networks, disks etc is now in cloud config in the v2 world.

 

Specifically, the BATs previously had deployment manifest templates for every IaaS. We have migrated the IaaS details into IaaS specific cloud configs instead, and all BATs will deploy a generic deployment manifest. These can all be found in https://github.com/cloudfoundry/bosh-acceptance-tests/tree/v2_manifest/templates with the `cloud-config-` prefix.

 

We tested vSphere, AWS, GCP, and Warden in our own pipelines, but Azure and Openstack remain untested. BATs also has an Oracle configuration which we did not touch. Additionally, BATs can be configured with a variety of different network topologies, and we only tested a few. Ideally these changes should not affect anyone, but there may be some unforeseen issues. If you are a CPI author and have feedback on these changes, please reach out to the BOSH Director team. Otherwise, these changes will be merged into master next week.

 

Thanks in advance for your feedback,

 

Charles and Belinda, BOSH Director team (SF)

Re: Migrating Bosh-Acceptance-Tests to v2 manifests

Riegger, Felix
 

Hi all,

meanwhile this has been tested against OpenStack. There were only minor changes necessary. These have been integrated into the v2_manifest branch.

Kind regards,
Felix