Closed tdcox closed 3 years ago
Next Steps:
Notes: Versioning of buildpacks and quickstarts needs to be established first
Best suited for a Labs project to establish patterns
MLOps has physical dependencies on hardware Libraries changing ML frameworks changing
Rework image usage/binaries Existing versioning on quickstarts is only conceptual
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://jenkins-x.io/community.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Provide feedback via https://jenkins-x.io/community.
/close
@jenkins-x-bot: Closing this issue.
There is an intrinsic dependency relationship between quickstarts, builders and buildpacks that spans the lifecycle of any customer application code derived from them.
We should assert the following use-cases:
Customers should always be able to rebuild an application that they have previously successfully built on the platform, within an agreed time window of support that should be measured in years.
It must be possible for the Jenkins-X project to upgrade builders on a regular cadence to mitigate vulnerabilities and add new features.
It must be possible for the Jenkins-X project to upgrade buildpacks on a regular cadence to mitigate vulnerabilities and add new features.
There must be a migration path for customer codebases to upgrade to later versions of builders and buildpacks (on the basis that this may necessitate changes to their codebase).
It must be possible for the Jenkins-X project to deprecate and eventually remove instances of quickstarts, builders and buildpacks at the end of a support window.
Implications:
Drivers:
It is currently not possible to upgrade builders and buildpacks without breaking customer code. This has meant that we are not providing timely security patches to core dependencies.
It is not possible to complete the transition from Skaffold to Kaniko due to buildpack dependencies.
It is currently not possible to support the rapid pace of change to core frameworks in MLOps due to the need to be able to support multiple versions of dependencies in parallel. in production.
Constraints:
It is proposed that we discuss ways to re-architect the current solution to meet the above use cases.
See also https://github.com/jenkins-x/jx/issues/4671