integrate semi-complex ODH demo into MOC

[Gkrumbach07]

Is your feature request related to a problem? Please describe. No

Describe the solution you'd like I would like to integrate my tutorial/demo which uses ODH into the MOC. This demo is different because it also relies on deployed model services that live outside of ODH.

• https://github.com/Gkrumbach07/docker-py-kaldi-asr
• https://github.com/Gkrumbach07/call_center_manage

Additional context The goal of this demo would be to allow the ODH community to experiment with using Kafka in a kappa architecture. It would also show how you could use this type of architecture to facilitate model services, both complex and simple. It is all wrapped up as a use case and utilizes a web app to display results.

My main issue is how this demo could be integrated into MOC, because it requires extra deployments beyond a traditional Jupyter notebook. The deployments that need to be on MOC are as follows:

• Kafka
• Flask API
• Python script (running and repeating as a service)
• Jupyter notebook (acting as a model service)
• Node deployments (backend/frontend web app)

cc @goern @erikerlandson

[HumairAK]

Hello @Gkrumbach07 !

That sounds neat. So out of your list of deployments we have:

• JupyterHub deployed by ODH. This will give you access to Jupyter Notebooks.

  You can already access it by visiting this link and logging in using the SSO (any gmail account should work). Logging in will also auto create a user for you on our MOC zero cluster.

  Adding your own notebook image can be done by following the docs here. This will allow you to select your own custom image from the spawner.

• Kafka deployed by ODH. We can add topics you require, and provide you with the appropriate certs/routes. If you need a dedicated Kafka instance for your own openshift namespace then, we can accommodate this as well. We're not super savvy with Kafka, so we welcome your expertise and feedback in this area.

For everything else, I'm assuming you will need your own openshift namespace where you would like to deploy these apps to. I see you tagged @goern and @erikerlandson so maybe they can confirm. If this is the case we'll need:

• Your MOC zero cluster username (this is obtained by logging in via SSO here, your user will be auto created). You can DM us this value as it will be your e-mail.
• Your team/project name (this can be anything name that we can use to organize resources/users/permissions under your project).
• Your openshift namespace name preference

[erikerlandson]

@HumairAK one question I had for the op1st team was: do we want this demo to be running "always", or to be able to spin up all the components on demand for a user. In theory one might get an on-demand deployment by a properly designed singleuser-profile. running the components in their own namespace has advantages but it is less obvious to me how we could get an on-demand spin-up

[erikerlandson]

cross-referencing #107

[HumairAK]

@erikerlandson do you mean like, a custom image that you can select from the spawner? This is something we also support, I've updated my comment to include a link to instructions on how this can be done. But as @tumido has mentioned in that issue you linked, if there are additional requirements like openshift routes/services etc. We try to encourage using your own namespaces so that the opf-* namespaces don't get over-crowded.

[Gkrumbach07]

Notebook image created: Two new Kafka topics: https://github.com/operate-first/apps/pull/527 Adding notebook image to MOC: https://github.com/operate-first/apps/pull/528

Would this demo / use-case live somewhere on Operate First (https://www.operate-first.cloud/data-science/) or would it be best placed somewhere else?

[HumairAK]

In general users keep their demos/application code in a separate git repository, and we house only privileged resource manifests (for deploying the app) in the operate-first org (e.g. cluster resources, some rbac, argocd manifests, etc.). Personally I would prefer to keep it that way.

@tumido @durandom

[Gkrumbach07]

@HumairAK I agree. My application code is sourced from my personal repositories and is deployed on a namespace in MOC. Any and all interactions are done through Kafka via this Jupyter notebook image. And all Documentation and demo instruction will be sourced from the same repo that has the Jupyter notebook. This would be similar in what @erikerlandson did for his Ray demo.

That was what I had in mind. If this demo does not fit in here well, then that is okay too.

[HumairAK]

Maybe I misunderstood -- are we talking about keeping the application demo deployed on the MOC Zero cluster and linking to it via the website, like the section you linked? I think this is something we can (and probably should) do :)

