You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Operators specify an array of buildpacks for Cloud Controller to install in capi-release. Cloud Controller groups these by name and then enqueues jobs to either update existing buildpacks or install new ones. These jobs are picked up by the local workers in the order in which they get to them. Since multiple workers are handling these jobs this can cause the buildpacks to be installed in non-deterministic orders.
Context
Buildpack order matters since it affects buildpack auto-detection. Many operators assume that the order they specify for their buildpacks in their CF deployment manifest will result in them using that order for auto-detection. The fact that the installation order/position for newly installed buildpacks is non-deterministic is surprising to operators.
Steps to Reproduce
This is difficult to reproduce due to the randomness, but after multiple deploys installing a fresh set of buildpacks (not updating existing ones) you should expect to see the buildpacks installed in a different order each time.
Expected result
I would expect the buildpacks to be installed in a consistent order.
Current result
The buildpacks are usually installed in the specified order (grouped by buildpack name in cases where multiple versions of buildpacks exist for different stacks). However occasionally the buildpacks will be installed in completely different orders which can cause issues with auto-detection.
Operators can reorder the buildpacks to their liking using cf update-buildpack BUILDPACK_NAME --position <position>. This updates the position column in the data base. We could consider having our install buildpacks task specify a position based on the install_buildpacks order when installing new buildpacks instead of leaving it up to chance.
It is important that the position of existing buildpacks is not changed by any fix for this issue since an operator may have explicitly ordered them using CLI commands. It should only affect newly installed buildpacks.
The text was updated successfully, but these errors were encountered:
Issue
Operators specify an array of buildpacks for Cloud Controller to install in capi-release. Cloud Controller groups these by name and then enqueues jobs to either update existing buildpacks or install new ones. These jobs are picked up by the local workers in the order in which they get to them. Since multiple workers are handling these jobs this can cause the buildpacks to be installed in non-deterministic orders.
Context
Buildpack order matters since it affects buildpack auto-detection. Many operators assume that the order they specify for their buildpacks in their CF deployment manifest will result in them using that order for auto-detection. The fact that the installation order/position for newly installed buildpacks is non-deterministic is surprising to operators.
Steps to Reproduce
This is difficult to reproduce due to the randomness, but after multiple deploys installing a fresh set of buildpacks (not updating existing ones) you should expect to see the buildpacks installed in a different order each time.
Expected result
I would expect the buildpacks to be installed in a consistent order.
Current result
The buildpacks are usually installed in the specified order (grouped by buildpack name in cases where multiple versions of buildpacks exist for different stacks). However occasionally the buildpacks will be installed in completely different orders which can cause issues with auto-detection.
Examples from two different installations:
Possible Fix
Operators can reorder the buildpacks to their liking using
cf update-buildpack BUILDPACK_NAME --position <position>
. This updates the position column in the data base. We could consider having our install buildpacks task specify aposition
based on theinstall_buildpacks
order when installing new buildpacks instead of leaving it up to chance.Notes
The text was updated successfully, but these errors were encountered: