search

operator-framework / enhancements

Apache License 2.0
9 stars 40 forks source link

OLM V1 Milestone 2 #121

Open awgreene opened 1 year ago

awgreene commented 1 year ago

Goals:

Suggested Milestone Stories:

Current prioritized list of reviewed suggestions: When reviewing the suggestions, the upstream community has decided that the suggestions should be priortized in the following order (missing suggestions have not yet been reviewed).

  1. Define the distribution process early on.
  2. Define the DeppySource API, move Deppy's hard coded reliance on the registry v1 client into a deppySource adaptor for registryv1 catalogsources, and create a proof of concept for the next generation catalog source API.
  3. Expand the Operator CRD's Spec to support more constraints. Some acceptance criteria may include: -- Defining how constraints are defined in the Operator CR Spec. --- Could a user learn about supported constraints with kubeclt explain? --- A GH Issue is created to discuss Generic Constraints and is added to the GA milestone. --- The community recommends that we avoid a fully generic template as it may be difficult to use. -- Channel: Users may specify a channel that the bundle MUST come from -- Version Range: Users may supply a range OR a specific version that a bundle must satisfy. -- Update kubectl operator plugin to allow users to specify new constraints.
  4. OLM v1 respects upgrade edges defined by operator authors.
  5. Lead discussion on what it means to "force install" an operator. -- Consider different user personas: Super Cluster Admin comfortable with deploying bundleDeployments, Cluster Admin relying on OLM V1 APIs -- What are all the "force install" scenarios? Are different "knobs" required for different "forced installs"?
  6. If dependencies are enabled, allow users to "ignore" dependencies when installing an operator. (It does not make sense to include this in a milestone until we support dependencies).
  7. Support direct bundle image references in the Operator API. -- How does this work with Operator CRs that introduce constraints.
  8. Support cluster constraints provided by Bundles -- This would likely require use of a DeppySource other than OLMv0 CatalogSources (e.g. a "cluster" entity that provides cluster version properties to the resolver)
joelanford commented 1 year ago

some e2e experience

Coming up with this is step 1 for defining a milestone I think. My feeling is that the focus could be on some of the following:

This list is probably too big for everything to be in the milestone, but IMO, these are the next logical steps.

joelanford commented 1 year ago

Another item that I think should be part of Milestone 2 is a centralized upstream OLMv1 distribution, which would:

  1. Pin to specific component versions: rukpak and operator controller (deppy is currently embedded as a library in the operator controller)
  2. Provide a simple installation experience
  3. Include tests that prove the component versions are compatible.
  4. Nice-to-have/follow-on: when an individual component PR is submitted run the distribution e2e with a build of that component from the PR, keeping the other components pinned.
awgreene commented 1 year ago

Milestone 1 will introduce rudimentary install and uninstall commands to the kubectl operator plugin, it may make sense to begin adding more of the features described in the OLM V1 UX doc in Milestone 2 or a subsequent milestone.

perdasilva commented 1 year ago

Once we are finished with M1 we should look at the deppy framework for bottlenecks (especially with the design). We should make a decision as to whether it is worth to switch to a generics-based framework.

The other thing we should consider are the resolution pipelines. Putting that framework in deppy.

dmesser commented 1 year ago

I vote, like @joelanford , to focus on basic upgrade functionality - learn how to pivot from one version to another. Potentially already taking steps for OLM to auto-choose a default path when multiple update options exist but at the same time allow the user to specify a desired target version that may not be the latest. This will likely require more work on the resolution framework. While we are at it, we can also expand that framework to start resolving constraints against cluster properties or other extensions.

awgreene commented 1 year ago
  1. Pin in to specific component versions: rukpak and operator controller (deppy is currently embedded as a library in the operator controller)

@joelanford is this speaking about:

We reviewed this in the community meeting and suspect it's the former, but wanted to confirm.

joelanford commented 1 year ago

Essentially, I'm suggesting that we need some way of mapping an OLMv1 version to a set of versions of all of the components such that anyone could:

  1. Run an install script for OLMv1 that would install all of the right sub-components
  2. Parse the mapping and substitute their own versions of subcomponenets. This would be useful for subcomponent CI

For example, would the github.com/operator-framework/operator-lifecycle-manager@v1.0.0-alpha1 tag contain a file like this:

subcomponents:
  - name: operator-controller
    repo: github.com/operator-framework/operator-controller
    commit: 47485a7e8e678ff7f922321d014e8ae1adeef352
  - name: rukpak
    repo: github.com/operator-framework/rukpak
    commit: c527e657b4dabfd228068fbe458b72acb013bf00

This is totally made up and I haven't thought too much about what sort of metadata we would need (name, repo, commit are just thrown out there without much thought).

But the overall point is: How do we define this mapping such that we can deterministically install a particular distribution of OLM at a particular version of that distribution? And how can we make it easy to sub in something else?