[Gkrumbach07]

Yes, that is what I was thinking. There are a few questions I had in how this app demo would differ from the conventional. Ideally I would want each new user to get a fresh build of the demo to play with. This would better showcase the point of the demo (which is using cookies to manage user sessions)(you can watch my demo if you want more context).

However, giving read access for the namespace to the user also works but opens up an issue that may or may not be a problem. For the demo to have data to work with (in the notebook image), a container on the namespace needs to be producing simulated data (constantly running with multiple pods). I am not sure if you want this happing constantly (a constant stream of Kafka data) or only when a user is interacting with the demo.

Also the notebook image uses Kafka without an any ssl certs so that needs to be dealt with I am guessing. What would I need to change in the notebook image to comply with this. Reference: https://github.com/operate-first/apps/issues/482.

[HumairAK]

Ideally I would want each new user to get a fresh build of the demo to play with

Hrm can you elaborate what it looks like for each user to get a fresh build?

However, giving read access for the namespace to the user also works

You can do this yourself for your namespace by creating a rolebinding like:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: project-reader
  namespace: fde-audio-decoder-demo
subjects:
  - kind: Group
    apiGroup: rbac.authorization.k8s.io
    name: 'system:authenticated'
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: project-reader

Then create a role called project-reader with the resources you want them to be able to get, list, watch etc.

I am not sure if you want this happing constantly (a constant stream of Kafka data) or only when a user is interacting with the demo.

That shouldn't be an issue, as long as the Kafka topic retention is reasonably small (afaik yours is fine).

Also the notebook image uses Kafka without an any ssl certs so that needs to be dealt with I am guessing. What would I need to change in the notebook image to comply with this.

Going to yield to @4n4nd for this, since he's working on Kafka auth.

[4n4nd]

Also the notebook image uses Kafka without an any ssl certs so that needs to be dealt with I am guessing. What would I need to change in the notebook image to comply with this.

I would say keeping using the internal route for now, but hopefully in the next week or two I will be able to create "readonly" certs and a couple of public topics accessible by anyone.

[tumido]

@HumairAK @Gkrumbach07

However, giving read access for the namespace to the user also works

You can do this yourself for your namespace by creating a rolebinding like: ... Then create a role called project-reader with the resources you want them to be able to get, list, watch etc.

Let's keep it simple. This single line enables you to expose the namespace publicly for everybody with view/read access:

https://github.com/operate-first/apps/blob/e0597cc699094a922a72f480787e031d1cb312c0/cluster-scope/base/namespaces/lab-cicd-2-jump-app-cicd/kustomization.yaml#L12

No need to create custom roles and rolebindings

[HumairAK]

Forgot about that, thanks! @Gkrumbach07 - if you add the same line as indicated above to this file then it will allow the namespace to be viewable by any logged in user.

[Gkrumbach07]

Hrm can you elaborate what it looks like for each user to get a fresh build?

When I say fresh build, I mean having a temporary namespace (with my demo installed) for a user to interact with. I guess the only need for a "fresh build" would be to increase and decrease pod counts for the simulator. I can defiantly rework the demo a bit so that only readonly access is needed. So disregard the requirement for a "fresh build"

Let's keep it simple. This single line enables you to expose the namespace publicly for everybody with view/read access:

Awesome, I will make made a pull request for that small change: https://github.com/operate-first/apps/pull/540

I will continue to build up the demo instructions and will create a pr to have it added to Operate First by "linking to it via the website". Under which tab in the Operate First website would this demo most likely be?

[HumairAK]

I will continue to build up the demo instructions and will create a pr to have it added to Operate First by "linking to it via the website". Under which tab in the Operate First website would this demo most likely be?

Great! There are instructions here on how you can add links (in the readme)

As for where to put this, I think under Data Science Projects makes the most sense to me.

But I'll wait for confirmation from @oindrillac @MichaelClifford

[MichaelClifford]

I agree with @HumairAK I think the Data Science Projects tab is best for this type of work.