We might consider having pre-alpha/alpha/beta/stable channels.

[sthaha]

We might consider having pre-alpha/alpha/beta/stable channels.

[sthaha]

@sunya-ch could you please expand this further?

We can definitely create pre-alpha, beta, stable channels but I see the following issues.

1. Users will have to opt into the pre-alpha and can't have a stable kepler deployment while being able to playaround with the experimental part at the same time.
2. Releases to the community-operator isn't going to be simple. I.e. We will have to maintain atleast 2 different releases of kepler-operator to community-catalog with each channel providing a different set of API making the upgrade from one to the other hard if not impossible because of the CRD differences.

The idea of both Kepler and KeplerExperiment CRD is that you can have both kepler (the stable part) and kepler-experiment deployed to the same cluster and each working independently.

The experiment can provide API such as:

spec: 
  exporter: 
     deployment:
         image: 
         port: 
  modelserver: 
    deployment:
      image:

which will never be part of the kepler API spec

[sunya-ch]

Thank you for the discussion post.

1. I don't think we should deploy two Kepler CR on the same cluster at the same time. We might have multiple Kepler with different node selector; however, that would be the case that we have a different configuration such as model for different CPU architecture. For example, why I need the Kepler CR when I can deploy everything by KeplerExperiment.
   If I were user with need of a stable Kepler CR, I just deploy Kepler operator from the stable channel.

2. API can change but of course not often. We just need to make sure the transition process. Also, if it cannot automatically upgrade, the operator cycle will just show warning that cannot upgrade and admin can uninstall and re-install if they want a new version. Kepler daemon is resilient enough to be deleted and redeployed.

In my opinion, we may newly define KeplerExperiment only for the configuration that we never allow it on production such as changing deployment image or pull policy.

However, for the feature that we consider to be user choice such as deployment choice to have model server / estimator sidecar or not, to expose all metrics or some metrics or not depends on overhead tradeoff. It should be added to Kepler CR.

Instead of complicating migration from these features to the Kepler CR, I think we should define a development cycle like what changes on API we are going to have on next major release on each channel (might have only alpha and stable).

[husky-parul]

I don't think we should deploy two Kepler CR on the same cluster at the same time. We might have multiple Kepler with different node selector; however, that would be the case that we have a different configuration such as model for different CPU architecture. For example, why I need the Kepler CR when I can deploy everything by KeplerExperiment.
If I were user with need of a stable Kepler CR, I just deploy Kepler operator from the stable channel.

This is to address the use case where a user already have Kepler CR deployed on their cluster but the user wants to play around with the new upcoming features in KeplerExperiment. To be clear there won't be 2 Kepler CR. There is a CR corresponding to Kepler stable API and the other one is KeplerExperiment CR.

Instead of complicating migration from these features to the Kepler CR, I think we should define a development cycle like what changes on API we are going to have on next major release on each channel (might have only alpha and stable).

+1 on this but @sthaha made a point about maintaining two releases for community operator in the comments above (also quoted below)

Releases to the community-operator isn't going to be simple. I.e. We will have to maintain atleast 2 different releases of kepler-operator to community-catalog with each channel providing a different set of API making the upgrade from one to the other hard if not impossible because of the CRD differences.

@sthaha can throw more light on how KeplerExperiment helps in easy on boarding of new contributors/developers

[sthaha]

@sthaha can throw more light on how KeplerExperiment helps in easy on boarding of new contributors/developers

The idea is quite simple :-) .
Most features that are straight forward, like setting a resource limits on kepler pods etc can / will be added directly to kepler crd.
However, there are at least 2 cases where the Experimental API is useful

1. Features that will never get into the stable api - Kepler . E.g.
   • `spec.exporter.deployment.image = "/my-kepler.img"
2. Feature that need more inputs from real-world usage like the model-server PR where a lot of things are still undecided.

Experimental Api provides a lower barrier to entry because we can accept any changes to the spec. For instance the model-server feature can be readily added to experimental API. This allows users and devs to experiment with the API, learn from it and move the parts that are stable (no change in spec) to kepler crd itself.

At this point,I am considering that we will ship both Kepler and KeplerExperiment CRD in the olm bundle as well

[sthaha]

Closing this in favour of #304