Date   

Bi-weekly Round-Up: Technical + Ecosystem Updates from Cloud Foundry 5.18.21

Chris Clark
 

Reminder: Cloud Foundry Summit CFP closes this Friday, May 21. In some previous cycles we have extended this date, but we won’t be doing so this time - so get those proposals in!

 From the Last Few Weeks

 

Notable Releases

Dates To Remember (times U.S. Pacific)

  • May CAB call - May 19 at 8 am
  • CF Technical Governance meeting - May 21 at 8 am
  • CF Summit CFP closes - May 21 at 11:59 pm 
  • Bi-weekly Runtime PMC meeting - May 25 at 10:30 am
  • CF Technical Governance meeting - May 28 at 8 am
  • CF Summit - July 21-22

Check the community calendar for updates and meeting details.

Ecosystem and General News:


--
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


#cf New live stream: CF Summit 2021 Co-chairs panel #cf

Ram Iyengar
 

Hey everyone!
Today we're going to be hosting a panel of wonderful technologists on a live stream - our co-chairs for the Cloud Foundry Summit 2021.

They're going to be discussing the upcoming Cloud Foundry Summit 2021, and in particular providing some interesting insights about what they expect to find in CFPs, technical depth, topics of interest, and much more. To quote Chip Childers –"This pre-summit event is about two things: inspiration and guidance".

CFP last date: 21 May 2021
Event date: 21+22 July 2021

To watch the stream, please visit https://www.cloudfoundry.org/event/cf-summit-2021-special-panel/

Cheers,
Ram Iyengar
Developer Advocate, Cloud Foundry Foundation


Live Stream about CF API v3 #cf

Ram Iyengar
 

Hey folks, There is going to be a live stream on 13th May 2021 about some CF internals, specifically the CF API v3. Jenna Goldstrich from VMware is going to be a special guest joining Shedrack and Ram from the CFF. Catch all the action here - https://www.cloudfoundry.org/event/capi-v3-whats-new/

Cheers,
Ram


Re: On boarding of a new CF system build pack for Rust

Daniel Mikusa <dmikusa@...>
 

+1 to everything Dr Nic said.


On May 10, 2021, at 4:45 AM, Dr Nic Williams <drnicwilliams@...> wrote:

Custom buildpacks (v2) can be installed in airgapped and enterprise CF. You convert the buildpack and it’s dependencies into a zip file and the CF admin installs it for all users to share, like you would upgrade a buildpack from the core CF team.

Paketo buildpacks (v3) — your own plus upstream — are baked into your builder Docker image, so again you have control over what buildpack you are using across all apps.

Nic

On Mon, 10 May 2021 at 6:28 pm, Borrmann, Andre via lists.cloudfoundry.org <a.borrmann=sap.com@...> wrote:

Hi Dr. Nic,

 

thanks for your reply and the links shared to the new buildpacks and the tutorial. As I’d like to use the buildpack within an enterprise context such custom buildpack would be a good starting point, but the ultimate goal would be to get it listed as part of this: https://docs.cloudfoundry.org/buildpacks/system-buildpacks.html

 

If I get you right, the CF core team/paketo team might be the right contacts to talk to about this topic to get a Rust buildpack eventually a core/system buildpack? Are you able to share some contact details to start the communication with the right audience straight away?

 

Thanks in advance.

 

BR

André

 

From: <cf-dev@...> on behalf of Dr Nic Williams <drnicwilliams@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Sunday, 9. May 2021 at 00:01
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] On boarding of a new CF system build pack for Rust

 

Skipping the question of “core buildpacks” which is a good one but I can’t answer it.

 

I can point you to two paths for authoring Buildpacks, depending on which CF your using.

 

Newer CF/kubernetes CF uses Paketo buildpacks 

https://paketo.io/ which are implementations of the Cloud Native Buildpacks project https://buildpacks.io — the latter page has a tutorial for creating a buildpack; and the former is a collection of buildpacks. If you want your Rust buildpack to be “core” one day, cargo cult the core team/paketo team’s buildpacks rather than implement yours from scratch.

 

If you’re on an older CF, and using the older buildpacks then yes you can create a Rust buildpack, but it will never be included in “core” — the core team/paketo team is solely working on the new set of buildpakcs above. I wrote some tutorials for creating the older buildpacks; but I hesitate to recommend them since they are “the old way” :)

 

Dr Nic

--

Dr Nic Williams

+61 437 276 076

twitter @drnic



--
Dr Nic Williams
+61 437 276 076
twitter @drnic


Re: Call for Nominations: Cloud Foundry Foundation Technical Oversight Committee Election

Chip Childers <cchilders@...>
 

Of course there's a type in one of the embedded links... <facepalm>.


@Eric Malm was kind enough to point out that "voders" is not a thing.

Chip Childers
Executive Director
Cloud Foundry Foundation


On Tue, May 11, 2021 at 1:53 PM Chip Childers <cchilders@...> wrote:

Call for Nominations: Cloud Foundry Foundation Technical Oversight Committee Election


(TL;DR - we are holding an election to create a TOC… members of the CFF technical community need to take a couple of actions. Check the “TODO” list at the bottom of this post.)


Overview:


As many members of the community are aware, a working group has been meeting regularly to propose changes to our community governance structure. Last week, the first major milestone in this work was reached when the Foundation’s Governing Board (GB) voted in favor of establishing a Technical Oversight Committee (TOC) to take the place of the PMC Council.


With that change now approved, we are kicking off the first TOC election cycle today.


This is the first step of what I expect to be a fairly complex realignment of how our technical community works day to day. There are many decisions still left to be made, but I am confident that a democratic election of the TOC will bring together community leaders that will be responsive and thoughtful when making these choices.


Why Change?


The Cloud Foundry Foundation was created after a long and difficult negotiation process amongst the founding member organizations. Many, many things have changed in our ecosystem in the (over) six years since that negotiation took place, but our community’s approach to decision making has stayed roughly the same. 


When I took on the role as Executive Director in early 2020, my primary goal was to help the Foundation’s membership and the project’s community restructure how everyone works together. At the end of 2020, the Foundation completed a set of changes to the corporate structure that supports the technical community’s efforts. Today, we are taking a major step on the community side.


The community members that have been participating in this process have grounded their thinking on three key guiding principles: Transparency, Clarity and Inclusivity. Every change proposed is tied back to those principles, and every change going forward should do the same. I encourage everyone to take a moment to read more about what we mean by these principles.


Put simply, it is time to make participation in the project easier for everyone.


What’s this TOC Thing?


A Technical Oversight Committee will take the place of the PMC Council, but that is where the similarity ends. The CFF TOC will be a democratically elected group of community members that represent you, the community.


The TOC is responsible for the oversight, direction, and delivery of technical aspects of the Cloud Foundry projects and working groups. Most importantly, the role of the TOC should be to enable the community to do good work in an open and transparent way, while helping to maintain the integrity of the project used by so many organizations around the world.


The first TOC election will be structured to elect five TOC members. Using the results of the election, the two nominees with the highest number of votes will have two year terms. The next three nominees, by number of votes, will have an initial term of one year.


The second TOC election will be held a year after the initial election. During that second election cycle, the three TOC members with initial one year terms will be at the end of their initial terms. Those TOC seats will be up for election during that second TOC election. An election will be held every year after that, with either two or three TOC seats being up for election each cycle.


The work of the TOC should become easier over time, but this first TOC will be asked to continue the hard work transforming how technical collaboration happens.


Who Gets To Participate?


TOC Eligibility:


The rules for eligibility to be a member of the TOC include specific community roles, which don’t exist yet. As such, eligibility to be nominated for the TOC during the first election will be:


Community members who are currently PMC Leads, Project Leads or committers within any PMC or project. Each member organization of the CFF can also nominate one additional person not meeting these criteria as a candidate for the first TOC election.


Eligible Voters:


If you are a member of the Cloud Foundry technical community, you have a role to play here. Any individual who has contributed to CFF projects or technical working groups in the twelve months prior to the election is eligible to vote in the TOC election.


Contributions include, but are not limited to, opening PRs, reviewing and commenting on PRs, opening and commenting on issues, writing design docs, commenting on design docs, participating in mailing list discussions and participating in working groups.


Timeline:


  • May 11 - Announcement of Election and Call for Nominations

  • May 11 through May 28 - Candidate nomination period

  • June 1 - Election Begins via email ballots

  • June 15 - Election Closes

  • June 17 - Results Announced


TODO (What you need to do):


  1. Check the voter list: Each election cycle, we will use automated reporting to try to gather a list of eligible voters. The reporting will be imperfect, given the definition of eligibility being so broad. If you want to vote, or if you want to nominate someone for the TOC, please check for your name in the list. If you are not on the list, just submit an issue using this template. The deadline is May 28th to be added to the voter list.


  1. Nominate TOC candidates: Every eligible voter can nominate candidates for the TOC, and we encourage you to do so. If you are eligible to serve on the TOC, you can self nominate! If you want to nominate someone else, do so as well! You can nominate someone for the TOC by submitting an issue using this template. The deadline is May 28th to be nominated (and for the nominee to indicate acceptance).


More information on the election process can be found in the 2021 TOC election guide.


Final Thoughts:


This will be our first time running this process as a community, so please bear with us if there are any hiccups or issues. The CFF staff will be here to make the process as smooth as possible, and will err on the side of “get it right” vs. “get it done on schedule”. I also expect that we will change the operational processes we use to support the election after this first cycle. As we always share with Cloud Foundry end users, plan to iterate. :)


I know that I speak for everyone that has been involved in the technical governance process over the last several months when I say that this should be an exciting time for the community. We have come very far over the years, but have so much further to go.


Feel free to reach out directly to me if you have any questions, concerns or issues.


Thanks!



Chip Childers
Executive Director
Cloud Foundry Foundation


Call for Nominations: Cloud Foundry Foundation Technical Oversight Committee Election

Chip Childers <cchilders@...>
 

Call for Nominations: Cloud Foundry Foundation Technical Oversight Committee Election


(TL;DR - we are holding an election to create a TOC… members of the CFF technical community need to take a couple of actions. Check the “TODO” list at the bottom of this post.)


Overview:


As many members of the community are aware, a working group has been meeting regularly to propose changes to our community governance structure. Last week, the first major milestone in this work was reached when the Foundation’s Governing Board (GB) voted in favor of establishing a Technical Oversight Committee (TOC) to take the place of the PMC Council.


With that change now approved, we are kicking off the first TOC election cycle today.


This is the first step of what I expect to be a fairly complex realignment of how our technical community works day to day. There are many decisions still left to be made, but I am confident that a democratic election of the TOC will bring together community leaders that will be responsive and thoughtful when making these choices.


Why Change?


The Cloud Foundry Foundation was created after a long and difficult negotiation process amongst the founding member organizations. Many, many things have changed in our ecosystem in the (over) six years since that negotiation took place, but our community’s approach to decision making has stayed roughly the same. 


When I took on the role as Executive Director in early 2020, my primary goal was to help the Foundation’s membership and the project’s community restructure how everyone works together. At the end of 2020, the Foundation completed a set of changes to the corporate structure that supports the technical community’s efforts. Today, we are taking a major step on the community side.


The community members that have been participating in this process have grounded their thinking on three key guiding principles: Transparency, Clarity and Inclusivity. Every change proposed is tied back to those principles, and every change going forward should do the same. I encourage everyone to take a moment to read more about what we mean by these principles.


Put simply, it is time to make participation in the project easier for everyone.


What’s this TOC Thing?


A Technical Oversight Committee will take the place of the PMC Council, but that is where the similarity ends. The CFF TOC will be a democratically elected group of community members that represent you, the community.


The TOC is responsible for the oversight, direction, and delivery of technical aspects of the Cloud Foundry projects and working groups. Most importantly, the role of the TOC should be to enable the community to do good work in an open and transparent way, while helping to maintain the integrity of the project used by so many organizations around the world.


The first TOC election will be structured to elect five TOC members. Using the results of the election, the two nominees with the highest number of votes will have two year terms. The next three nominees, by number of votes, will have an initial term of one year.


The second TOC election will be held a year after the initial election. During that second election cycle, the three TOC members with initial one year terms will be at the end of their initial terms. Those TOC seats will be up for election during that second TOC election. An election will be held every year after that, with either two or three TOC seats being up for election each cycle.


The work of the TOC should become easier over time, but this first TOC will be asked to continue the hard work transforming how technical collaboration happens.


Who Gets To Participate?


TOC Eligibility:


The rules for eligibility to be a member of the TOC include specific community roles, which don’t exist yet. As such, eligibility to be nominated for the TOC during the first election will be:


Community members who are currently PMC Leads, Project Leads or committers within any PMC or project. Each member organization of the CFF can also nominate one additional person not meeting these criteria as a candidate for the first TOC election.


Eligible Voters:


If you are a member of the Cloud Foundry technical community, you have a role to play here. Any individual who has contributed to CFF projects or technical working groups in the twelve months prior to the election is eligible to vote in the TOC election.


Contributions include, but are not limited to, opening PRs, reviewing and commenting on PRs, opening and commenting on issues, writing design docs, commenting on design docs, participating in mailing list discussions and participating in working groups.


Timeline:


  • May 11 - Announcement of Election and Call for Nominations

  • May 11 through May 28 - Candidate nomination period

  • June 1 - Election Begins via email ballots

  • June 15 - Election Closes

  • June 17 - Results Announced


TODO (What you need to do):


  1. Check the voter list: Each election cycle, we will use automated reporting to try to gather a list of eligible voters. The reporting will be imperfect, given the definition of eligibility being so broad. If you want to vote, or if you want to nominate someone for the TOC, please check for your name in the list. If you are not on the list, just submit an issue using this template. The deadline is May 28th to be added to the voter list.


  1. Nominate TOC candidates: Every eligible voter can nominate candidates for the TOC, and we encourage you to do so. If you are eligible to serve on the TOC, you can self nominate! If you want to nominate someone else, do so as well! You can nominate someone for the TOC by submitting an issue using this template. The deadline is May 28th to be nominated (and for the nominee to indicate acceptance).


More information on the election process can be found in the 2021 TOC election guide.


Final Thoughts:


This will be our first time running this process as a community, so please bear with us if there are any hiccups or issues. The CFF staff will be here to make the process as smooth as possible, and will err on the side of “get it right” vs. “get it done on schedule”. I also expect that we will change the operational processes we use to support the election after this first cycle. As we always share with Cloud Foundry end users, plan to iterate. :)


I know that I speak for everyone that has been involved in the technical governance process over the last several months when I say that this should be an exciting time for the community. We have come very far over the years, but have so much further to go.


Feel free to reach out directly to me if you have any questions, concerns or issues.


Thanks!



Chip Childers
Executive Director
Cloud Foundry Foundation


Re: On boarding of a new CF system build pack for Rust

Kashyap Vedurmudi
 

Hi all - My team at VMware contributes to both the v2 Cloud Foundry buildpacks as well as the Paketo Buildpacks project (v3). Just to re-iterate a couple points above and add a few others, you have a couple options here:
  1. Build a custom v2 Rust Buildpack and set add this to the system buildpack list as a CF admin (cf create-buildpack). This is likely the best short term option if you'd like to support this without integrating pack in CI and pushing with the --docker-image flag. A quick google search shows that there are a couple existing community Rust buildpacks that you can probably reference. https://github.com/ELD/rust-buildpack and https://github.com/amsantavicca/cloudfoundry-buildpack-rust. These haven't been updated in years though, so could be better to refer to the Paketo Rust buildpack to understand build/detection logic. 
  2. Use the v3 Paketo Rust buildpack, the pack CLI, and cf push with the --docker-image flag. As Dan mentioned, this should work but probably isn't ideal for larger orgs. 
  3. (long term, this doesn't actually exist yet) - Use a v3 to v2 buildpack "shim". One of the things our team at VMware has been exploring is to implement a generic "shim" tool to convert v3 Paketo Buildpacks into v2 buildpacks that can be used in CF. This doesn't exist yet, but I thought I'd mention it as this would likely be the best way to support new languages in CF in the long term.
As others in the thread have mentioned, my team at VMware is focusing most of our development efforts on v3 Paketo Buildpacks and likely won't have the bandwidth to build a v2 Rust buildpack. That said, Rust is definitely growing in popularity, so I'm happy to discuss any of these options above in depth, André. Feel free to keep the discussion going here or start a thread in the #buildpacks channel on CF slack.

Thanks,
Kashyap


From: cf-dev@... <cf-dev@...> on behalf of Dr Nic Williams <drnicwilliams@...>
Sent: Monday, May 10, 2021 4:45 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] On boarding of a new CF system build pack for Rust
 
Custom buildpacks (v2) can be installed in airgapped and enterprise CF. You convert the buildpack and it’s dependencies into a zip file and the CF admin installs it for all users to share, like you would upgrade a buildpack from the core CF team.

Paketo buildpacks (v3) — your own plus upstream — are baked into your builder Docker image, so again you have control over what buildpack you are using across all apps.

Nic

On Mon, 10 May 2021 at 6:28 pm, Borrmann, Andre via lists.cloudfoundry.org <a.borrmann=sap.com@...> wrote:

Hi Dr. Nic,

 

thanks for your reply and the links shared to the new buildpacks and the tutorial. As I’d like to use the buildpack within an enterprise context such custom buildpack would be a good starting point, but the ultimate goal would be to get it listed as part of this: https://docs.cloudfoundry.org/buildpacks/system-buildpacks.html

 

If I get you right, the CF core team/paketo team might be the right contacts to talk to about this topic to get a Rust buildpack eventually a core/system buildpack? Are you able to share some contact details to start the communication with the right audience straight away?

 

Thanks in advance.

 

BR

André

 

From: <cf-dev@...> on behalf of Dr Nic Williams <drnicwilliams@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Sunday, 9. May 2021 at 00:01
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] On boarding of a new CF system build pack for Rust

 

Skipping the question of “core buildpacks” which is a good one but I can’t answer it.

 

I can point you to two paths for authoring Buildpacks, depending on which CF your using.

 

Newer CF/kubernetes CF uses Paketo buildpacks 

https://paketo.io/ which are implementations of the Cloud Native Buildpacks project https://buildpacks.io — the latter page has a tutorial for creating a buildpack; and the former is a collection of buildpacks. If you want your Rust buildpack to be “core” one day, cargo cult the core team/paketo team’s buildpacks rather than implement yours from scratch.

 

If you’re on an older CF, and using the older buildpacks then yes you can create a Rust buildpack, but it will never be included in “core” — the core team/paketo team is solely working on the new set of buildpakcs above. I wrote some tutorials for creating the older buildpacks; but I hesitate to recommend them since they are “the old way” :)

 

Dr Nic

--

Dr Nic Williams

+61 437 276 076

twitter @drnic

--
Dr Nic Williams
+61 437 276 076
twitter @drnic


Re: On boarding of a new CF system build pack for Rust

Dr Nic Williams <drnicwilliams@...>
 

