Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add documentation on installing custom images #67

Conversation

ChristianZaccaria
Copy link
Contributor

@ChristianZaccaria ChristianZaccaria commented Jul 25, 2023

Closes #68

Description

  • Added documentation to the Quick-Start on how to install custom images of MCAD and/or InstaScale to your OpenShift or Kubernetes cluster.
  • Provided commands which may be used to efficiently replace the controllerImage value in a CRD to the path to the custom image.

How Has This Been Tested?

Commands tested on OpenShift OSD cluster.

Merge criteria:

  • The commits are squashed in a cohesive manner and have meaningful messages.
  • Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
  • The developer has manually tested the changes and verified that the changes work

Additional Notes:

I added this documentation in this repository as it can then be added in the CodeFlare-Operator wiki. Opened to thoughts on this?

@@ -78,6 +78,20 @@ At this point you should be able to go to your notebook spawner page and select

You can access the spawner page through the Open Data Hub dashboard. The default route should be `https://odh-dashboard-<your ODH namespace>.apps.<your cluster's uri>`. Once you are on your dashboard, you can select "Launch application" on the Jupyter application. This will take you to your notebook spawner page.

### [Optional] - Install custom images of MCAD and/or InstaScale
After adding the MCAD and InstaScale objects, the simplest way to update their versions is by replacing the `controllerImage` value in their Custom Resource Definitions (CRDs) with the path to your custom image. This image might be stored in a registry, such as quay.io. To help you build and push your custom image to a registry, both the [MCAD](https://github.com/project-codeflare/multi-cluster-app-dispatcher) and [InstaScale](https://github.com/project-codeflare/instascale) repositories provide `make` commands to achieve this.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These commands would be overwritten by the kfdef as the operator would reconcile the changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made a mistake there, I meant to say to replace the value in the InstaScale CR as opposed to the CRD.

Wouldn't adding the controllerImage field and specifying the value in the InstaScale CR, set a new desired state? What do you think?

controllerImage in CRD

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the issue is that the odh operator is managing the instascale CR. Any changes you make to the instascale cr will be overwritten by the ODH operator. Can you sync up with Dimitri tomorrow? He should be able to explain in better detail (or I can once I'm on)

@astefanutti
Copy link
Contributor

Summarising the discussion @ChristianZaccaria and I just had:

The Problem:

  1. It is expected the ODH operator overwrites local changes made to resources it manages. Yet, it may not be the observed behaviour, in which case it's then an incorrect one. On the other hand, it's unlikely the ODH operator will introduce a mechanism to handle conflicting changes gracefully.

  2. It means any changes have to be made to the source of truth, which is:

    • A tarball containing a snapshot of the odh-manifests repository in case of the ODH operator v1,
    • Or a checkout of the odh-manifests repository, packaged within the ODH operator v2 container image
  3. In both cases, it makes it very difficult / almost impossible for users to apply their changes.

  4. The root cause of this issue lies in having configuration mixed with specification, i.e., the MCAD and InstaScale resources, which are configuration, are packaged along with the deployment manifests.

Solutions:

  1. One option would be to remove these resources from the CodeFlare ODH manifests, but that'll mandate users to create them manually, or to update the CodeFlare operator to initialise them.

  2. On the other hand, configuration of the CodeFlare operator will drastically change in case Introduce ADR for CodeFlare operator redesign project-codeflare/adr#9 is accepted, so another option would be to wait for the conclusion of this ADR first, and fall back to option 1) if it's rejected.

@astefanutti
Copy link
Contributor

I think this has become obsolete with the operator redesign and can be closed.

@openshift-merge-robot
Copy link

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Doc: CodeFlare Operator with custom MCAD and Instascale images
4 participants