Update docs/FAQ.md, blog/big-bang-2-0.md, blog/dev-bigbang-mil-certificate.md,...
All threads resolved!
All threads resolved!
Compare changes
Files
6+ 21
− 22
@@ -6,58 +6,57 @@ tags:
These will be *small* breaking changes to user values. If you want to continue to deploy Twistlock for example, you will need to adjust your values to disable NeuVector and enable Twistlock before upgrading. It's also important to note that we will continue to support the alternative packages in all of these cases, we do not intend to lock users in to a single option.
These will be *small* breaking changes to user values. If you want to continue to deploy Twistlock, for example, you will need to adjust your values to disable NeuVector and enable Twistlock before upgrading. It's also important to note that we will continue to support the alternative packages in all of these cases, we do not intend to lock users in to a single option.
Within Big Bang, packages have a wide variety of naming conventions and mis-matches between different locations. Some packages may have a values key that doesn't match the namespace or `HelmRelease` name. In order to improve the user experience we are standardizing the names in these areas. Package values keys will line up with the namespace and `HelmRelease`/`GitRepository` name 1:1 with case translations to accommodate different usages (`camelCase` for Helm values, `kebab-case` for Kubernetes resources). In addition, Big Bang will provide a documented style guide with any exceptions to the guide.
Within Big Bang, packages have a wide variety of naming conventions and mis-matches between different locations. Some packages may have a values key that doesn't match the namespace or `HelmRelease` name. In order to improve the user experience, we are standardizing the names in these areas. Package values keys will line up with the namespace and `HelmRelease`/`GitRepository` name 1:1 with case translations to accommodate different usages (`camelCase` for Helm values, `kebab-case` for Kubernetes resources). In addition, Big Bang will provide a documented style guide with any exceptions to the guide.
With 2.0 we will be providing a way to deploy community/arbitrary packages as part of Big Bang, as a "first-class" experience. This will provide a way for users to effectively extend Big Bang, and still have the lifecycle of additional packages tied to the Big Bang deployment directly. Beyond this, there will also be a new `wrapper` provided that offers some features for integration of an application inside of Big Bang, strictly via Big Bang values. This includes things like configuring `VirtualService`, `ServiceMonitor`, and `NetworkPolicy` resources.
With 2.0 we will be providing a way to deploy community/arbitrary packages as part of Big Bang and as a "first-class" experience. This will provide a way for users to effectively extend Big Bang, and still have the lifecycle of additional packages tied to the Big Bang deployment directly. Beyond this, there will also be a new `wrapper` provided that offers some features for integration of an application inside of Big Bang, strictly via Big Bang values. This includes things like configuring `VirtualService`, `ServiceMonitor`, and `NetworkPolicy` resources.
As mentioned in our why section - upgrades for Big Bang are hard. A big piece of this is a lack of documentation surrounding what a Big Bang upgrade should look like, and how to complete one. In 2.0 we will be providing clear documentation around updates for both single packages and the entire stack as a whole.
As mentioned in our "Why" section, upgrades for Big Bang are hard. A big piece of this is a lack of documentation surrounding what a Big Bang upgrade should look like, and how to complete one. In 2.0, we will be providing clear documentation around updates for both single packages and the entire stack as a whole.
One of the challenges we are balancing is keeping end users up to date with the latest security patches as quick as they release, while avoiding the danger of updating 10, 20, 30+ packages in a single upgrade. Part of our approach to resolving this pain is releasing/encouraging smaller upgrades, more often. A piece of our solution for this is providing the Renovate tool as a Big Bang package, along with guidance around usage and templates for configuration. Renovate is a tool that provides automation of dependency updates. Within the context of Big Bang this would alert end users of new package releases and provide automatic changes to the user's GitOps config repo in the form of merge/pull requests.. The ultimate goal is that customers could update packages asynchronously from the Big Bang releases (smaller updates, more often).
One of the challenges we are balancing is keeping end users up to date with the latest security patches as quick as they release, while avoiding the danger of updating 10, 20, or 30+ packages in a single upgrade. Part of our approach to resolving this pain is releasing/encouraging smaller upgrades at a more frequent rate. A piece of our solution for this is providing the Renovate tool as a Big Bang package, along with providing guidance around usage and templates for configuration. Renovate is a tool that provides automation of dependency updates. Within the context of Big Bang, this would alert end users of new package releases and provide automatic changes to the user's GitOps config repo in the form of merge/pull requests. The ultimate goal is for customers to be able to update packages asynchronously from the Big Bang releases (i.e., smaller updates, more often).
This again will largely look more like a new feature - although it may have implications to the current release process/cadence. We will continue to release Big Bang versions, but again we hope for these to be smaller updates due to package updates happening differently. As a result the requirements for a major/minor/patch version will be different and will be documented in the near future.
This again will largely look more like a new feature, although it may have implications to the current release process/cadence. We will continue to release Big Bang versions, but again, we hope for these to be smaller updates due to package updates happening differently. As a result the requirements for a major/minor/patch version will be different and will be documented in the near future.
OCI `HelmRepository` will be offered as a deployment option instead of `GitRepository` in 2.0. Big Bang charts are currently being published as Helm OCI artifacts in `registry1.dso.mil/bigbang` and will be published for all Big Bang core, addon, and community packages. It is important to call out that there is no inherent extra scanning/security going into these artifacts today - this is largely just a "storage format" change for the way Flux sources the Helm charts. In the future Big Bang will be signing our OCI Helm charts and providing for verification of these signatures by end users - increasing confidence in our supply chain security. We also hope that will enable future improvements to the airgap process - all artifacts needed for Big Bang will be "OCI shaped", both the images and the Helm charts.
OCI `HelmRepository` will be offered as a deployment option instead of `GitRepository` in 2.0. Big Bang charts are currently being published as Helm OCI artifacts in `registry1.dso.mil/bigbang` and will be published for all Big Bang core, addon, and community packages. It is important to call out that there is no inherent extra scanning/security going into these artifacts today; this is largely just a "storage format" change for the way Flux sources the Helm charts. In the future, Big Bang will be signing our OCI Helm charts and providing for verification of these signatures by end users, increasing confidence in our supply chain security. We also hope this will enable future improvements to the airgap process. All artifacts needed for Big Bang will be "OCI shaped," both the images and the Helm charts.
This is a change in the underlying architecture of Big Bang, but it will be offered as an option in 2.0 to start with, and `GitRepository` will remain the default. We anticipate changing the default in the future but `GitRepository` will remain an option long-term to enable a variety of deployment needs.