Custom buildpacks (v2) can be installed in airgapped and enterprise CF. You convert the buildpack and it’s dependencies into a zip file and the CF admin installs it for all users to share, like you would upgrade a buildpack from the core CF team.

Paketo buildpacks (v3) — your own plus upstream — are baked into your builder Docker image, so again you have control over what buildpack you are using across all apps.

Nic

On Mon, 10 May 2021 at 6:28 pm, Borrmann, Andre via lists.cloudfoundry.org <a.borrmann=sap.com@...> wrote:

Hi Dr. Nic,

 

thanks for your reply and the links shared to the new buildpacks and the tutorial. As I’d like to use the buildpack within an enterprise context such custom buildpack would be a good starting point, but the ultimate goal would be to get it listed as part of this: https://docs.cloudfoundry.org/buildpacks/system-buildpacks.html

 

If I get you right, the CF core team/paketo team might be the right contacts to talk to about this topic to get a Rust buildpack eventually a core/system buildpack? Are you able to share some contact details to start the communication with the right audience straight away?

 

Thanks in advance.

 

BR

André

 

From: <cf-dev@...> on behalf of Dr Nic Williams <drnicwilliams@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Sunday, 9. May 2021 at 00:01
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] On boarding of a new CF system build pack for Rust

 

Skipping the question of “core buildpacks” which is a good one but I can’t answer it.

 

I can point you to two paths for authoring Buildpacks, depending on which CF your using.

 

Newer CF/kubernetes CF uses Paketo buildpacks 

https://paketo.io/ which are implementations of the Cloud Native Buildpacks project https://buildpacks.io — the latter page has a tutorial for creating a buildpack; and the former is a collection of buildpacks. If you want your Rust buildpack to be “core” one day, cargo cult the core team/paketo team’s buildpacks rather than implement yours from scratch.

 

If you’re on an older CF, and using the older buildpacks then yes you can create a Rust buildpack, but it will never be included in “core” — the core team/paketo team is solely working on the new set of buildpakcs above. I wrote some tutorials for creating the older buildpacks; but I hesitate to recommend them since they are “the old way” :)

 

Dr Nic

--

Dr Nic Williams

+61 437 276 076

twitter @drnic

--
Dr Nic Williams
+61 437 276 076
twitter @drnic


Re: On boarding of a new CF system build pack for Rust

Borrmann, Andre
 

Hi Dr. Nic,

 

thanks for your reply and the links shared to the new buildpacks and the tutorial. As I’d like to use the buildpack within an enterprise context such custom buildpack would be a good starting point, but the ultimate goal would be to get it listed as part of this: https://docs.cloudfoundry.org/buildpacks/system-buildpacks.html

 

If I get you right, the CF core team/paketo team might be the right contacts to talk to about this topic to get a Rust buildpack eventually a core/system buildpack? Are you able to share some contact details to start the communication with the right audience straight away?

 

Thanks in advance.

 

BR

André

 

From: <cf-dev@...> on behalf of Dr Nic Williams <drnicwilliams@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Sunday, 9. May 2021 at 00:01
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] On boarding of a new CF system build pack for Rust

 

Skipping the question of “core buildpacks” which is a good one but I can’t answer it.

 

I can point you to two paths for authoring Buildpacks, depending on which CF your using.

 

Newer CF/kubernetes CF uses Paketo buildpacks 

https://paketo.io/ which are implementations of the Cloud Native Buildpacks project https://buildpacks.io — the latter page has a tutorial for creating a buildpack; and the former is a collection of buildpacks. If you want your Rust buildpack to be “core” one day, cargo cult the core team/paketo team’s buildpacks rather than implement yours from scratch.

 

If you’re on an older CF, and using the older buildpacks then yes you can create a Rust buildpack, but it will never be included in “core” — the core team/paketo team is solely working on the new set of buildpakcs above. I wrote some tutorials for creating the older buildpacks; but I hesitate to recommend them since they are “the old way” :)

 

Dr Nic

--

Dr Nic Williams

+61 437 276 076

twitter @drnic


Re: On boarding of a new CF system build pack for Rust

Borrmann, Andre
 

Hi Dan,

 

thanks for your reply. While a custom/community buildpack is a viable option my question is more related to an enterprise context. Which means, building enterprise applications and deploy them to CF. This would require reproducible build steps and thus should not be dependent on external hosted buildpacks. So either we would require the custom buildpack to be hosted within our enterprise boundaries or – the preferred option – being part of the CF stack itself, like JAVA buildpack, GO buildpack etc. (so it should be best listed here: https://docs.cloudfoundry.org/buildpacks/system-buildpacks.html).

 

This kind of lead to the question how those buildpaks became system build packs and how could Rust become a part of this party. Where should this being requested and who would be responsible to get this “onboarding” kicked off.

 

Thanks in advance.

 

BR

André

 

From: <cf-dev@...> on behalf of Daniel Mikusa <dmikusa@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Saturday, 8. May 2021 at 08:04
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] On boarding of a new CF system build pack for Rust

 

