-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pushing applications with cflinuxfs4 #325
Comments
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story. The labels on this github issue will be updated when the story is started. |
- The tile-generator will currently use cflinuxfs3 if it exists even if cflinuxfs4 is the default stack: cf-platform-eng/tile-generator#325 - Redefine the get_stack function to prefer cflinuxfs4 if available. - Only use cflinuxfs4 if the go_buildpack is available. Some environments will have the cflinuxfs4 stack but no go_buildpack for cflinuxfs4.
- The tile-generator will currently use cflinuxfs3 if it exists even if cflinuxfs4 is the default stack: cf-platform-eng/tile-generator#325 - Redefine the get_stack function to prefer cflinuxfs4 if available. - Only use cflinuxfs4 if the go_buildpack is available. Some environments will have the cflinuxfs4 stack but no go_buildpack for cflinuxfs4.
+1 on this (on behalf of credhub service broker tile). |
The tile generator is currently hard-coded to push applications specifying the cflinuxfs3 stack if it is available.
tile-generator/tile_generator/templates/jobs/deploy-all.sh.erb
Lines 220 to 227 in 8cbcfb2
It would be nice to be able to use cflinuxfs4 when it is available.
Prefer cflinuxfs4
One option would be to do something similar to what currently exists and use cflinuxfs4 if it is available, falling back to
cflinuxfs3. For example:
This has some potential to break tiles that don't work on cflinuxfs4, though that could be a good thing if it encourages adoption of cflinuxfs4.
It might also not work if operators were on a version of TAS 3.0 that has cflinuxfs4 but does not have a buildpack with support for cflinuxfs4 that is used when pushing the app.
https://docs.vmware.com/en/VMware-Tanzu-Application-Service/3.0/tas-for-vms/runtime-rn.html#jammy-jellyfish-stack-support-beta-17
Default stack
Another option is to use the configured default stack. This means that the operator would control the stack used, though teams that are shipping tiles may prefer to have their applications use the latest stack that is available.
With the release of TAS 4.0 operators can choose to set cflinuxfs4 as the default stack:
https://docs.vmware.com/en/VMware-Tanzu-Application-Service/4.0/tas-for-vms/runtime-rn.html
Specified by tile developers
Another option would be to allow tile developers to specify the stack that should be used at build time.
The text was updated successfully, but these errors were encountered: