diff --git a/.ci-operator.yaml b/.ci-operator.yaml index a83f0f843..38718883b 100644 --- a/.ci-operator.yaml +++ b/.ci-operator.yaml @@ -1,4 +1,4 @@ build_root_image: name: release namespace: openshift - tag: rhel-9-release-golang-1.21-openshift-4.16 + tag: rhel-8-release-golang-1.21-openshift-4.16 diff --git a/README.md b/README.md index 9e1efd8ac..befc82af4 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,23 @@ # operator-controller The operator-controller is the central component of Operator Lifecycle Manager (OLM) v1. It extends Kubernetes with an API through which users can install extensions. -## Description -OLM v1 is the follow-up to OLM v0, located [here](https://github.com/operator-framework/operator-lifecycle-manager). It consists of four different components, including this one, which are as follows: + +## Mission + +OLM’s purpose is to provide APIs, controllers, and tooling that support the packaging, distribution, and lifecycling of Kubernetes extensions. It aims to align with Kubernetes designs and user assumptions, provide secure, high-quality, and predictable user experiences centered around declarative GitOps concepts, and to give cluster admins the minimal necessary controls to build their desired cluster architectures and to have ultimate control. + +## Overview + +OLM v1 is the follow-up to OLM v0, located [here](https://github.com/operator-framework/operator-lifecycle-manager). + +OLM v1 consists of four different components, including this one, which are as follows: * operator-controller * [deppy](https://github.com/operator-framework/deppy) * [rukpak](https://github.com/operator-framework/rukpak) * [catalogd](https://github.com/operator-framework/catalogd) +For a more complete overview of OLM v1 and how it differs from OLM v0, see our [overview](./docs/olmv1_overview.md). + ## Getting Started You’ll need a Kubernetes cluster to run against. You can use [KIND](https://sigs.k8s.io/kind) to get a local cluster for testing, or run against a remote cluster. **Note:** Your controller will automatically use the current context in your kubeconfig file (i.e. whatever cluster `kubectl cluster-info` shows). diff --git a/commitchecker.yaml b/commitchecker.yaml index 0a8c61306..ca5fec0f6 100644 --- a/commitchecker.yaml +++ b/commitchecker.yaml @@ -1,4 +1,4 @@ -expectedMergeBase: 92d88895f079c002766ca9faa949f9fc3954f33c +expectedMergeBase: e999ca9126b0ec2b7c43218e121e5e7776db93f3 upstreamBranch: main upstreamOrg: operator-framework upstreamRepo: operator-controller diff --git a/docs/olmv1_overview.md b/docs/olmv1_overview.md new file mode 100644 index 000000000..f2e299a78 --- /dev/null +++ b/docs/olmv1_overview.md @@ -0,0 +1,243 @@ +# OLMv1 Overview + +## What won't OLMv1 do that OLMv0 did? + +TL;DR: OLMv1 cannot feasibly support multi-tenancy or any feature that assumes multi-tenancy. All multi-tenancy features end up falling over because of the global API system of Kubernetes. While this short conclusion may be unsatisfying, the reasons are complex and intertwined. + +### Historical Context + +Nearly every active contributor in the Operator Framework project contributed to design explorations and prototypes over an entire year. For each of these design explorations, there are complex webs of features and assumptions that are necessary to understand the context that ultimately led to a conclusion of infeasibility. + +Here is a sampling of some of the ideas we explored: +- [[WIP] OLM v1's approach to multi-tenancy](https://docs.google.com/document/d/1xTu7XadmqD61imJisjnP9A6k38_fiZQ8ThvZSDYszog/edit#heading=h.m19itc78n5rw) +- [OLMv1 Multi-tenancy Brainstorming](https://docs.google.com/document/d/1ihFuJR9YS_GWW4_p3qjXu3WjvK0NIPIkt0qGixirQO8/edit#heading=h.vy9860qq1j01) + +### Watched namespaces cannot be configured in a first-class API + +OLMv1 will not have a first-class API for configuring the namespaces that a controller will watch. + +Kubernetes APIs are global. Kubernetes is designed with the assumption that a controller WILL reconcile an object no matter where it is in the cluster. + +However, Kubernetes does not assume that a controller will be successful when it reconciles an object. + +The Kubernetes design assumptions are: +- CRDs and their controllers are trusted cluster extensions. +- If an object for an API exists a controller WILL reconcile it, no matter where it is in the cluster. + +OLMv1 will make the same assumption that Kubernetes does and that users of Kubernetes APIs do. That is: If a user has RBAC to create an object in the cluster, they can expect that a controller exists that will reconcile that object. If this assumption does not hold, it will be considered a configuration issue, not an OLMv1 bug. + +This means that it is a best practice to implement and configure controllers to have cluster-wide permission to read and update the status of their primary APIs. It does not mean that a controller needs cluster-wide access to read/write secondary APIs. If a controller can update the status of its primary APIs, it can tell users when it lacks permission to act on secondary APIs. + +### Dependencies based on watched namespaces + +Since there will be no first-class support for configuration of watched namespaces, OLMv1 cannot resolve dependencies among bundles based on where controllers are watching. + +However, not all bundle constraints are based on dependencies among bundles from different packages. OLMv1 will be able to support constraints against cluster state. For example, OLMv1 could support a “kubernetesVersionRange” constraint that blocks installation of a bundle if the current kubernetes cluster version does not fall into the specified range. + +#### Background + +For packages that specify API-based dependencies, OLMv0’s dependency checker knows which controllers are watching which namespaces. While OLMv1 will have awareness of which APIs are present on a cluster (via the discovery API), it will not know which namespaces are being watched for reconciliation of those APIs. Therefore dependency resolution based solely on API availability would only work in cases where controllers are configured to watch all namespaces. + +For packages that specify package-based dependencies, OLMv0’s dependency checker again knows which controllers are watching which namespaces. This case is challenging for a variety of reasons: +1. How would a dependency resolver know which extensions were installed (let alone which extensions were watching which namespaces)? If a user is running the resolver, they would be blind to an installed extension that is watching their namespace if they don’t have permission to list extensions in the installation namespace. If a controller is running the resolver, then it might leak information to a user about installed extensions that the user is not otherwise entitled to know. +2. Even if (1) could be overcome, the lack of awareness of watched namespaces means that the resolver would have to make assumptions. If only one controller is installed, is it watching the right set of namespaces to meet the constraint? If multiple controllers are installed, are any of them watching the right set of namespaces? Without knowing the watched namespaces of the parent and child controllers, a correct dependency resolver implementation is not possible to implement. + +Note that regardless of the ability of OLMv1 to perform dependency resolution (now or in the future), OLMv1 will not automatically install a missing dependency when a user requests an operator. The primary reasoning is that OLMv1 will err on the side of predictability and cluster-administrator awareness. + +### "Watch namespace"-aware operator discoverability + +When operators add APIs to a cluster, these APIs are globally visible. As stated before, there is an assumption in this design that a controller will reconcile an object of that API anywhere it exists in the cluster. + +Therefore, the API discoverability story boils down to answering this question for the user: “What APIs do I have access to in a given namespace?” Fortunately, built-in APIs exist to answer this question: Kubernetes Discovery, SelfSubjectRulesReview (SSRR), and SelfSubjectAccessReview (SSAR). + +However, helping users discover which actual controllers will reconcile those APIs is not possible unless OLMv1 knows which namespaces those controllers are watching. + +Any solution here would be unaware of where a controller is actually watching and could only know “is there a controller installed that provides an implementation of this API?”. However even knowledge of a controller installation is not certain. Any user can use the discovery, SSRR, and SSAR. Not all users can list all Extensions (see [User discovery of “available” APIs](#user-discovery-of-available-apis)). + +## What does this mean for multi-tenancy? + +The multi-tenancy promises that OLMv0 made were false promises. Kubernetes is not multi-tenant with respect to management of APIs (because APIs are global). Any promise that OLMv0 has around multi-tenancy evaporates when true tenant isolation attempts are made, and any attempt to fix a broken promise is actually just a bandaid on an already broken assumption. + +So where do we go from here? There are multiple solutions that do not involve OLM implementing full multi-tenancy support, some or all of which can be explored. +1. Customers transition to a control plane per tenant +2. Extension authors update their operators to support customers’ multi-tenancy use cases +3. Extension authors with “simple” lifecycling concerns transition to other packaging and deployment strategies (e.g. helm charts) + +### Single-tenant control planes + +One choice for customers would be to adopt low-overhead single-tenant control planes in which every tenant can have full control over their APIs and controllers and be truly isolated (at the control plane layer at least) from other tenants. With this option, the things OLMv1 cannot do (listed above) are irrelevant, because the purpose of all of those features is to support multi-tenant control planes in OLM. + +The [Kubernetes multi-tenancy docs](https://kubernetes.io/docs/concepts/security/multi-tenancy/#virtual-control-plane-per-tenant) contain a good overview of the options in this space. Kubernetes vendors may also have their own virtual control plane implementations. + +### Shift multi-tenant responsibility to operators + +There is a set of operators that both (a) provide fully namespace-scoped workload-style operands and that (b) provide a large amount of value to their users for advanced features like backup and migration. For these operators, the Operator Framework program would suggest that they shift toward supporting multi-tenancy directly. That would involve: +1. Taking extreme care to avoid API breaking changes. +2. Supporting multiple versions of their operands in a single version of the operator (if required by users in multi-tenant clusters). +3. Maintaining support for versioned operands for the same period of time that the operator is supported for a given cluster version. +4. Completely avoiding global configuration. Each tenant should be able to provide their configuration separately. + +### Operator authors ship controllers outside of OLM + +Some projects have been successful delivering and supporting their operator on Kubernetes, but outside of OLM, for example with helm-packaged operators. On this path, individual layered project teams have more flexibility in solving lifecycling problems for their users because they are unencumbered by OLM’s opinions. However the tradeoff is that those project teams and their users take on responsibility and accountability for safe upgrades, automation, and multi-tenant architectures. With OLMv1 no longer attempting to support multi-tenancy in a first-class way, these tradeoffs change and project teams may decide that a different approach is necessary. + +This path does not necessarily mean a scattering of content in various places. It would still be possible to provide customers with a marketplace of content (e.g. see https://artifacthub.io/). + +### Authors of "simple" operators ship their workload without an operator + +Another direction is to just stop shipping content via an operator. The operator pattern is particularly well-suited for applications that require complex upgrade logic, that need to convert declarative intent to imperative action, or that require sophisticated health monitoring logic and feedback. But a sizable portion of the OperatorHub catalog contain operators that are not actually taking advantage of the benefits of the operator pattern and are instead a simple wrapper around the workload, which is where the real value is. + +Using the [Operator Capability Levels](https://sdk.operatorframework.io/docs/overview/operator-capabilities/) as a rubric, operators that fall into Level 1 and some that fall into Level 2 are not making full use of the operator pattern. If content authors had the choice to ship their content without also shipping an operator that performs simple installation and upgrades, many supporting these Level 1 and Level 2 operators might make that choice to decrease their overall maintenance and support burden while losing very little in terms of value to their customers. + +## What will OLM do that a generic package manager doesn't? + +OLM will provide multiple features that are absent in generic package managers. Some items listed below are already implemented, while others may be planned for the future. + +### Upgrade controls + +An operator author can control the upgrade flow by specifying supported upgrade paths from one version to another. Or, they could use semantic versioning (semver) - this is fully supported by OLM too. + +A user can see the author’s supplied upgrade information. + +While these features might seem standard in package managers, they are fairly unique in the Kubernetes ecosystem. Helm, for example, doesn’t have any features that help users stay on supported upgrade paths. + +### On-cluster component for automated upgrades, health monitoring + +OLM automatically upgrades an operator to the latest acceptable matching version whenever a new matching version appears in a catalog, assuming the user has enabled this for their operator. + +OLM constantly monitors the state of all on-cluster resources for all the operators it manages, reporting the health in aggregate on each operator. + +### CRD Upgrade Safety Checks + +Before OLM upgrades a CRD, OLM performs a set of safety checks to identify any changes that potentially would have negative impacts, such as: +- data loss +- incompatible schema changes + +These checks may not be a guarantee that an upgrade is safe; instead, they are intended to provide an early warning sign for identifiable incompatibilities. False positives (OLMv1 claims a breaking change when there is none) and false negatives (a breaking change makes it through the check without being caught) are possible, at least while the OLMv1 team iterates on this feature. + +### User permissions management + +Operators typically provide at least one new API, and often multiple. While operator authors know the APIs they’re providing, users installing operators won’t necessarily have this same knowledge. OLM will make it easy to grant permissions to operator-provided APIs to users/groups in various namespaces, but any automation (which would be client-side only) or UX provided by OLM related to user permissions management will be unable to automatically account for watch namespace configurations. See [Watched namespaces cannot be configured in a first class API](#watched-namespaces-cannot-be-configured-in-a-first-class-api) + +Also note that user permission management does not unlock operator discoverability (only API discoverability). See [“Watch namespace”-aware operator discoverability](#watch-namespace-aware-operator-discoverability) for more details. + +### User discovery of “available” APIs + +In the future, the Operator Framework team could explore building an API similar to SelfSubjectAccessReview and SelfSubjectRulesReview that answers the question: +“What is the public metadata of all of the extensions that are installed on the cluster that provide APIs that I have permission for in namespace X?” + +One solution would be to join “installed extensions with user permissions”. If an installed extension provides an API that a user has RBAC permission for, that extension would be considered available to that user in that scope. This solution would not be foolproof: it makes the (reasonable) assumption that an administrator only configures RBAC for a user in a namespace where a controller is reconciling that object. If an administrator gives a user RBAC access to an API without also configuring that controller to watch the namespace that they have access to, the discovery solution would report an available extension, but then nothing would actually reconcile the object they create. + +This solution would tell users about API-only and API+controller bundles that are installed. It would not tell users about controller-only bundles, because they do not include APIs. + +Other similar API-centric solutions could be explored as well. For example, pursuing enhancements to OLMv1 or core Kubernetes related to API metadata and/or grouping. + +A key note here is that controller-specific metadata like the version of the controller that will reconcile the object in a certain namespace is not necessary for discovery. Discovery is primarily about driving user flows around presenting information and example usage of a group of APIs such that CLIs and UIs can provide rich experiences around interactions with available APIs. + +## Approach + +We will adhere to the following tenets in our approach for the design and implementation of OLMv1 + +### Do not fight Kubernetes + +One of the key features of cloud-native applications/extensions/operators is that they typically come with a Kubernetes-based API (e.g. CRD) and a controller that reconciles instances of that API. In Kubernetes, API registration is cluster-scoped. It is not possible to register different APIs in different namespaces. Instances of an API can be cluster- or namespace-scoped. All APIs are global (they can be invoked/accessed regardless of namespace). For cluster-scoped APIs, the names of their instances must be unique. For example, it’s possible to have Nodes named “one” and “two”, but it’s not possible to have multiple Nodes named “two”. For namespace-scoped APIs, the names of their instances must be unique per namespace. The following illustrates this for ConfigMaps, a namespace-scoped API: + +Allowed +- Namespace: test, name: my-configmap +- Namespace: other, name: my-configmap + +Disallowed +- Namespace: test, name: my-configmap +- Namespace: test, name: my-configmap + +In cases where OLMv0 decides that joint ownership of CRDs will not impact different tenants, OLMv0 allows multiple installations of bundles that include the same named CRD, and OLMv0 itself manages the CRD lifecycle. This has security implications because it requires OLMv0 to act as a deputy, but it also pits OLM against the limitations of the Kubernetes API. OLMv0 promises that different versions of an operator can be installed in the cluster for use by different tenants without tenants being affected by each other. This is not a promise OLM can make because it is not possible to have multiple versions of the same CRD present on a cluster for different tenants. + +In OLMv1, we will not design the core APIs and controllers around this promise. Instead, we will build an API where ownership of installed objects is not shared. Managed objects are owned by exactly one extension. + +This pattern is generic, aligns with the Kubernetes API, and makes multi-tenancy a possibility, but not a guarantee or core concept. We will explore the implications of this design on existing OLMv0 registry+v1 bundles as part of the larger v0 to v1 migration design. For net new content, operator authors that intend multiple installations of operator on the same cluster would need to package their components to account for this ownership rule. Generally, this would entail separation along these lines: +- CRDs, conversion webhook workloads, and admission webhook configurations and workloads, APIServices and workloads. +- Controller workloads, service accounts, RBAC, etc. + +OLMv1 will include primitives (e.g. templating) to make it possible to have multiple non-conflicting installations of bundles. + +However it should be noted that the purpose of these primitives is not to enable multi-tenancy. It is to enable administrators to provide configuration for the installation of an extension. The fact that operators can be packaged as separate bundles and parameterized in a way that permits multiple controller installations is incidental, and not something that OLMv1 will encourage or promote. + +### Make OLM secure by default + +OLMv0 runs as cluster-admin, which is a security concern. OLMv0 has optional security controls for operator installations via the OperatorGroup, which allows a user with permission to create or update them to also set a ServiceAccount that will be used for authorization purposes on operator installations and upgrades in that namespace. If a ServiceAccount is not explicitly specified, OLM’s cluster-admin credentials are used. Another avenue that cluster administrators have is to lock down permissions and usage of the CatalogSource API, disable default catalogs, and provide tenants with custom vetted catalogs. However if a cluster admin is not aware of these options, the default configuration of a cluster results in users with permission to create a Subscription in namespaces that contain an OperatorGroup effectively have cluster-admin, because OLMv0 has unlimited permissions to install any bundle available in the default catalogs and the default community catalog is not vetted for limited RBAC. Because OLMv0 is used to install more RBAC and run arbitrary workloads, there are numerous potential vectors that attackers could exploit. While there are no known exploits and there has not been any specific concern reported from customers, we believe CNCF’s reputation rest on secure cloud-native software and that this is a non-negotiable area to improve. + +To make OLM secure by default: +- OLMv1 will not be granted cluster admin permissions. Instead it will require service accounts provided by users to actually install, upgrade, and delete content. In addition to the security this provides, it also fulfills one of OLM’s long-standing requirements: halt when bundle upgrades require additional permissions and wait until those permissions are granted. +- OLMv1 will use secure communication protocols between all internal components and between itself and its clients. + +### Simple and predictable semantics for install, upgrade, and delete + +OLMv0 has grown into a complex web of functionality that is difficult to understand, even for seasoned Kubernetes veterans. + +In OLMv1 we will move to GitOps-friendly APIs that allow administrators to rely on their experience with conventional Kubernetes API behavior (declarative, eventually consistent) to manage operator lifecycles. + +OLMv1 will reduce its API surface down to two primary APIs that represent catalogs of content, and intent for that content to be installed on the cluster. + +OLMv1 will: +- Permit administrators to pin to specific versions, channels, version ranges, or combinations of both. +- Permit administrators to pause management of an installation for maintenance or troubleshooting purposes. +- Put opinionated guardrails up by default (e.g. follow operator developer-defined upgrade edges). +- Give administrators escape hatches to disable any or all of OLMs guardrails. +- Delete managed content when a user deletes the OLM object that represents it. + +### APIs and behaviors to handle common controller patterns + +OLMv0 takes an extremely opinionated stance on the contents of the bundles it installs and in the way that operators can be lifecycled. The original designers believed these opinions would keep OLM’s scope limited and that they encompassed best practices for operator lifecycling. Some of these opinions are: +- All bundles must include a ClusterServiceVersion, which ostensibly gives operator authors an API that they can use to fully describe how to run the operator, what permissions it requires, what APIs it provides, and what metadata to show to users. +- Bundles cannot contain arbitrary objects. OLMv0 needs to have specific handling for each resource that it supports. +- Cluster administrators cannot override OLM safety checks around CRD changes or upgrades. + +OLMv1 will take a slightly different approach: +- It will not require bundles to have very specific controller-centric shapes. OLMv1 will happily install a bundle that contains a deployment, service, and ingress or a bundle that contains a single configmap. +- However for bundles that do include CRDs, controllers, RBAC, webhooks, and other objects that relate to the behavior of the apiserver, OLM will continue to have opinions and special handling: + - CRD upgrade checks (best effort) + - Specific knowledge and handling of webhooks. +- To the extent necessary OLMv1 will include optional controller-centric concepts in its APIs and or CLIs in order to facilitate the most common controller patterns. Examples could include: + - Permission management + - CRD upgrade check policies +- OLMv1 will continue to have opinions about upgrade traversals and CRD changes that help users prevent accidental breakage, but it will also allow administrators to disable safeguards and proceed anyway. + +OLMv0 has some support for automatic upgrades. However administrators cannot control the maximum version for automatic upgrades, and the upgrade policy (manual vs automatic) applies to all operators in a namespace. If any operator’s upgrade policy is manual, all upgrades of all operators in the namespace must be approved manually. + +OLMv1 will have fine-grained control for version ranges (and pins) and for controlling automatic upgrades for individual operators regardless of the policy of other operators installed in the same namespace. + +### Constraint checking (but not automated on-cluster management) + +OLMv0 includes support for dependency and constraint checking for many common use cases (e.g. required and provided APIs, required cluster version, required package versions). It also has other constraint APIs that have not gained traction (e.g. CEL expressions and compound constraints). In addition to its somewhat hap-hazard constraint expression support, OLMv0 also automatically installs dependency trees, which has proven problematic in several respects: +1. OLMv0 can resolve existing dependencies from outside the current namespace, but it can only install new dependencies in the current namespace. One scenario where this is problematic is if A depends on B, where A supports only OwnNamespace mode and B supports only AllNamespace mode. In that case, OLMv0’s auto dependency management fails because B cannot be installed in the same namespace as A (assuming the OperatorGroup in that namespace is configured for OwnNamespace operators to work). +2. OLMv0’s logic for choosing a dependency among multiple contenders is confusing and error-prone, and an administrator’s ability to have fine-grained control of upgrades is essentially limited to building and deploying tailor-made catalogs. +3. OLMv0 automatically installs dependencies. The only way for an administrator to avoid this OLMv0 functionality is to fully understand the dependency tree in advance and to then install dependencies from the leaves to the root so that OLMv0 always detects that dependencies are already met. If OLMv0 installs a dependency for you, it does not uninstall it when it is no longer depended upon. + +OLMv1 will not provide dependency resolution among packages in the catalog (see [Dependencies based on watched namespaces](#dependencies-based-on-watched-namespaces)) + +OLMv1 will provide constraint checking based on available cluster state. Constraint checking will be limited to checking whether the existing constraints are met. If so, install proceeds. If not, unmet constraints will be reported and the install/upgrade waits until constraints are met. + +The Operator Framework team will perform a survey of registry+v1 packages that currently rely on OLMv0’s dependency features and will suggest a solution as part of the overall OLMv0 to OLMv1 migration effort. + +### Client libraries and CLIs contribute to the overall UX + +OLMv0 has no official client libraries or CLIs that can be used to augment its functionality or provide a more streamlined user experience. The kubectl "operator" plugin was developed several years ago, but has never been a focus of the core Operator Framework development team, and has never factored into the overall architecture. + +OLMv1 will deliver an official CLI (likely by overhauling the kubectl operator plugin) and will use it to meet requirements that are difficult or impossible to implement in a controller, or where an architectural assessment dictates that a client is the better choice. This CLI would automate standard workflows over cluster APIs to facilitate simple administrative actions (e.g. automatically create RBAC and ServiceAccounts necessary for an extension installation as an optional step in the CLI’s extension install experience). + +The official CLI will provide administrators and users with a UX that covers the most common scenarios users will encounter. + +The official CLI will explicitly NOT attempt to cover complex scenarios. Maintainers will reject requests to over-complicate the CLI. Users with advanced use cases will be able to directly interact with OLMv1’s on-cluster APIs. + +The idea is: +- On-cluster APIs can be used to manage operators in 100% of cases (assuming bundle content is structured in a compatible way) +- The official CLI will cover standard user flows, covering ~80% of use cases. +- Third-party or unofficial CLIs will cover the remaining ~20% of use cases. + +Areas where the official CLI could provide value include: +- Catalog interactions (search, list, inspect, etc.) +- Standard install/upgrade/delete commands +- Upgrade previews +- RBAC management +- Discovery of available APIs + diff --git a/docs/requirements.txt b/docs/requirements.txt index 4195482c2..09c487e5b 100644 --- a/docs/requirements.txt +++ b/docs/requirements.txt @@ -14,7 +14,7 @@ markdown2==2.4.13 MarkupSafe==2.1.5 mergedeep==1.3.4 mkdocs==1.5.3 -mkdocs-material==9.5.14 +mkdocs-material==9.5.15 mkdocs-material-extensions==1.3.1 packaging==24.0 paginate==0.5.6 diff --git a/go.mod b/go.mod index caa429f93..59ad4e8c8 100644 --- a/go.mod +++ b/go.mod @@ -2,7 +2,7 @@ module github.com/operator-framework/operator-controller go 1.21 -toolchain go1.21.7 +toolchain go1.21.0 require ( github.com/Masterminds/semver/v3 v3.2.1 @@ -11,11 +11,11 @@ require ( github.com/google/go-cmp v0.6.0 github.com/operator-framework/catalogd v0.11.0 github.com/operator-framework/deppy v0.3.0 - github.com/operator-framework/operator-registry v1.36.0 + github.com/operator-framework/operator-registry v1.37.0 github.com/operator-framework/rukpak v0.18.1 github.com/spf13/pflag v1.0.5 github.com/stretchr/testify v1.9.0 - github.com/vmware-tanzu/carvel-kapp-controller v0.50.0 + github.com/vmware-tanzu/carvel-kapp-controller v0.50.2 go.uber.org/zap v1.27.0 golang.org/x/exp v0.0.0-20231006140011-7918f672742d gopkg.in/yaml.v2 v2.4.0 @@ -50,9 +50,9 @@ require ( github.com/containers/storage v1.51.0 // indirect github.com/davecgh/go-spew v1.1.1 // indirect github.com/distribution/reference v0.5.0 // indirect - github.com/docker/cli v24.0.7+incompatible // indirect + github.com/docker/cli v25.0.5+incompatible // indirect github.com/docker/distribution v2.8.3+incompatible // indirect - github.com/docker/docker v24.0.7+incompatible // indirect + github.com/docker/docker v25.0.5+incompatible // indirect github.com/docker/docker-credential-helpers v0.8.0 // indirect github.com/docker/go-connections v0.4.0 // indirect github.com/docker/go-units v0.5.0 // indirect @@ -103,7 +103,7 @@ require ( github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 // indirect github.com/onsi/gomega v1.31.1 // indirect github.com/opencontainers/go-digest v1.0.0 // indirect - github.com/opencontainers/image-spec v1.1.0-rc5 // indirect + github.com/opencontainers/image-spec v1.1.0-rc6 // indirect github.com/opencontainers/runc v1.1.12 // indirect github.com/opencontainers/runtime-spec v1.1.0 // indirect github.com/operator-framework/api v0.22.0 // indirect @@ -161,6 +161,6 @@ require ( sigs.k8s.io/yaml v1.4.0 // indirect ) -replace github.com/operator-framework/rukpak => github.com/openshift/operator-framework-rukpak v0.0.0-20240308020514-7589a1f04ea1 +replace github.com/operator-framework/rukpak => github.com/openshift/operator-framework-rukpak v0.0.0-20240326115409-bf49b7249b21 replace github.com/operator-framework/catalogd => github.com/openshift/operator-framework-catalogd v0.0.0-20240221182512-9666df2685f2 diff --git a/go.sum b/go.sum index e4b9fad87..7aef87213 100644 --- a/go.sum +++ b/go.sum @@ -1,8 +1,6 @@ cloud.google.com/go v0.26.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw= github.com/AdaLogics/go-fuzz-headers v0.0.0-20230811130428-ced1acdcaa24 h1:bvDV9vkmnHYOMsOr4WLk+Vo07yKIzd94sVoIqshQ4bU= github.com/AdaLogics/go-fuzz-headers v0.0.0-20230811130428-ced1acdcaa24/go.mod h1:8o94RPi1/7XTJvwPpRSzSUedZrtlirdB3r9Z20bi2f8= -github.com/Azure/go-ansiterm v0.0.0-20230124172434-306776ec8161 h1:L/gRVlceqvL25UVaW/CKtUDjefjrs0SPonmDGUVOYP0= -github.com/Azure/go-ansiterm v0.0.0-20230124172434-306776ec8161/go.mod h1:xomTg63KZ2rFqZQzSB4Vz2SUXa1BpHTVz9L5PTmPC4E= github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU= github.com/BurntSushi/toml v1.3.2 h1:o7IhLm0Msx3BaB+n3Ag7L8EVlByGnpq14C4YWiu/gL8= github.com/BurntSushi/toml v1.3.2/go.mod h1:CxXYINrC8qIiEnFrOxCa7Jy5BFHlXnUU2pbicEuybxQ= @@ -73,12 +71,12 @@ github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/distribution/reference v0.5.0 h1:/FUIFXtfc/x2gpa5/VGfiGLuOIdYa1t65IKK2OFGvA0= github.com/distribution/reference v0.5.0/go.mod h1:BbU0aIcezP1/5jX/8MP0YiH4SdvB5Y4f/wlDRiLyi3E= -github.com/docker/cli v24.0.7+incompatible h1:wa/nIwYFW7BVTGa7SWPVyyXU9lgORqUb1xfI36MSkFg= -github.com/docker/cli v24.0.7+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8= +github.com/docker/cli v25.0.5+incompatible h1:3Llw3kcE1gOScEojA247iDD+p1l9hHeC7H3vf3Zd5fk= +github.com/docker/cli v25.0.5+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8= github.com/docker/distribution v2.8.3+incompatible h1:AtKxIZ36LoNK51+Z6RpzLpddBirtxJnzDrHLEKxTAYk= github.com/docker/distribution v2.8.3+incompatible/go.mod h1:J2gT2udsDAN96Uj4KfcMRqY0/ypR+oyYUYmja8H+y+w= -github.com/docker/docker v24.0.7+incompatible h1:Wo6l37AuwP3JaMnZa226lzVXGA3F9Ig1seQen0cKYlM= -github.com/docker/docker v24.0.7+incompatible/go.mod h1:eEKB0N0r5NX/I1kEveEz05bcu8tLC/8azJZsviup8Sk= +github.com/docker/docker v25.0.5+incompatible h1:UmQydMduGkrD5nQde1mecF/YnSbTOaPeFIeP5C4W+DE= +github.com/docker/docker v25.0.5+incompatible/go.mod h1:eEKB0N0r5NX/I1kEveEz05bcu8tLC/8azJZsviup8Sk= github.com/docker/docker-credential-helpers v0.8.0 h1:YQFtbBQb4VrpoPxhFuzEBPQ9E16qz5SpHLS+uswaCp8= github.com/docker/docker-credential-helpers v0.8.0/go.mod h1:UGFXcuoQ5TxPiB54nHOZ32AWRqQdECoh/Mg0AlEYb40= github.com/docker/go-connections v0.4.0 h1:El9xVISelRB7BuFusrZozjnkIM5YnzCViNKohAFqRJQ= @@ -252,15 +250,11 @@ github.com/moby/sys/mountinfo v0.7.1 h1:/tTvQaSJRr2FshkhXiIpux6fQ2Zvc4j7tAhMTStA github.com/moby/sys/mountinfo v0.7.1/go.mod h1:IJb6JQeOklcdMU9F5xQ8ZALD+CUr5VlGpwtX+VE0rpI= github.com/moby/sys/sequential v0.5.0 h1:OPvI35Lzn9K04PBbCLW0g4LcFAJgHsvXsRyewg5lXtc= github.com/moby/sys/sequential v0.5.0/go.mod h1:tH2cOOs5V9MlPiXcQzRC+eEyab644PWKGRYaaV5ZZlo= -github.com/moby/term v0.5.0 h1:xt8Q1nalod/v7BqbG21f8mQPqH+xAaC9C3N3wfWbVP0= -github.com/moby/term v0.5.0/go.mod h1:8FzsFHVUBGZdbDsJw/ot+X+d5HLUbvklYLJ9uGfcI3Y= github.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q= github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd h1:TRLaZ9cD/w8PVh93nsPXa1VrQ6jlwL5oN8l14QlcNfg= github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q= github.com/modern-go/reflect2 v1.0.2 h1:xBagoLtFs94CBntxluKeaWgTMpvLxC4ur3nMaC9Gz0M= github.com/modern-go/reflect2 v1.0.2/go.mod h1:yWuevngMOJpCy52FWWMvUC8ws7m/LJsjYzDa0/r8luk= -github.com/morikuni/aec v1.0.0 h1:nP9CBfwrvYnBRgY6qfDQkygYDmYwOilePFkwzv4dU8A= -github.com/morikuni/aec v1.0.0/go.mod h1:BbKIizmSmc5MMPqRYbxO4ZU0S0+P200+tUnFx7PXmsc= github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 h1:C3w9PqII01/Oq1c1nUAm88MOHcQC9l5mIlSMApZMrHA= github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ= github.com/niemeyer/pretty v0.0.0-20200227124842-a10e7caefd8e/go.mod h1:zD1mROLANZcx1PVRCS0qkT7pwLkGfwJo4zjcN/Tysno= @@ -271,22 +265,22 @@ github.com/onsi/gomega v1.31.1 h1:KYppCUK+bUgAZwHOu7EXVBKyQA6ILvOESHkn/tgoqvo= github.com/onsi/gomega v1.31.1/go.mod h1:y40C95dwAD1Nz36SsEnxvfFe8FFfNxzI5eJ0EYGyAy0= github.com/opencontainers/go-digest v1.0.0 h1:apOUWs51W5PlhuyGyz9FCeeBIOUDA/6nW8Oi/yOhh5U= github.com/opencontainers/go-digest v1.0.0/go.mod h1:0JzlMkj0TRzQZfJkVvzbP0HBR3IKzErnv2BNG4W4MAM= -github.com/opencontainers/image-spec v1.1.0-rc5 h1:Ygwkfw9bpDvs+c9E34SdgGOj41dX/cbdlwvlWt0pnFI= -github.com/opencontainers/image-spec v1.1.0-rc5/go.mod h1:X4pATf0uXsnn3g5aiGIsVnJBR4mxhKzfwmvK/B2NTm8= +github.com/opencontainers/image-spec v1.1.0-rc6 h1:XDqvyKsJEbRtATzkgItUqBA7QHk58yxX1Ov9HERHNqU= +github.com/opencontainers/image-spec v1.1.0-rc6/go.mod h1:W4s4sFTMaBeK1BQLXbG4AdM2szdn85PY75RI83NrTrM= github.com/opencontainers/runc v1.1.12 h1:BOIssBaW1La0/qbNZHXOOa71dZfZEQOzW7dqQf3phss= github.com/opencontainers/runc v1.1.12/go.mod h1:S+lQwSfncpBha7XTy/5lBwWgm5+y5Ma/O44Ekby9FK8= github.com/opencontainers/runtime-spec v1.1.0 h1:HHUyrt9mwHUjtasSbXSMvs4cyFxh+Bll4AjJ9odEGpg= github.com/opencontainers/runtime-spec v1.1.0/go.mod h1:jwyrGlmzljRJv/Fgzds9SsS/C5hL+LL3ko9hs6T5lQ0= github.com/openshift/operator-framework-catalogd v0.0.0-20240221182512-9666df2685f2 h1:yyT13hKySvcpcduEA6ZFN6po4CQGE8aSk2nkp9Zy9PY= github.com/openshift/operator-framework-catalogd v0.0.0-20240221182512-9666df2685f2/go.mod h1:AHz6B7NxC7cywF6P3XclmCim1bs0y0g2+LdycdIGAmE= -github.com/openshift/operator-framework-rukpak v0.0.0-20240308020514-7589a1f04ea1 h1:gdTBoJlL+itlDgRBIcOTs84RKmRT3I9CQFU0/jASAl0= -github.com/openshift/operator-framework-rukpak v0.0.0-20240308020514-7589a1f04ea1/go.mod h1:abntOB7EG2Ma9PQe2RLHhrmic2eGZAhnwP2zjDx/ghs= +github.com/openshift/operator-framework-rukpak v0.0.0-20240326115409-bf49b7249b21 h1:me3We7mIb7z9uAXuCKWaNZ/LGinsl6E5e2DZrFOnh64= +github.com/openshift/operator-framework-rukpak v0.0.0-20240326115409-bf49b7249b21/go.mod h1:jImbz2OSJ5QoF1dlJLmQWzGDJ1DZnlksFv6JYCO5zUs= github.com/operator-framework/api v0.22.0 h1:UZSn+iaQih4rCReezOnWTTJkMyawwV5iLnIItaOzytY= github.com/operator-framework/api v0.22.0/go.mod h1:p/7YDbr+n4fmESfZ47yLAV1SvkfE6NU2aX8KhcfI0GA= github.com/operator-framework/deppy v0.3.0 h1:W8wpF0ehcTAdH2WfMyqMPI5Ja0Qv8M5FMO5cXgJvEQ8= github.com/operator-framework/deppy v0.3.0/go.mod h1:EHDxZz8fKGvuymCng3G/Ou7wuX14GaLr0cmf2u29Oog= -github.com/operator-framework/operator-registry v1.36.0 h1:Xp+0bIOboP78qPGv9odh4Ird2LjsTldrztVRGsCkuxI= -github.com/operator-framework/operator-registry v1.36.0/go.mod h1:+wioYPVlq1htVtpR5E1648A7ok1zh2Vn6E53ur3LnWs= +github.com/operator-framework/operator-registry v1.37.0 h1:XBCY6pkCBE+rIbnrN+MFblrGfZCvYABf43Lf7AM0X8k= +github.com/operator-framework/operator-registry v1.37.0/go.mod h1:9w3/HO+6btZAgsUWz4aHEW4womn8ImdrSmHoXDDP5LA= github.com/otiai10/copy v1.14.0 h1:dCI/t1iTdYGtkvCuBG2BgR6KZa83PTclw4U5n2wAllU= github.com/otiai10/copy v1.14.0/go.mod h1:ECfuL02W+/FkTWZWgQqXPWZgW9oeKCSQ5qVfSc4qc4w= github.com/otiai10/mint v1.5.1 h1:XaPLeE+9vGbuyEHem1JNk3bYc7KKqyI/na0/mLd/Kks= @@ -342,8 +336,8 @@ github.com/ulikunitz/xz v0.5.11 h1:kpFauv27b6ynzBNT/Xy+1k+fK4WswhN/6PN5WhFAGw8= github.com/ulikunitz/xz v0.5.11/go.mod h1:nbz6k7qbPmH4IRqmfOplQw/tblSgqTqBwxkY0oWt/14= github.com/vbatts/tar-split v0.11.5 h1:3bHCTIheBm1qFTcgh9oPu+nNBtX+XJIupG/vacinCts= github.com/vbatts/tar-split v0.11.5/go.mod h1:yZbwRsSeGjusneWgA781EKej9HF8vme8okylkAeNKLk= -github.com/vmware-tanzu/carvel-kapp-controller v0.50.0 h1:TCqaH+7OzhgHlD6DZphfu27hCefBnxqAPZyV/2NYZ2g= -github.com/vmware-tanzu/carvel-kapp-controller v0.50.0/go.mod h1:9RwhTFRNwsiLMoIJ6kz5R/EbOXkb+beNJ8y5fyU72Pc= +github.com/vmware-tanzu/carvel-kapp-controller v0.50.2 h1:/0iDxqCzQIDLhasdnx2Hw+iW5VbL2OenfHESbWOZ5fE= +github.com/vmware-tanzu/carvel-kapp-controller v0.50.2/go.mod h1:dcE+zg3cMl6CWRWwA1K9I9x24wGF98wlsatz5UEfdFo= github.com/vmware-tanzu/carvel-vendir v0.36.0 h1:F9FNk2YysC6DlUDP2Nl2ynsv6JH8S0FYT4OK6HrRco0= github.com/vmware-tanzu/carvel-vendir v0.36.0/go.mod h1:rPGI/zItMK4QgLRpLix2aykoYufavHyKqqLTONXb2uE= github.com/xanzy/ssh-agent v0.3.0/go.mod h1:3s9xbODqPuuhK9JV1R321M/FlMZSBvE5aY6eAcqrDh0= diff --git a/openshift/operator-controller.Dockerfile b/openshift/operator-controller.Dockerfile index a79cf4822..33ccc52c4 100644 --- a/openshift/operator-controller.Dockerfile +++ b/openshift/operator-controller.Dockerfile @@ -1,9 +1,9 @@ -FROM registry.ci.openshift.org/ocp/builder:rhel-9-golang-1.21-openshift-4.16 AS builder +FROM registry.ci.openshift.org/ocp/builder:rhel-8-golang-1.21-openshift-4.16 AS builder WORKDIR /build COPY . . RUN make go-build-local -FROM registry.ci.openshift.org/ocp/4.16:base-rhel9 +FROM registry.ci.openshift.org/ocp/4.16:base USER 1001 COPY --from=builder /build/bin/manager /manager COPY openshift/manifests /openshift/manifests diff --git a/requirements.txt b/requirements.txt index 95e7f32ab..f997ca2c1 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1 +1 @@ -mkdocs-material==9.5.14 +mkdocs-material==9.5.15 diff --git a/vendor/github.com/docker/cli/AUTHORS b/vendor/github.com/docker/cli/AUTHORS index 483743c99..d6d23b3de 100644 --- a/vendor/github.com/docker/cli/AUTHORS +++ b/vendor/github.com/docker/cli/AUTHORS @@ -2,6 +2,7 @@ # This file lists all contributors to the repository. # See scripts/docs/generate-authors.sh to make modifications. +A. Lester Buck III Aanand Prasad Aaron L. Xu Aaron Lehmann @@ -16,6 +17,7 @@ Adolfo Ochagavía Adrian Plata Adrien Duermael Adrien Folie +Adyanth Hosavalike Ahmet Alp Balkan Aidan Feldman Aidan Hobson Sayers @@ -26,7 +28,7 @@ Akim Demaille Alan Thompson Albert Callarisa Alberto Roura -Albin Kerouanton +Albin Kerouanton Aleksa Sarai Aleksander Piotrowski Alessandro Boch @@ -34,6 +36,7 @@ Alex Couture-Beil Alex Mavrogiannis Alex Mayer Alexander Boyd +Alexander Chneerov Alexander Larsson Alexander Morozov Alexander Ryabov @@ -41,6 +44,7 @@ Alexandre González Alexey Igrychev Alexis Couvreur Alfred Landrum +Ali Rostami Alicia Lauerman Allen Sun Alvin Deng @@ -79,7 +83,9 @@ Arko Dasgupta Arnaud Porterie Arnaud Rebillout Arthur Peka +Ashly Mathew Ashwini Oruganti +Aslam Ahemad Azat Khuyiyakhmetov Bardia Keyoumarsi Barnaby Gray @@ -98,7 +104,9 @@ Bill Wang Bin Liu Bingshen Wang Bishal Das +Bjorn Neergaard Boaz Shuster +Boban Acimovic Bogdan Anton Boris Pruessmann Brad Baker @@ -109,6 +117,7 @@ Brent Salisbury Bret Fisher Brian (bex) Exelbierd Brian Goff +Brian Tracy Brian Wieder Bruno Sousa Bryan Bess @@ -136,6 +145,7 @@ Chen Chuanliang Chen Hanxiao Chen Mingjie Chen Qiu +Chris Chinchilla Chris Couzens Chris Gavin Chris Gibson @@ -163,6 +173,8 @@ Conner Crosby Corey Farrell Corey Quon Cory Bennet +Cory Snider +Craig Osterhout Craig Wilhite Cristian Staretu Daehyeok Mun @@ -171,6 +183,7 @@ Daisuke Ito dalanlan Damien Nadé Dan Cotora +Danial Gharib Daniel Artine Daniel Cassidy Daniel Dao @@ -210,6 +223,7 @@ Denis Defreyne Denis Gladkikh Denis Ollier Dennis Docter +dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Derek McGowan Des Preston Deshi Xiao @@ -232,11 +246,13 @@ DongGeon Lee Doug Davis Drew Erny Ed Costello +Ed Morley <501702+edmorley@users.noreply.github.com> Elango Sivanandam Eli Uriegas Eli Uriegas Elias Faxö Elliot Luo <956941328@qq.com> +Eric Bode Eric Curtin Eric Engestrom Eric G. Noriega @@ -254,6 +270,7 @@ Eugene Yakubovich Evan Allrich Evan Hazlett Evan Krall +Evan Lezar Evelyn Xu Everett Toews Fabio Falci @@ -275,6 +292,7 @@ Frederik Nordahl Jul Sabroe Frieder Bluemle Gabriel Gore Gabriel Nicolas Avellaneda +Gabriela Georgieva Gaetan de Villele Gang Qiao Gary Schaetz @@ -288,6 +306,7 @@ Gleb Stsenov Goksu Toprak Gou Rao Govind Rai +Graeme Wiebe Grant Reaber Greg Pflaum Gsealy @@ -311,6 +330,7 @@ Hernan Garcia Hongbin Lu Hu Keping Huayi Zhang +Hugo Chastel Hugo Gabriel Eyherabide huqun Huu Nguyen @@ -329,9 +349,12 @@ Ivan Grund Ivan Markin Jacob Atzen Jacob Tomlinson +Jacopo Rigoli Jaivish Kothari Jake Lambert Jake Sanders +Jake Stokes +Jakub Panek James Nesbitt James Turnbull Jamie Hannaford @@ -408,10 +431,12 @@ Josh Chorlton Josh Hawn Josh Horwitz Josh Soref +Julian Julien Barbier Julien Kassar Julien Maitrehenry Justas Brazauskas +Justin Chadwell Justin Cormack Justin Simonelis Justyn Temme @@ -434,7 +459,7 @@ Kelton Bassingthwaite Ken Cochrane Ken ICHIKAWA Kenfe-Mickaël Laventure -Kevin Alvarez +Kevin Alvarez Kevin Burke Kevin Feyrer Kevin Kern @@ -454,6 +479,7 @@ Kyle Mitofsky Lachlan Cooper Lai Jiangshan Lars Kellogg-Stedman +Laura Brehm Laura Frank Laurent Erignoux Lee Gaines @@ -462,10 +488,10 @@ Lennie Leo Gallucci Leonid Skorospelov Lewis Daly +Li Fu Bang Li Yi Li Yi Liang-Chi Hsieh -Lifubang Lihua Tang Lily Guo Lin Lu @@ -480,6 +506,7 @@ Louis Opter Luca Favatella Luca Marturana Lucas Chan +Luis Henrique Mulinari Luka Hartwig Lukas Heeren Lukasz Zajaczkowski @@ -498,6 +525,7 @@ mapk0y Marc Bihlmaier Marc Cornellà Marco Mariani +Marco Spiess Marco Vedovati Marcus Martins Marianna Tessel @@ -522,6 +550,7 @@ Max Shytikov Maxime Petazzoni Maximillian Fan Xavier Mei ChunTao +Melroy van den Berg Metal <2466052+tedhexaflow@users.noreply.github.com> Micah Zoltu Michael A. Smith @@ -593,6 +622,7 @@ Nishant Totla NIWA Hideyuki Noah Treuhaft O.S. Tezer +Oded Arbel Odin Ugedal ohmystack OKA Naoya @@ -604,19 +634,21 @@ Otto Kekäläinen Ovidio Mallo Pascal Borreli Patrick Böänziger +Patrick Daigle <114765035+pdaig@users.noreply.github.com> Patrick Hemmer Patrick Lang Paul Paul Kehrer Paul Lietar Paul Mulders +Paul Seyfert Paul Weaver Pavel Pospisil Paweł Gronowski Paweł Pokrywka Paweł Szczekutowicz Peeyush Gupta -Per Lundberg +Per Lundberg Peter Dave Hello Peter Edge Peter Hsu @@ -639,6 +671,7 @@ Preston Cowley Pure White Qiang Huang Qinglan Peng +QQ喵 qudongfang Raghavendra K T Rahul Kadyan @@ -657,6 +690,7 @@ Rick Wieman Ritesh H Shukla Riyaz Faizullabhoy Rob Gulewich +Rob Murray Robert Wallis Robin Naundorf Robin Speekenbrink @@ -689,6 +723,7 @@ Sandro Jäckel Santhosh Manohar Sargun Dhillon Saswat Bhattacharya +Saurabh Kumar Scott Brenner Scott Collier Sean Christopherson @@ -788,6 +823,7 @@ uhayate Ulrich Bareth Ulysses Souza Umesh Yadav +Vaclav Struhar Valentin Lorentz Vardan Pogosian Venkateswara Reddy Bukkasamudram @@ -795,6 +831,7 @@ Veres Lajos Victor Vieux Victoria Bialas Viktor Stanchev +Ville Skyttä Vimal Raghubir Vincent Batts Vincent Bernat @@ -831,6 +868,7 @@ Yong Tang Yosef Fertel Yu Peng Yuan Sun +Yucheng Wu Yue Zhang Yunxiang Huang Zachary Romero diff --git a/vendor/github.com/docker/cli/cli/config/config.go b/vendor/github.com/docker/cli/cli/config/config.go index b7c05c3f8..952f6e71f 100644 --- a/vendor/github.com/docker/cli/cli/config/config.go +++ b/vendor/github.com/docker/cli/cli/config/config.go @@ -16,32 +16,25 @@ import ( ) const ( - // ConfigFileName is the name of config file + // EnvOverrideConfigDir is the name of the environment variable that can be + // used to override the location of the client configuration files (~/.docker). + // + // It takes priority over the default, but can be overridden by the "--config" + // command line option. + EnvOverrideConfigDir = "DOCKER_CONFIG" + + // ConfigFileName is the name of the client configuration file inside the + // config-directory. ConfigFileName = "config.json" configFileDir = ".docker" - oldConfigfile = ".dockercfg" // Deprecated: remove once we stop printing deprecation warning contextsDir = "contexts" ) var ( initConfigDir = new(sync.Once) configDir string - homeDir string ) -// resetHomeDir is used in testing to reset the "homeDir" package variable to -// force re-lookup of the home directory between tests. -func resetHomeDir() { - homeDir = "" -} - -func getHomeDir() string { - if homeDir == "" { - homeDir = homedir.Get() - } - return homeDir -} - // resetConfigDir is used in testing to reset the "configDir" package variable // and its sync.Once to force re-lookup between tests. func resetConfigDir() { @@ -49,19 +42,14 @@ func resetConfigDir() { initConfigDir = new(sync.Once) } -func setConfigDir() { - if configDir != "" { - return - } - configDir = os.Getenv("DOCKER_CONFIG") - if configDir == "" { - configDir = filepath.Join(getHomeDir(), configFileDir) - } -} - // Dir returns the directory the configuration file is stored in func Dir() string { - initConfigDir.Do(setConfigDir) + initConfigDir.Do(func() { + configDir = os.Getenv(EnvOverrideConfigDir) + if configDir == "" { + configDir = filepath.Join(homedir.Get(), configFileDir) + } + }) return configDir } @@ -72,6 +60,8 @@ func ContextStoreDir() string { // SetDir sets the directory the configuration file is stored in func SetDir(dir string) { + // trigger the sync.Once to synchronise with Dir() + initConfigDir.Do(func() {}) configDir = filepath.Clean(dir) } @@ -96,55 +86,43 @@ func LoadFromReader(configData io.Reader) (*configfile.ConfigFile, error) { // Load reads the configuration files in the given directory, and sets up // the auth config information and returns values. -// FIXME: use the internal golang config parser func Load(configDir string) (*configfile.ConfigFile, error) { - cfg, _, err := load(configDir) - return cfg, err -} - -// TODO remove this temporary hack, which is used to warn about the deprecated ~/.dockercfg file -// so we can remove the bool return value and collapse this back into `Load` -func load(configDir string) (*configfile.ConfigFile, bool, error) { - printLegacyFileWarning := false - if configDir == "" { configDir = Dir() } + return load(configDir) +} +func load(configDir string) (*configfile.ConfigFile, error) { filename := filepath.Join(configDir, ConfigFileName) configFile := configfile.New(filename) - // Try happy path first - latest config file - if file, err := os.Open(filename); err == nil { - defer file.Close() - err = configFile.LoadFromReader(file) - if err != nil { - err = errors.Wrap(err, filename) + file, err := os.Open(filename) + if err != nil { + if os.IsNotExist(err) { + // + // if file is there but we can't stat it for any reason other + // than it doesn't exist then stop + return configFile, nil } - return configFile, printLegacyFileWarning, err - } else if !os.IsNotExist(err) { // if file is there but we can't stat it for any reason other // than it doesn't exist then stop - return configFile, printLegacyFileWarning, errors.Wrap(err, filename) + return configFile, nil } - - // Can't find latest config file so check for the old one - filename = filepath.Join(getHomeDir(), oldConfigfile) - if _, err := os.Stat(filename); err == nil { - printLegacyFileWarning = true + defer file.Close() + err = configFile.LoadFromReader(file) + if err != nil { + err = errors.Wrap(err, filename) } - return configFile, printLegacyFileWarning, nil + return configFile, err } // LoadDefaultConfigFile attempts to load the default config file and returns // an initialized ConfigFile struct if none is found. func LoadDefaultConfigFile(stderr io.Writer) *configfile.ConfigFile { - configFile, printLegacyFileWarning, err := load(Dir()) + configFile, err := load(Dir()) if err != nil { - fmt.Fprintf(stderr, "WARNING: Error loading config file: %v\n", err) - } - if printLegacyFileWarning { - _, _ = fmt.Fprintln(stderr, "WARNING: Support for the legacy ~/.dockercfg configuration file and file-format has been removed and the configuration file will be ignored") + _, _ = fmt.Fprintf(stderr, "WARNING: Error loading config file: %v\n", err) } if !configFile.ContainsAuth() { configFile.CredentialsStore = credentials.DetectDefaultStore(configFile.CredentialsStore) diff --git a/vendor/github.com/docker/cli/cli/config/configfile/file_unix.go b/vendor/github.com/docker/cli/cli/config/configfile/file_unix.go index 353887547..06b811e7d 100644 --- a/vendor/github.com/docker/cli/cli/config/configfile/file_unix.go +++ b/vendor/github.com/docker/cli/cli/config/configfile/file_unix.go @@ -1,5 +1,4 @@ //go:build !windows -// +build !windows package configfile diff --git a/vendor/github.com/docker/cli/cli/config/credentials/default_store.go b/vendor/github.com/docker/cli/cli/config/credentials/default_store.go index 402235bff..a36afc41f 100644 --- a/vendor/github.com/docker/cli/cli/config/credentials/default_store.go +++ b/vendor/github.com/docker/cli/cli/config/credentials/default_store.go @@ -1,21 +1,22 @@ package credentials -import ( - exec "golang.org/x/sys/execabs" -) +import "os/exec" // DetectDefaultStore return the default credentials store for the platform if -// the store executable is available. +// no user-defined store is passed, and the store executable is available. func DetectDefaultStore(store string) string { - platformDefault := defaultCredentialsStore() - - // user defined or no default for platform - if store != "" || platformDefault == "" { + if store != "" { + // use user-defined return store } - if _, err := exec.LookPath(remoteCredentialsPrefix + platformDefault); err == nil { - return platformDefault + platformDefault := defaultCredentialsStore() + if platformDefault == "" { + return "" + } + + if _, err := exec.LookPath(remoteCredentialsPrefix + platformDefault); err != nil { + return "" } - return "" + return platformDefault } diff --git a/vendor/github.com/docker/cli/cli/config/credentials/default_store_unsupported.go b/vendor/github.com/docker/cli/cli/config/credentials/default_store_unsupported.go index c9630ea51..40c16eb83 100644 --- a/vendor/github.com/docker/cli/cli/config/credentials/default_store_unsupported.go +++ b/vendor/github.com/docker/cli/cli/config/credentials/default_store_unsupported.go @@ -1,5 +1,4 @@ //go:build !windows && !darwin && !linux -// +build !windows,!darwin,!linux package credentials diff --git a/vendor/github.com/docker/cli/cli/config/credentials/native_store.go b/vendor/github.com/docker/cli/cli/config/credentials/native_store.go index f9619b038..b9af145b9 100644 --- a/vendor/github.com/docker/cli/cli/config/credentials/native_store.go +++ b/vendor/github.com/docker/cli/cli/config/credentials/native_store.go @@ -51,6 +51,7 @@ func (c *nativeStore) Get(serverAddress string) (types.AuthConfig, error) { auth.Username = creds.Username auth.IdentityToken = creds.IdentityToken auth.Password = creds.Password + auth.ServerAddress = creds.ServerAddress return auth, nil } @@ -76,6 +77,9 @@ func (c *nativeStore) GetAll() (map[string]types.AuthConfig, error) { ac.Username = creds.Username ac.Password = creds.Password ac.IdentityToken = creds.IdentityToken + if ac.ServerAddress == "" { + ac.ServerAddress = creds.ServerAddress + } authConfigs[registry] = ac } diff --git a/vendor/github.com/docker/docker/AUTHORS b/vendor/github.com/docker/docker/AUTHORS index b31418192..48d04f9a9 100644 --- a/vendor/github.com/docker/docker/AUTHORS +++ b/vendor/github.com/docker/docker/AUTHORS @@ -27,6 +27,7 @@ Adam Miller Adam Mills Adam Pointer Adam Singer +Adam Thornton Adam Walz Adam Williams AdamKorcz @@ -173,6 +174,7 @@ Andy Rothfusz Andy Smith Andy Wilson Andy Zhang +Aneesh Kulkarni Anes Hasicic Angel Velazquez Anil Belur @@ -236,6 +238,7 @@ Ben Golub Ben Gould Ben Hall Ben Langfeld +Ben Lovy Ben Sargent Ben Severson Ben Toews @@ -262,7 +265,7 @@ Billy Ridgway Bily Zhang Bin Liu Bingshen Wang -Bjorn Neergaard +Bjorn Neergaard Blake Geno Boaz Shuster bobby abbott @@ -279,6 +282,7 @@ Brandon Liu Brandon Philips Brandon Rhodes Brendan Dixon +Brennan Kinney <5098581+polarathene@users.noreply.github.com> Brent Salisbury Brett Higgins Brett Kochendorfer @@ -363,6 +367,7 @@ chenyuzhu Chetan Birajdar Chewey Chia-liang Kao +Chiranjeevi Tirunagari chli Cholerae Hu Chris Alfonso @@ -433,8 +438,8 @@ Cristian Staretu cristiano balducci Cristina Yenyxe Gonzalez Garcia Cruceru Calin-Cristian +cui fliter CUI Wei -cuishuang Cuong Manh Le Cyprian Gracz Cyril F @@ -513,6 +518,7 @@ David Dooling David Gageot David Gebler David Glasser +David Karlsson <35727626+dvdksn@users.noreply.github.com> David Lawrence David Lechner David M. Karr @@ -602,6 +608,7 @@ Donald Huang Dong Chen Donghwa Kim Donovan Jones +Dorin Geman Doron Podoleanu Doug Davis Doug MacEachern @@ -636,6 +643,7 @@ Emily Rose Emir Ozer Eng Zer Jun Enguerran +Enrico Weigelt, metux IT consult Eohyung Lee epeterso er0k @@ -676,6 +684,7 @@ Evan Allrich Evan Carmi Evan Hazlett Evan Krall +Evan Lezar Evan Phoenix Evan Wies Evelyn Xu @@ -744,6 +753,7 @@ Frank Groeneveld Frank Herrmann Frank Macreery Frank Rosquin +Frank Villaro-Dixon Frank Yang Fred Lifton Frederick F. Kautz IV @@ -983,6 +993,7 @@ Jean Rouge Jean-Baptiste Barth Jean-Baptiste Dalido Jean-Christophe Berthon +Jean-Michel Rouet Jean-Paul Calderone Jean-Pierre Huynh Jean-Tiare Le Bigot @@ -1013,6 +1024,7 @@ Jeroen Jacobs Jesse Dearing Jesse Dubay Jessica Frazelle +Jeyanthinath Muthuram Jezeniel Zapanta Jhon Honce Ji.Zhilong @@ -1141,6 +1153,7 @@ junxu Jussi Nummelin Justas Brazauskas Justen Martin +Justin Chadwell Justin Cormack Justin Force Justin Keller <85903732+jk-vb@users.noreply.github.com> @@ -1183,6 +1196,7 @@ Ke Xu Kei Ohmura Keith Hudgins Keli Hu +Ken Bannister Ken Cochrane Ken Herner Ken ICHIKAWA @@ -1192,7 +1206,7 @@ Kenjiro Nakayama Kent Johnson Kenta Tada Kevin "qwazerty" Houdebert -Kevin Alvarez +Kevin Alvarez Kevin Burke Kevin Clark Kevin Feyrer @@ -1225,6 +1239,7 @@ Konstantin Gribov Konstantin L Konstantin Pelykh Kostadin Plachkov +kpcyrd Krasi Georgiev Krasimir Georgiev Kris-Mikael Krister @@ -1306,6 +1321,7 @@ Lorenzo Fontana Lotus Fenn Louis Delossantos Louis Opter +Luboslav Pivarc Luca Favatella Luca Marturana Luca Orlandi @@ -1344,6 +1360,7 @@ Manuel Meurer Manuel Rüger Manuel Woelker mapk0y +Marat Radchenko Marc Abramowitz Marc Kuo Marc Tamsky @@ -1383,6 +1400,7 @@ Martijn van Oosterhout Martin Braun Martin Dojcak Martin Honermeyer +Martin Jirku Martin Kelly Martin Mosegaard Amdisen Martin Muzatko @@ -1461,6 +1479,7 @@ Michael Holzheu Michael Hudson-Doyle Michael Huettermann Michael Irwin +Michael Kebe Michael Kuehn Michael Käufl Michael Neale @@ -1509,10 +1528,11 @@ Mike Lundy Mike MacCana Mike Naberezny Mike Snitzer +Mike Sul mikelinjie <294893458@qq.com> Mikhail Sobolev Miklos Szegedi -Milas Bowman +Milas Bowman Milind Chawre Miloslav Trmač mingqing @@ -1524,6 +1544,7 @@ mlarcher Mohammad Banikazemi Mohammad Nasirifar Mohammed Aaqib Ansari +Mohd Sadiq Mohit Soni Moorthy RS Morgan Bauer @@ -1606,6 +1627,7 @@ Noah Treuhaft NobodyOnSE noducks Nolan Darilek +Nolan Miles Noriki Nakamura nponeccop Nurahmadie @@ -1661,6 +1683,7 @@ Paul Lietar Paul Liljenberg Paul Morie Paul Nasrat +Paul Seiffert Paul Weaver Paulo Gomes Paulo Ribeiro @@ -1674,6 +1697,7 @@ Pavlos Ratis Pavol Vargovcik Pawel Konczalski Paweł Gronowski +payall4u Peeyush Gupta Peggy Li Pei Su @@ -1703,7 +1727,9 @@ Phil Estes Phil Sphicas Phil Spitler Philip Alexander Etling +Philip K. Warren Philip Monroe +Philipp Fruck Philipp Gillé Philipp Wahala Philipp Weissensteiner @@ -1741,6 +1767,7 @@ Quentin Brossard Quentin Perez Quentin Tayssier r0n22 +Rachit Sharma Radostin Stoyanov Rafal Jeczalik Rafe Colton @@ -1773,6 +1800,7 @@ Rich Horwood Rich Moyse Rich Seymour Richard Burnison +Richard Hansen Richard Harvey Richard Mathie Richard Metzler @@ -1788,6 +1816,7 @@ Ritesh H Shukla Riyaz Faizullabhoy Rob Cowsill <42620235+rcowsill@users.noreply.github.com> Rob Gulewich +Rob Murray Rob Vesse Robert Bachmann Robert Bittle @@ -1869,6 +1898,7 @@ ryancooper7 RyanDeng Ryo Nakao Ryoga Saito +Régis Behmo Rémy Greinhofer s. rannou Sabin Basyal @@ -1885,6 +1915,7 @@ Sam J Sharpe Sam Neirinck Sam Reis Sam Rijs +Sam Thibault Sam Whited Sambuddha Basu Sami Wagiaalla @@ -1908,6 +1939,7 @@ Satoshi Tagomori Scott Bessler Scott Collier Scott Johnston +Scott Moser Scott Percival Scott Stamp Scott Walls @@ -1923,6 +1955,7 @@ Sebastiaan van Steenis Sebastiaan van Stijn Sebastian Höffner Sebastian Radloff +Sebastian Thomschke Sebastien Goasguen Senthil Kumar Selvaraj Senthil Kumaran @@ -1996,6 +2029,7 @@ Stanislav Bondarenko Stanislav Levin Steeve Morin Stefan Berger +Stefan Gehrig Stefan J. Wernli Stefan Praszalowicz Stefan S. @@ -2003,6 +2037,7 @@ Stefan Scherer Stefan Staudenmeyer Stefan Weil Steffen Butzer +Stephan Henningsen Stephan Spindler Stephen Benjamin Stephen Crosby @@ -2204,6 +2239,7 @@ Vinod Kulkarni Vishal Doshi Vishnu Kannan Vitaly Ostrosablin +Vitor Anjos Vitor Monteiro Vivek Agarwal Vivek Dasgupta @@ -2250,6 +2286,7 @@ Wenxuan Zhao Wenyu You <21551128@zju.edu.cn> Wenzhi Liang Wes Morgan +Wesley Pettit Wewang Xiaorenfine Wiktor Kwapisiewicz Will Dietz @@ -2289,7 +2326,7 @@ xiekeyang Ximo Guanter Gonzálbez xin.li Xinbo Weng -Xinfeng Liu +Xinfeng Liu Xinzi Zhou Xiuming Chen Xuecong Liao @@ -2355,6 +2392,7 @@ Zen Lin(Zhinan Lin) Zhang Kun Zhang Wei Zhang Wentao +zhangguanzhang ZhangHang zhangxianwei Zhenan Ye <21551168@zju.edu.cn> @@ -2381,6 +2419,7 @@ Zuhayr Elahi Zunayed Ali Álvaro Lázaro Átila Camurça Alves +吴小白 <296015668@qq.com> 尹吉峰 屈骏 徐俊杰 diff --git a/vendor/github.com/docker/docker/pkg/homedir/homedir.go b/vendor/github.com/docker/docker/pkg/homedir/homedir.go new file mode 100644 index 000000000..590683206 --- /dev/null +++ b/vendor/github.com/docker/docker/pkg/homedir/homedir.go @@ -0,0 +1,44 @@ +package homedir + +import ( + "os" + "os/user" + "runtime" +) + +// Key returns the env var name for the user's home dir based on +// the platform being run on. +// +// Deprecated: this function is no longer used, and will be removed in the next release. +func Key() string { + return envKeyName +} + +// Get returns the home directory of the current user with the help of +// environment variables depending on the target operating system. +// Returned path should be used with "path/filepath" to form new paths. +// +// On non-Windows platforms, it falls back to nss lookups, if the home +// directory cannot be obtained from environment-variables. +// +// If linking statically with cgo enabled against glibc, ensure the +// osusergo build tag is used. +// +// If needing to do nss lookups, do not disable cgo or set osusergo. +func Get() string { + home, _ := os.UserHomeDir() + if home == "" && runtime.GOOS != "windows" { + if u, err := user.Current(); err == nil { + return u.HomeDir + } + } + return home +} + +// GetShortcutString returns the string that is shortcut to user's home directory +// in the native shell of the platform running on. +// +// Deprecated: this function is no longer used, and will be removed in the next release. +func GetShortcutString() string { + return homeShortCut +} diff --git a/vendor/github.com/docker/docker/pkg/homedir/homedir_others.go b/vendor/github.com/docker/docker/pkg/homedir/homedir_others.go index 11f1bec98..4eeb26b5d 100644 --- a/vendor/github.com/docker/docker/pkg/homedir/homedir_others.go +++ b/vendor/github.com/docker/docker/pkg/homedir/homedir_others.go @@ -1,5 +1,4 @@ //go:build !linux -// +build !linux package homedir // import "github.com/docker/docker/pkg/homedir" diff --git a/vendor/github.com/docker/docker/pkg/homedir/homedir_unix.go b/vendor/github.com/docker/docker/pkg/homedir/homedir_unix.go index d1732dee5..feae4d736 100644 --- a/vendor/github.com/docker/docker/pkg/homedir/homedir_unix.go +++ b/vendor/github.com/docker/docker/pkg/homedir/homedir_unix.go @@ -1,39 +1,8 @@ //go:build !windows -// +build !windows package homedir // import "github.com/docker/docker/pkg/homedir" -import ( - "os" - "os/user" +const ( + envKeyName = "HOME" + homeShortCut = "~" ) - -// Key returns the env var name for the user's home dir based on -// the platform being run on -func Key() string { - return "HOME" -} - -// Get returns the home directory of the current user with the help of -// environment variables depending on the target operating system. -// Returned path should be used with "path/filepath" to form new paths. -// -// If linking statically with cgo enabled against glibc, ensure the -// osusergo build tag is used. -// -// If needing to do nss lookups, do not disable cgo or set osusergo. -func Get() string { - home := os.Getenv(Key()) - if home == "" { - if u, err := user.Current(); err == nil { - return u.HomeDir - } - } - return home -} - -// GetShortcutString returns the string that is shortcut to user's home directory -// in the native shell of the platform running on. -func GetShortcutString() string { - return "~" -} diff --git a/vendor/github.com/docker/docker/pkg/homedir/homedir_windows.go b/vendor/github.com/docker/docker/pkg/homedir/homedir_windows.go index 2f81813b2..37f4ee670 100644 --- a/vendor/github.com/docker/docker/pkg/homedir/homedir_windows.go +++ b/vendor/github.com/docker/docker/pkg/homedir/homedir_windows.go @@ -1,24 +1,6 @@ package homedir // import "github.com/docker/docker/pkg/homedir" -import ( - "os" +const ( + envKeyName = "USERPROFILE" + homeShortCut = "%USERPROFILE%" // be careful while using in format functions ) - -// Key returns the env var name for the user's home dir based on -// the platform being run on -func Key() string { - return "USERPROFILE" -} - -// Get returns the home directory of the current user with the help of -// environment variables depending on the target operating system. -// Returned path should be used with "path/filepath" to form new paths. -func Get() string { - return os.Getenv(Key()) -} - -// GetShortcutString returns the string that is shortcut to user's home directory -// in the native shell of the platform running on. -func GetShortcutString() string { - return "%USERPROFILE%" // be careful while using in format functions -} diff --git a/vendor/github.com/opencontainers/image-spec/specs-go/v1/mediatype.go b/vendor/github.com/opencontainers/image-spec/specs-go/v1/mediatype.go index 892ba3de9..ce8313e79 100644 --- a/vendor/github.com/opencontainers/image-spec/specs-go/v1/mediatype.go +++ b/vendor/github.com/opencontainers/image-spec/specs-go/v1/mediatype.go @@ -21,12 +21,20 @@ const ( // MediaTypeLayoutHeader specifies the media type for the oci-layout. MediaTypeLayoutHeader = "application/vnd.oci.layout.header.v1+json" + // MediaTypeImageIndex specifies the media type for an image index. + MediaTypeImageIndex = "application/vnd.oci.image.index.v1+json" + // MediaTypeImageManifest specifies the media type for an image manifest. MediaTypeImageManifest = "application/vnd.oci.image.manifest.v1+json" - // MediaTypeImageIndex specifies the media type for an image index. - MediaTypeImageIndex = "application/vnd.oci.image.index.v1+json" + // MediaTypeImageConfig specifies the media type for the image configuration. + MediaTypeImageConfig = "application/vnd.oci.image.config.v1+json" + + // MediaTypeEmptyJSON specifies the media type for an unused blob containing the value "{}". + MediaTypeEmptyJSON = "application/vnd.oci.empty.v1+json" +) +const ( // MediaTypeImageLayer is the media type used for layers referenced by the manifest. MediaTypeImageLayer = "application/vnd.oci.image.layer.v1.tar" @@ -37,7 +45,15 @@ const ( // MediaTypeImageLayerZstd is the media type used for zstd compressed // layers referenced by the manifest. MediaTypeImageLayerZstd = "application/vnd.oci.image.layer.v1.tar+zstd" +) +// Non-distributable layer media-types. +// +// Deprecated: Non-distributable layers are deprecated, and not recommended +// for future use. Implementations SHOULD NOT produce new non-distributable +// layers. +// https://github.com/opencontainers/image-spec/pull/965 +const ( // MediaTypeImageLayerNonDistributable is the media type for layers referenced by // the manifest but with distribution restrictions. // @@ -66,10 +82,4 @@ const ( // layers. // https://github.com/opencontainers/image-spec/pull/965 MediaTypeImageLayerNonDistributableZstd = "application/vnd.oci.image.layer.nondistributable.v1.tar+zstd" - - // MediaTypeImageConfig specifies the media type for the image configuration. - MediaTypeImageConfig = "application/vnd.oci.image.config.v1+json" - - // MediaTypeEmptyJSON specifies the media type for an unused blob containing the value `{}` - MediaTypeEmptyJSON = "application/vnd.oci.empty.v1+json" ) diff --git a/vendor/github.com/opencontainers/image-spec/specs-go/version.go b/vendor/github.com/opencontainers/image-spec/specs-go/version.go index 11e09b584..6d01f6e71 100644 --- a/vendor/github.com/opencontainers/image-spec/specs-go/version.go +++ b/vendor/github.com/opencontainers/image-spec/specs-go/version.go @@ -25,7 +25,7 @@ const ( VersionPatch = 0 // VersionDev indicates development branch. Releases will be empty string. - VersionDev = "-rc.5" + VersionDev = "-rc.6" ) // Version is the specification version that the package types support. diff --git a/vendor/github.com/operator-framework/operator-registry/alpha/action/render.go b/vendor/github.com/operator-framework/operator-registry/alpha/action/render.go index 465f54db9..5dbb980cf 100644 --- a/vendor/github.com/operator-framework/operator-registry/alpha/action/render.go +++ b/vendor/github.com/operator-framework/operator-registry/alpha/action/render.go @@ -12,6 +12,7 @@ import ( "sort" "strings" "sync" + "text/template" "github.com/h2non/filetype" "github.com/h2non/filetype/matchers" @@ -39,6 +40,7 @@ const ( RefSqliteFile RefDCImage RefDCDir + RefBundleDir RefAll = 0 ) @@ -50,10 +52,11 @@ func (r RefType) Allowed(refType RefType) bool { var ErrNotAllowed = errors.New("not allowed") type Render struct { - Refs []string - Registry image.Registry - AllowedRefMask RefType - Migrate bool + Refs []string + Registry image.Registry + AllowedRefMask RefType + Migrate bool + ImageRefTemplate *template.Template skipSqliteDeprecationLog bool } @@ -125,25 +128,44 @@ func (r Render) createRegistry() (*containerdregistry.Registry, error) { } func (r Render) renderReference(ctx context.Context, ref string) (*declcfg.DeclarativeConfig, error) { - if stat, serr := os.Stat(ref); serr == nil { - if stat.IsDir() { - if !r.AllowedRefMask.Allowed(RefDCDir) { - return nil, fmt.Errorf("cannot render declarative config directory: %w", ErrNotAllowed) - } - return declcfg.LoadFS(ctx, os.DirFS(ref)) - } else { - // The only supported file type is an sqlite DB file, - // since declarative configs will be in a directory. - if err := checkDBFile(ref); err != nil { - return nil, err - } - if !r.AllowedRefMask.Allowed(RefSqliteFile) { - return nil, fmt.Errorf("cannot render sqlite file: %w", ErrNotAllowed) + stat, err := os.Stat(ref) + if err != nil { + return r.imageToDeclcfg(ctx, ref) + } + if stat.IsDir() { + dirEntries, err := os.ReadDir(ref) + if err != nil { + return nil, err + } + if isBundle(dirEntries) { + // Looks like a bundle directory + if !r.AllowedRefMask.Allowed(RefBundleDir) { + return nil, fmt.Errorf("cannot render bundle directory %q: %w", ref, ErrNotAllowed) } - return sqliteToDeclcfg(ctx, ref) + return r.renderBundleDirectory(ref) } + + // Otherwise, assume it is a declarative config root directory. + if !r.AllowedRefMask.Allowed(RefDCDir) { + return nil, fmt.Errorf("cannot render declarative config directory: %w", ErrNotAllowed) + } + return declcfg.LoadFS(ctx, os.DirFS(ref)) + } + // The only supported file type is an sqlite DB file, + // since declarative configs will be in a directory. + if err := checkDBFile(ref); err != nil { + return nil, err + } + if !r.AllowedRefMask.Allowed(RefSqliteFile) { + return nil, fmt.Errorf("cannot render sqlite file: %w", ErrNotAllowed) + } + + db, err := sqlite.Open(ref) + if err != nil { + return nil, err } - return r.imageToDeclcfg(ctx, ref) + defer db.Close() + return sqliteToDeclcfg(ctx, db) } func (r Render) imageToDeclcfg(ctx context.Context, imageRef string) (*declcfg.DeclarativeConfig, error) { @@ -169,7 +191,12 @@ func (r Render) imageToDeclcfg(ctx context.Context, imageRef string) (*declcfg.D if !r.AllowedRefMask.Allowed(RefSqliteImage) { return nil, fmt.Errorf("cannot render sqlite image: %w", ErrNotAllowed) } - cfg, err = sqliteToDeclcfg(ctx, filepath.Join(tmpDir, dbFile)) + db, err := sqlite.Open(filepath.Join(tmpDir, dbFile)) + if err != nil { + return nil, err + } + defer db.Close() + cfg, err = sqliteToDeclcfg(ctx, db) if err != nil { return nil, err } @@ -190,10 +217,11 @@ func (r Render) imageToDeclcfg(ctx context.Context, imageRef string) (*declcfg.D return nil, err } - cfg, err = bundleToDeclcfg(img.Bundle) + bundle, err := bundleToDeclcfg(img.Bundle) if err != nil { return nil, err } + cfg = &declcfg.DeclarativeConfig{Bundles: []declcfg.Bundle{*bundle}} } else { labelKeys := sets.StringKeySet(labels) labelVals := []string{} @@ -221,17 +249,11 @@ func checkDBFile(ref string) error { return nil } -func sqliteToDeclcfg(ctx context.Context, dbFile string) (*declcfg.DeclarativeConfig, error) { +func sqliteToDeclcfg(ctx context.Context, db *sql.DB) (*declcfg.DeclarativeConfig, error) { logDeprecationMessage.Do(func() { sqlite.LogSqliteDeprecation() }) - db, err := sqlite.Open(dbFile) - if err != nil { - return nil, err - } - defer db.Close() - migrator, err := sqlite.NewSQLLiteMigrator(db) if err != nil { return nil, err @@ -303,7 +325,7 @@ func populateDBRelatedImages(ctx context.Context, cfg *declcfg.DeclarativeConfig return nil } -func bundleToDeclcfg(bundle *registry.Bundle) (*declcfg.DeclarativeConfig, error) { +func bundleToDeclcfg(bundle *registry.Bundle) (*declcfg.Bundle, error) { objs, props, err := registry.ObjectsAndPropertiesFromBundle(bundle) if err != nil { return nil, fmt.Errorf("get properties for bundle %q: %v", bundle.Name, err) @@ -323,7 +345,7 @@ func bundleToDeclcfg(bundle *registry.Bundle) (*declcfg.DeclarativeConfig, error } } - dBundle := declcfg.Bundle{ + return &declcfg.Bundle{ Schema: "olm.bundle", Name: bundle.Name, Package: bundle.Package, @@ -332,9 +354,7 @@ func bundleToDeclcfg(bundle *registry.Bundle) (*declcfg.DeclarativeConfig, error RelatedImages: relatedImages, Objects: objs, CsvJSON: string(csvJson), - } - - return &declcfg.DeclarativeConfig{Bundles: []declcfg.Bundle{dBundle}}, nil + }, nil } func getRelatedImages(b *registry.Bundle) ([]declcfg.RelatedImage, error) { @@ -363,7 +383,7 @@ func getRelatedImages(b *registry.Bundle) ([]declcfg.RelatedImage, error) { allImages = allImages.Insert(ri.Image) } - if !allImages.Has(b.BundleImage) { + if b.BundleImage != "" && !allImages.Has(b.BundleImage) { relatedImages = append(relatedImages, declcfg.RelatedImage{ Image: b.BundleImage, }) @@ -454,3 +474,72 @@ func combineConfigs(cfgs []declcfg.DeclarativeConfig) *declcfg.DeclarativeConfig } return out } + +func isBundle(entries []os.DirEntry) bool { + foundManifests := false + foundMetadata := false + for _, e := range entries { + if e.IsDir() { + switch e.Name() { + case "manifests": + foundManifests = true + case "metadata": + foundMetadata = true + } + } + if foundMetadata && foundManifests { + return true + } + } + return false +} + +type imageReferenceTemplateData struct { + Package string + Name string + Version string +} + +func (r *Render) renderBundleDirectory(ref string) (*declcfg.DeclarativeConfig, error) { + img, err := registry.NewImageInput(image.SimpleReference(""), ref) + if err != nil { + return nil, err + } + if err := r.templateBundleImageRef(img.Bundle); err != nil { + return nil, fmt.Errorf("failed templating image reference from bundle for %q: %v", ref, err) + } + fbcBundle, err := bundleToDeclcfg(img.Bundle) + if err != nil { + return nil, err + } + return &declcfg.DeclarativeConfig{Bundles: []declcfg.Bundle{*fbcBundle}}, nil +} + +func (r *Render) templateBundleImageRef(bundle *registry.Bundle) error { + if r.ImageRefTemplate == nil { + return nil + } + + var pkgProp property.Package + for _, p := range bundle.Properties { + if p.Type != property.TypePackage { + continue + } + if err := json.Unmarshal(p.Value, &pkgProp); err != nil { + return err + } + break + } + + var buf strings.Builder + tmplInput := imageReferenceTemplateData{ + Package: bundle.Package, + Name: bundle.Name, + Version: pkgProp.Version, + } + if err := r.ImageRefTemplate.Execute(&buf, tmplInput); err != nil { + return err + } + bundle.BundleImage = buf.String() + return nil +} diff --git a/vendor/modules.txt b/vendor/modules.txt index 688e3c1dc..121b18539 100644 --- a/vendor/modules.txt +++ b/vendor/modules.txt @@ -192,7 +192,7 @@ github.com/davecgh/go-spew/spew # github.com/distribution/reference v0.5.0 ## explicit; go 1.20 github.com/distribution/reference -# github.com/docker/cli v24.0.7+incompatible +# github.com/docker/cli v25.0.5+incompatible ## explicit github.com/docker/cli/cli/config github.com/docker/cli/cli/config/configfile @@ -203,7 +203,7 @@ github.com/docker/cli/cli/config/types github.com/docker/distribution/registry/api/errcode github.com/docker/distribution/registry/api/v2 github.com/docker/distribution/registry/client/auth/challenge -# github.com/docker/docker v24.0.7+incompatible +# github.com/docker/docker v25.0.5+incompatible ## explicit github.com/docker/docker/api/types/versions github.com/docker/docker/pkg/homedir @@ -434,7 +434,7 @@ github.com/onsi/gomega/types # github.com/opencontainers/go-digest v1.0.0 ## explicit; go 1.13 github.com/opencontainers/go-digest -# github.com/opencontainers/image-spec v1.1.0-rc5 +# github.com/opencontainers/image-spec v1.1.0-rc6 ## explicit; go 1.18 github.com/opencontainers/image-spec/specs-go github.com/opencontainers/image-spec/specs-go/v1 @@ -467,8 +467,8 @@ github.com/operator-framework/deppy/pkg/deppy github.com/operator-framework/deppy/pkg/deppy/constraint github.com/operator-framework/deppy/pkg/deppy/input github.com/operator-framework/deppy/pkg/deppy/solver -# github.com/operator-framework/operator-registry v1.36.0 -## explicit; go 1.20 +# github.com/operator-framework/operator-registry v1.37.0 +## explicit; go 1.21 github.com/operator-framework/operator-registry/alpha/action github.com/operator-framework/operator-registry/alpha/declcfg github.com/operator-framework/operator-registry/alpha/model @@ -485,7 +485,7 @@ github.com/operator-framework/operator-registry/pkg/prettyunmarshaler github.com/operator-framework/operator-registry/pkg/registry github.com/operator-framework/operator-registry/pkg/sqlite github.com/operator-framework/operator-registry/pkg/sqlite/migrations -# github.com/operator-framework/rukpak v0.18.1 => github.com/openshift/operator-framework-rukpak v0.0.0-20240308020514-7589a1f04ea1 +# github.com/operator-framework/rukpak v0.18.1 => github.com/openshift/operator-framework-rukpak v0.0.0-20240326115409-bf49b7249b21 ## explicit; go 1.21 github.com/operator-framework/rukpak/api/v1alpha2 # github.com/otiai10/copy v1.14.0 @@ -546,7 +546,7 @@ github.com/ulikunitz/xz/lzma github.com/vbatts/tar-split/archive/tar github.com/vbatts/tar-split/tar/asm github.com/vbatts/tar-split/tar/storage -# github.com/vmware-tanzu/carvel-kapp-controller v0.50.0 +# github.com/vmware-tanzu/carvel-kapp-controller v0.50.2 ## explicit; go 1.21 github.com/vmware-tanzu/carvel-kapp-controller/pkg/apis/kappctrl/v1alpha1 # github.com/vmware-tanzu/carvel-vendir v0.36.0 @@ -1269,5 +1269,5 @@ sigs.k8s.io/structured-merge-diff/v4/value ## explicit; go 1.12 sigs.k8s.io/yaml sigs.k8s.io/yaml/goyaml.v2 -# github.com/operator-framework/rukpak => github.com/openshift/operator-framework-rukpak v0.0.0-20240308020514-7589a1f04ea1 +# github.com/operator-framework/rukpak => github.com/openshift/operator-framework-rukpak v0.0.0-20240326115409-bf49b7249b21 # github.com/operator-framework/catalogd => github.com/openshift/operator-framework-catalogd v0.0.0-20240221182512-9666df2685f2