Hi,

 

Not sure this exactly answers your question. I am also Rust fan and so a while back felt compelled to write a set of Cloud Native buildpacks (v3 buildpack) for Rust & contributed it to the Paketo community (Paketo is a CF Foundation project for implementations of the v3 cloud native buildpack spec).

 

 

I haven't tried it, but I'm pretty sure you could `pack build` images with this buildpack and `cf push -o` them onto CF. It's one extra step, but it should work. 

 

Maybe there'd be a way to retrofit it to work as a v2 CF buildpack? I think some folks were working on a wrapper a while back.

 

Dan

 



On May 6, 2021, at 12:18 PM, Borrmann, Andre via lists.cloudfoundry.org <a.borrmann=sap.com@...> wrote:

 

Hi there CF community,

 

While Rust is still kind of a young but continuously growing language it has been voted to be one of the most beloved development languages several years in a row.

I’m wondering if there are any plans to provide a Rust “system buildpack” natively integrated into Cloud Foundry. If there are no such plans yet, I’d like to understand what the key drivers would be to achieve such a thing. What are the prerequisites and what are possible contributions to drive or support the efforts around this topic.

 

Thanks in advance for any pointers to achieve the goal of having a system buildpack for Rust available on Cloud Foundry.

 

Besst Regards,

 

André Borrmann

Development Expert

Strategic Projects | New Ventures and Technologies | Technology & Innovation

SAP SE, Konrad-Zuse-Ring 10, 14469 Potsdam, Germany

 

 

Pflichtangaben/Mandatory Disclosure Statements:
http://www.sap.com/company/legal/impressum.epx

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.

 

 

 


Re: On boarding of a new CF system build pack for Rust

0atman
 

Adding this to the conversation:

I found it trivial to modify emk/heroku-buildpack-rust into alphagov/cf-buildpack-rust to work with our UK government CF deployment here at the GDS.
Others will have done it better, I am sure, but it was so easy to get it going.

Tris Oaten
Senior Dev, GDS


Re: On boarding of a new CF system build pack for Rust

Dr Nic Williams <drnicwilliams@...>
 

Skipping the question of “core buildpacks” which is a good one but I can’t answer it.

I can point you to two paths for authoring Buildpacks, depending on which CF your using.

Newer CF/kubernetes CF uses Paketo buildpacks 
https://paketo.io/ which are implementations of the Cloud Native Buildpacks project https://buildpacks.io — the latter page has a tutorial for creating a buildpack; and the former is a collection of buildpacks. If you want your Rust buildpack to be “core” one day, cargo cult the core team/paketo team’s buildpacks rather than implement yours from scratch.

If you’re on an older CF, and using the older buildpacks then yes you can create a Rust buildpack, but it will never be included in “core” — the core team/paketo team is solely working on the new set of buildpakcs above. I wrote some tutorials for creating the older buildpacks; but I hesitate to recommend them since they are “the old way” :)

Dr Nic
--
Dr Nic Williams
+61 437 276 076
twitter @drnic


Re: On boarding of a new CF system build pack for Rust

Daniel Mikusa <dmikusa@...>
 

Hi,

Not sure this exactly answers your question. I am also Rust fan and so a while back felt compelled to write a set of Cloud Native buildpacks (v3 buildpack) for Rust & contributed it to the Paketo community (Paketo is a CF Foundation project for implementations of the v3 cloud native buildpack spec).


I haven't tried it, but I'm pretty sure you could `pack build` images with this buildpack and `cf push -o` them onto CF. It's one extra step, but it should work. 

Maybe there'd be a way to retrofit it to work as a v2 CF buildpack? I think some folks were working on a wrapper a while back.

Dan


On May 6, 2021, at 12:18 PM, Borrmann, Andre via lists.cloudfoundry.org <a.borrmann=sap.com@...> wrote:

Hi there CF community,
 
While Rust is still kind of a young but continuously growing language it has been voted to be one of the most beloved development languages several years in a row.
I’m wondering if there are any plans to provide a Rust “system buildpack” natively integrated into Cloud Foundry. If there are no such plans yet, I’d like to understand what the key drivers would be to achieve such a thing. What are the prerequisites and what are possible contributions to drive or support the efforts around this topic.
 
Thanks in advance for any pointers to achieve the goal of having a system buildpack for Rust available on Cloud Foundry.
 
Besst Regards,
 
André Borrmann
Development Expert
Strategic Projects | New Ventures and Technologies | Technology & Innovation
SAP SE, Konrad-Zuse-Ring 10, 14469 Potsdam, Germany
 
 
Pflichtangaben/Mandatory Disclosure Statements:
http://www.sap.com/company/legal/impressum.epx

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.
 
 


