Jenkins X 3.x

[jstrachan]

we are aiming for an initial version of Jenkins X 3.x based on:

• simplified setup/upgrade UX + diagram for better integration with different tools like terraform or cloud provider CLI tools like gcloud/aws
• high level design goals and principles
• how the current alpha works
• modular new CLI
• helm 3 / kustomize support

by making those capabilities available as a new jx 3.x alpha binary so that we can keep 2.x of Jenkins X stable and iterate quickly on the new 3.x alpha.

During this enhancement proposal I hope we can determine the release criteria to progress from alpha > beta > GA & how and when features make it into the release

e.g. we could also roll in these kinds of features too - but depending how things progress we may with to defer to versions after 3.0.x:

• tekton catalog support
• migration of Jenkins setups to Jenkins X

[rawlingsj]

Yeah agreed, adding a few more topics we have talked about:

• design docs and diagrams
• remove as much tech debt as possible, make things clear and easy for the developer community to grok
• separate Jenkins X from managing cloud resources, describe the criteria / requirements that approaches which create clusters must meet for a Jenkins X install to be compatible.
• clear and well documented extension points with examples
• standardise on Tekton specs and interop with Tekton features like the Tekton Catalog (this was mentioned above too)
• standardise on external secrets

[polothy]

Hey - watched the demo of JX3 and read through most of the docs in your docs PR. One major shift from static Jenkins and JX2/boot, is that JX environments are no longer isolated git repositories with their own pipelines. While, on the surface, the new design is much simpler and easier to manage, I'm worried about a couple of things:

One: if all of our teams are promoting into a single git repository, if one breaks the build, then it stops everyone else from promoting their applications, etc. Are there any mechanisms for preventing this... or maybe somehow temporarily skipping "broken" applications?

Two: we are (ab)using JX environment pipelines in order to provision application cloud infrastructure via Terraform (like dynamodb tables, etc). Putting that into a single build is very worrisome as we can run into the same problem as above with one bad egg messing up the pipeline for everyone else, or worse, the Terraform state.

Just wondering if you guys have thought through use cases like these? Maybe JX isn't the right tool to provision cloud infra and we should do something else, etc. I'm open to any sort of suggestions.

[jstrachan]

the Jenkins X v3 docs are here btw https://jenkins-x.io/docs/v3/

[jstrachan]

Hey - watched the demo of JX3 and read through most of the docs in your docs PR. One major shift from static Jenkins and JX2/boot, is that JX environments are no longer isolated git repositories with their own pipelines. While, on the surface, the new design is much simpler and easier to manage, I'm worried about a couple of things:

One: if all of our teams are promoting into a single git repository, if one breaks the build, then it stops everyone else from promoting their applications, etc. Are there any mechanisms for preventing this... or maybe somehow temporarily skipping "broken" applications?

Pull Requests on the git repository only merge when everything's green - i.e. all the kubernetes resources can be properly populated correctly for all applications. We've yet to find a way to break the build really; but everythings in git so worst case, you can revert a bad change.

Note that we're using a git repository per cluster right now; you could use separate clusters + git repositories for separate teams (at least for Staging / Production). e.g. share a development cluster across teams, but make deployments to team-specific git repositories and clusters?

Two: we are (ab)using JX environment pipelines in order to provision application cloud infrastructure via Terraform (like dynamodb tables, etc). Putting that into a single build is very worrisome as we can run into the same problem as above with one bad egg messing up the pipeline for everyone else, or worse, the Terraform state.

Just wondering if you guys have thought through use cases like these? Maybe JX isn't the right tool to provision cloud infra and we should do something else, etc. I'm open to any sort of suggestions.

Great question. We've been having lots of similar thoughts ourselves on the perfect way to blend Terraform and Jenkins X - particularly in a multi-team, multi cluster world & figuring out the split/join between Terraform and Jenkins X / k8s / helm etc.

James Rawlings did a demo in the last Office Hours on using Terraform Cloud to provision infrastructure; then using Jenkins X on top of the infrastructure. The aim is to provide the best + simplest getting started guide for teams to setup some cloud infrastructure (one or more k8s clusters and usually some cloud IAM users/roles, buckets, container registry and whatnot). Terraform Cloud is a pretty great solution for the CI/CD of Terraform itself - the core infrastructure. Then Jenkins X is installed on top of the k8s cluster that Terraform creates.

We're working towards Terraform actually performing the installation of the git operator too - then install/setup is just pure Terraform for a nice simple UX.

What we've found is:

• tools like Terraform Cloud can't handle huge amounts of PRs/merges for every single version change of every repo/app/microservice. It's really designed for more stable infrastructure that doesn't change that rapidly. So we recommend a separate git repository for clusters + infrastructure to the git repository developers use to define the repositories to enable CI/CD on and to do kubernetes level promotions etc
• we need to be very careful defining the contract between Terraform and the rest of kubernetes (jx / helm etc) - particularly; if Terraform creates a resource (e.g. a namespace, a ConfigMap, a Secret) - then that should be read only for the rest of the kubernetes ecosystem (microservices / jx / pipelines etc). Things get wacky when, say, Jenkins X installs charts into a Terraform created namespace when performing an upgrade of infrastructure etc.

[jenkins-x-bot]

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

[jenkins-x-bot]

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

[jenkins-x-bot]

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]

@jenkins-x-bot: Closing this issue.

In response to [this](https://github.com/jenkins-x/enhancements/issues/36#issuecomment-775063542): >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 Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [jenkins-x/lighthouse](https://github.com/jenkins-x/lighthouse/issues/new?title=Command%20issue:) repository.