Free to Migrate to BPM
|
Josh Collins
Hey Y'all, You may know this already, but I wanted to send out a broad communication to make sure you're in the know and to build a shared understanding about the process for migrating to BPM going forward. As of cf-deployment v1.40.0, BPM is colocated on all instance groups in cf-d. It's available for every component team to adopt when validated against their component's features. To-date, teams that have completed validation have enabled BPM by including logic within their jobs to rely on BPM based on whether the `bpm.enabled` property is set to true for their jobs. And adding an entry to `operations/experimental/enable-bpm.yml` to set that property/value to true in the deployment manifest. The following jobs currently have entries in enable-bpm.yml:
Now that BPM is on each VM by default you can validate your components in your pipelines by enabling BPM directly within your job(s). And when ready to publish your bpm-enablement changes in a release, please...
For each team that has a component/job that's already validated against BPM, it would be great if you could enable it directly as per above and, if appropriate, submit a PR which removes the entry from `enable-bpm.yml.` At some point in the relatively near future, I'll delete `enable-bpm.yml,` but only after all components listed have enabled it and I've heard folk's pipelines no longer rely on it's existence. Thank you for reading this through and thanks very much in advance for replying with any questions, feedback, or suggestions and issues related to this communique. Cheers, Josh |
|
|
|
Krannich, Bernd
Hi Josh,
This is great news, thanks for sharing!
So essentially, cf-deployment at some point in time will run containerized processes, even on “plain VMs”, excellent.
This coincides with the mail from Cornelius (https://lists.cloudfoundry.org/g/cf-dev/message/8120) around Containerizing CF. When discussing the Containerizing proposal, our hope was always that BPM adoption would pick up so that converting into Kubernetes artifacts could benefit from the BPM metadata.
Seems like all of this is now nicely falling in place.
Thanks, Bernd
Bernd Krannich SAP Cloud Platform SAP SE Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany
Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
From: <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Hey Y'all,
You may know this already, but I wanted to send out a broad communication to make sure you're in the know and to build a shared understanding about the process for migrating to BPM going forward.
As of cf-deployment v1.40.0, BPM is colocated on all instance groups in cf-d.
It's available for every component team to adopt when validated against their component's features.
To-date, teams that have completed validation have enabled BPM by including logic within their jobs to rely on BPM based on whether the `bpm.enabled` property is set to true for their jobs. And adding an entry to `operations/experimental/enable-bpm.yml` to set that property/value to true in the deployment manifest.
The following jobs currently have entries in enable-bpm.yml:
Now that BPM is on each VM by default you can validate your components in your pipelines by enabling BPM directly within your job(s).
And when ready to publish your bpm-enablement changes in a release, please...
For each team that has a component/job that's already validated against BPM, it would be great if you could enable it directly as per above and, if appropriate, submit a PR which removes the entry from `enable-bpm.yml.`
At some point in the relatively near future, I'll delete `enable-bpm.yml,` but only after all components listed have enabled it and I've heard folk's pipelines no longer rely on it's existence.
Thank you for reading this through and thanks very much in advance for replying with any questions, feedback, or suggestions and issues related to this communique.
Cheers,
Josh
|
|
|