On boarding of a new CF system build pack for Rust

Borrmann, Andre <a.borrmann@...>
 

Hi there CF community,

 

While Rust is still kind of a young but continuously growing language it has been voted to be one of the most beloved development languages several years in a row.

I’m wondering if there are any plans to provide a Rust “system buildpack” natively integrated into Cloud Foundry. If there are no such plans yet, I’d like to understand what the key drivers would be to achieve such a thing. What are the prerequisites and what are possible contributions to drive or support the efforts around this topic.

 

Thanks in advance for any pointers to achieve the goal of having a system buildpack for Rust available on Cloud Foundry.

 

Besst Regards,

 

André Borrmann

Development Expert

Strategic Projects | New Ventures and Technologies | Technology & Innovation

SAP SE, Konrad-Zuse-Ring 10, 14469 Potsdam, Germany

 

 

Pflichtangaben/Mandatory Disclosure Statements:
http://www.sap.com/company/legal/impressum.epx

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.

 

 


Re: [cf-bosh] [cf-dev] Update regarding Bionic Stemcells: Version 1.1 released for GA!

Eric Malm
 

Congratulations, Marco and everyone else who has contributed to the Bionic stemcell effort! Great to see the new line get all the way to GA!

Best,
Eric


From: cf-bosh@... <cf-bosh@...> on behalf of Daniel Jones via lists.cloudfoundry.org <daniel.jones=engineerbetter.com@...>
Sent: Friday, May 7, 2021 9:37 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Cc: cf-bosh@... <cf-bosh@...>; Paul Warren <warrenpa@...>
Subject: Re: [cf-bosh] [cf-dev] Update regarding Bionic Stemcells: Version 1.1 released for GA!
 
Congrats all. Government and enterprise users of OSS CF owe y'all a beverage!

Regards,
Daniel 'Deejay' Jones - Managing Director
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


On Fri, 7 May 2021 at 08:33, Marco Voelz via lists.cloudfoundry.org <marco.voelz=sap.com@...> wrote:

Dear Cloud Foundry community,

 

We've released Bionic 1.1 and removed the 'beta' flag on https://bosh.io/stemcells/ – this means: The Bionic stemcells are officially GA now!

 

This is a huge step for us, achieved under immense time pressure. A big thank you to everyone involved in this project: without this multi-company effort with people contributing what they can this would not have been possible and/or taken much, much longer. This community continues to amaze me and you're all excellent people!

 

What's next?

As announced earlier, Bionic is not part of the official CFF security advisories, but the team around @Paul Warren will start to prioritze the necessary work for this. Note that this "only" impacts the way how you receive notifications about new stemcells you should be applying. We already have automation in place to release new stemcells when Canonical releases an important CVE fix for Bionic! So for the time being: watch out for new stemcells on https://bosh.io/stemcells/ and make sure to bring them into production soon.

 

For all outstanding and ongoing work around the Bionic stemcells, I'd like to refer you again to https://github.com/orgs/cloudfoundry/projects/4. Raise issues if you find Bionic related problems in your Cloud Foundries, help us prioritize the outstanding work, and help us getting it done by collaborating!

 

Feedback?

Please reply to this mail on the list and/or send us a message in #bosh-bionic on Cloud Foundry slack. Don’t hesitate to DM me or send me a mail if you want to reach out privately.

 

Warm regards

Marco


Re: Update regarding Bionic Stemcells: Version 1.1 released for GA!

Daniel Jones
 

Congrats all. Government and enterprise users of OSS CF owe y'all a beverage!

Regards,
Daniel 'Deejay' Jones - Managing Director
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


On Fri, 7 May 2021 at 08:33, Marco Voelz via lists.cloudfoundry.org <marco.voelz=sap.com@...> wrote:

Dear Cloud Foundry community,

 

We've released Bionic 1.1 and removed the 'beta' flag on https://bosh.io/stemcells/ – this means: The Bionic stemcells are officially GA now!

 

This is a huge step for us, achieved under immense time pressure. A big thank you to everyone involved in this project: without this multi-company effort with people contributing what they can this would not have been possible and/or taken much, much longer. This community continues to amaze me and you're all excellent people!

 

What's next?

As announced earlier, Bionic is not part of the official CFF security advisories, but the team around @Paul Warren will start to prioritze the necessary work for this. Note that this "only" impacts the way how you receive notifications about new stemcells you should be applying. We already have automation in place to release new stemcells when Canonical releases an important CVE fix for Bionic! So for the time being: watch out for new stemcells on https://bosh.io/stemcells/ and make sure to bring them into production soon.

 

For all outstanding and ongoing work around the Bionic stemcells, I'd like to refer you again to https://github.com/orgs/cloudfoundry/projects/4. Raise issues if you find Bionic related problems in your Cloud Foundries, help us prioritize the outstanding work, and help us getting it done by collaborating!

 

Feedback?

