Support Pod Defaults in Tensorboard Web App

[surajkota]

Description of Changes

Add functionality to configure PodDefaults in the Tensorboard UI which allows users to configure tensorboard instance for using object store(e.g. endpoint, region in case of AWS S3), different service account etc.. This completes the feature requested in #6493. This is a follow up PR of #6874 and hence it will be great to merge it soon so it can be made available as part of 1.7 release. #6672

See user experience section for sample

Frontend changes:

• Added the configurations component to the form as a checklist with multiple selection (similar to Jupyter webapp)
• Populated the configurations list with poddefaults available in the namespace
• Send the labels selected by user onSubmit/tensorboard instance creation

Backend changes:

• Added a route to fetch poddefaults
• Parse and add the labels to the tensorboard CR
• Fixed a bug where body was not printing in logs

Manifest changes:

• Added permissions for the webapp to list and get pod defaults

Testing

Tested using sample tensorboard event generated from - https://www.tensorflow.org/tensorboard/get_started#using_tensorboard_with_keras_modelfit and steps as described in user experience section below

Built an image using Make command to test the changes

Notes to reviewer

How is this file used? - components/crud-web-apps/tensorboards/deploy/app-rbac.yaml

User Experience - use AWS S3 as object store to visualize events in Tensorboard

1. Choose a service account which has access to S3 bucket with data. The following example uses default-editor as the service account. (Tensorboard controller creates instances using default service account by default). You can also use secrets but this example uses IAM role for Service Account

Following command adds S3 permissions to default-editor service account

# export cluster and profile variables

export CLUSTER_NAME=<my-cluster>
export CLUSTER_REGION=<my-cluster-region>
export PROFILE_NAMESPACE=kubeflow-user-example-com

# add S3 permissions to service account
eksctl create iamserviceaccount --cluster=$CLUSTER_NAME --name default-editor --namespace $PROFILE_NAMESPACE --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess --region $CLUSTER_REGION --override-existing-serviceaccounts --approve

2. Create a PodDefault with configurations for the S3 bucket where data is located and the service account to use

cat <<EOF > tb_s3_poddefault.yaml
apiVersion: kubeflow.org/v1alpha1
kind: PodDefault
metadata:
  name: tensorboard-s3-config
spec:
  desc: S3 config for us-west-2 region
  selector:
    matchLabels:
      tb-s3-config: "true"
  env:
    - name: AWS_REGION
      value: us-west-2
  serviceAccountName: default-editor
EOF

kubectl apply -f tb_s3_poddefault.yaml -n $PROFILE_NAMESPACE

3. Headover to the tensorboard UI and use an AWS S3 as object store location and select the Configuration you just created while creating a new tensorboard instance

4. Click the connect button once the tensorboard instance is ready

[surajkota]

@kimwnasptd Please take a look

[orfeas-k]

Hi @surajkota, thank you for the PR. I 'm also working on KF's web apps and @kimwnasptd informed me about your PR. I 'd be happy to take a look at this and review this so I 'll start right away. I had also worked with Pod Defaults when creating the Notebook details page in JWA.

[surajkota]

Thanks @orfeas-k, please take a look when you get a chance

[orfeas-k]

Hey sorry for the delay @surajkota. The PR looks great.

As a general comment, I noticed that you followed what we do in JWA for poddefaults which is great, since this is code that has been tested and we know it works. However, I think it is always a great practice to avoid maintaining the same code twice. For this reason, I suggest the following changes:

• Create a lib-form-configurations component in Kubeflow's common library and put this to use both in TWA and JWA
• Create a parser/poddefaults.py file in the common code and put there a function that parses the PodDefaults and that both TWA and JWA will use.

Also, nit but I think renaming the PR to twa: Support Pod Defaults would make it more easy to navigate to inside the repo's commits.

I 'll let @kimwnasptd comment on the changes regarding rbac, since he has a greater overview of how they work.

[orfeas-k]

Suggested change

	return cr_labels
	return cr_labels

[orfeas-k]

Suggested change

	}
	}

[surajkota]

Hey sorry for the delay @surajkota. The PR looks great.

As a general comment, I noticed that you followed what we do in JWA for poddefaults which is great, since this is code that has been tested and we know it works. However, I think it is always a great practice to avoid maintaining the same code twice. For this reason, I suggest the following changes:

• Create a lib-form-configurations component in Kubeflow's common library and put this to use both in TWA and JWA
• Create a parser/poddefaults.py file in the common code and put there a function that parses the PodDefaults and that both TWA and JWA will use.

Also, nit but I think renaming the PR to twa: Support Pod Defaults would make it more easy to navigate to inside the repo's commits.

I 'll let @kimwnasptd comment on the changes regarding rbac, since he has a greater overview of how they work.

Hi @orfeas-k, thanks for the feedback. I 100% agree with you on the above changes and I had started to do it, however I am on vacation right now without access to laptop and given the timeline for 1.7 release, can we merge it without the common lib changes and do it in a follow up PR post release?

I can make the other nit changes suggested.

I want the feature to be available in 1.7. Please let me know

[kimwnasptd]

I'm good with merging this PR now and including it in the 1.7 RC, since this is the last feature we had in mind for this release for Notebooks WG.

The feature also uses a lot of the same code from the JWA as well, so since we've tested it as well I'm confident that it should be OK. We'll also keep an eye for this for the remainder of the RC testing. I'll go on and merge this iteration so that we can include it in the next RC, cc @DomFleischmann

Thanks for the work on this @surajkota!

/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kimwnasptd

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• components/crud-web-apps/OWNERS [kimwnasptd]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[surajkota]

Great, Thanks folks!