Enable this stack to be created in any region, not just US-EAST-1. AWS users will likely want to create stacks in a region of their choice.

Add deployment script for CKF-COS that uses the Grafana agent. As outlined in this doc: https://discourse.charmhub.io/t/how-to-integrate-charmed-kubeflow-with-the-canonical-observability-stack-cos/11927.

Why it needs to get done

We need to access the Kubeflow dashboard from outside of EC2 instance even when the instance is restarted or the IP is changed. We also want to access the dashboard without changing the security group after we deploy cloud formation template. One way is to create Elastic IP and associate it with the EC2 instance https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html

What needs to get done

With cloud formation:

• create elastic ip address
• associate the ip with the ec2 instance
• make sure we can access the dashboard

When is the task considered done

After deployment of the appliance we can access the dashboard on IP addresss without the need to change the security group or the need of SOCKS proxy.

Amazon manages a tool called taskcat which tests cloudformation templates. This should be integrated into github actions as a way to validate the latest CFT prior to requesting marketplace entry updates.

Right now the NVIDIA GPU Operator is not enabled in MicroK8s. This means the K8s will not utilise a GPU even if one is present on the machine.

Let's aim to either

• Provide users a way to toggle the NVIDIA Operator
• Have it on all the time, if it can work even if no GPU is currently available

The goal is for users to be able to use the appliance with a GPU

Add a template that deploys both Kubeflow and COS and integrates the two.

Why it needs to get done

We need a spec with details on how to remove socks proxy from appliance setup.

What needs to get done

Write a spec explaining how to connect to kubeflow in EC2 instance microk8s without the need of SOCKs proxy. MOre details:

• Research how to maintain a static IP address for the deployment (load balancer?)
• Research how the public-url will behave with non-metallb IP address
• Research whether the loadbalancer service in microk8s can be set to AWS loadbalancer instead of metallb

When is the task considered done

Spec is written.

Same issue as reported on Launchpad. The CloudFormation template does not pin Juju version. So now it is getting Juju 3.x. All Juju commands fail with this error:

ERROR cannot load ssh client keys: mkdir /home/ubuntu/.local: permission denied

Workaround is to create this directory:

mkdir -p ~/.local/share

However, by the time the directory is created, Juju is working, but the CloudFormation script has failed to launch Kubeflow.

Juju version at the time of writing this bug:

juju version
3.1.5-genericlinux-amd64

Proposed fix: pin Juju to 2.9 - presumably this was the intended version for the CloudFormation template when it was created.

Why it needs to get done

We need to access the Istio Ingressgateway service on ip:port of the ec2 instance so we don't need to use SOCKs proxy.

What needs to get done

• Enable ingress microk8s addon https://microk8s.io/docs/addon-ingress.
• Create an ingress object for the Istio Ingressgateway service.
• Change the public-url setting in dex accordingly.

NOTE: in this case we need to enable port 80 in security group so we can access it on EC2.

When is the task considered done

User can access the dashboard on http://{ec2-intance-ip}:80

Today, if you want to create 2 stacks simultaneously using this template, the first succeeds but the second one fails because resource names are not unique. Resource name uniqueness uses the stack name and the AppName.

Proposed fix: use only the stack name for resource uniqueness, so that if someone creates two different stacks with two different names, then they will both succeed in their creation.