Please reply to this mail on the list and/or send us a message in #bosh-bionic on Cloud Foundry slack. Don’t hesitate to DM me or send me a mail if you want to reach out privately.

 

Warm regards

Marco


Update regarding Bionic Stemcells: Version 1.1 released for GA!

Marco Voelz
 

Dear Cloud Foundry community,

 

We've released Bionic 1.1 and removed the 'beta' flag on https://bosh.io/stemcells/ – this means: The Bionic stemcells are officially GA now!

 

This is a huge step for us, achieved under immense time pressure. A big thank you to everyone involved in this project: without this multi-company effort with people contributing what they can this would not have been possible and/or taken much, much longer. This community continues to amaze me and you're all excellent people!

 

What's next?

As announced earlier, Bionic is not part of the official CFF security advisories, but the team around @Paul Warren will start to prioritze the necessary work for this. Note that this "only" impacts the way how you receive notifications about new stemcells you should be applying. We already have automation in place to release new stemcells when Canonical releases an important CVE fix for Bionic! So for the time being: watch out for new stemcells on https://bosh.io/stemcells/ and make sure to bring them into production soon.

 

For all outstanding and ongoing work around the Bionic stemcells, I'd like to refer you again to https://github.com/orgs/cloudfoundry/projects/4. Raise issues if you find Bionic related problems in your Cloud Foundries, help us prioritize the outstanding work, and help us getting it done by collaborating!

 

Feedback?

Please reply to this mail on the list and/or send us a message in #bosh-bionic on Cloud Foundry slack. Don’t hesitate to DM me or send me a mail if you want to reach out privately.

 

Warm regards

Marco


Re: Update regarding Bionic Stemcells: Production readiness

Chip Childers <cchilders@...>
 

Awesome to see end user testing results being reported back to the wider community here, and I hope that this inspires others to do the same... :)

Many thanks Aaron!

Chip Childers
Executive Director
Cloud Foundry Foundation


On Thu, May 6, 2021 at 2:56 PM Aaron Huber <aaron.m.huber@...> wrote:
We have fully tested the 0.28 stemcell using the vSphere CPI with the following deployments/releases and everything appears to be fully functioning:

cf-deployment
logsearch-boshrelease
logsearch-for-cloudfoundry
prometheus-boshrelease

We still need a new release of smb-volume-release to fix https://github.com/cloudfoundry/smb-volume-release/issues/16 but I've updated the notes with our temporary work-around and we'll go to production with a dev release for now.  Thanks to everyone involved for keeping the open source version of CF secure.

Aaron


Re: Update regarding Bionic Stemcells: Production readiness

Aaron Huber
 

We have fully tested the 0.28 stemcell using the vSphere CPI with the following deployments/releases and everything appears to be fully functioning:

cf-deployment
logsearch-boshrelease
logsearch-for-cloudfoundry
prometheus-boshrelease

We still need a new release of smb-volume-release to fix https://github.com/cloudfoundry/smb-volume-release/issues/16 but I've updated the notes with our temporary work-around and we'll go to production with a dev release for now.  Thanks to everyone involved for keeping the open source version of CF secure.

Aaron


Bi-weekly Round-Up: Technical + Ecosystem Updates from Cloud Foundry 5.4.21

Chris Clark
 

Hi folks! Reminder: Cloud Foundry Summit CFP closes May 21st.


From the Last Few Weeks:


Notable Releases:

  • cf-for-k8s
    • v3.1.0
      • Docs have been moved to the cf-for-k8s.io website.
      • Istio has been upgraded to an in-support version, with an additional upgrade to follow.
    • v4.0.0
      • The config block resource_validator_certificate for Eirini has been removed. It was introduced in v3.1.0 via the Eirini bump, so this is regarded as a breaking change.
      • This release supports mitigating the previously introduced interface change and preparation for an additional Istio update.
    • v4.1.0
      • Istio bump
      • Note: Istio does not support jump upgrades, so you MUST upgrade to v4.0 before upgrading to v4.1
  • BOSH v271.8.0
  • gosigar v1.2.0
  • diego-release v2.50.0
  • cf-networking-release v2.36.0
  • quarks-operator v7.2.3 and v7.2.4

Dates To Remember (All times US Pacific):

  • CF Technical Governance meeting – May 7 at 8 am
  • Bi-weekly Runtime PMC meeting – May 11 at 10:30 am
  • Office Hours: CAPI – May 12 at 9 am
  • CF Technical Governance meeting – May 14 at 8 am
  • Office Hours: Logging and Metrics – May 14 at 10:30 am
  • CF-for-K8s SIG meeting – May 18 at 8:30 am
  • May CAB call – May 19 at 8 am
  • CF Summit CFP closes – May 21 at 11:59 pm 
  • CF Summit – July 21-22

 

Check the community calendar for updates and meeting details.


Ecosystem and General News:

 


--
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation