Context

ContainerFileTemplate currently accepts the path to a file, we've encountered use cases where we want to pass the file contents rather. For example, when the file content is created as part of the charm code like creating the certs.
At the moment, the workaround for this is to create a temp file and pass the path of the temp file to ContainerFileTemplate i.e. read the temp file back in.
Example of the workaround.

What needs to get done

modify the pebble component to accept file contents rather than just file paths in files_to_push

Definition of Done

1. we can pass the file content to files_to_push
2. tests are added for passing file content
3. refactor the charms where we are doing the workaround mentioned in the context.

Context

PR #81 sent changes with new helpers for testing rocks

What needs to get done

Publish a new release of chisme following the instructions in the README.md
unpin the dependency in (oidc rock repo)[https://github.com/canonical/oidc-authservice-rock] tests

Definition of Done

new version is published to PyPi and library is not pinned in any of our repos

Context

We want to unify implementation for handling custom images in the charms. We can implement key functions like parse_image_config (example here) and get_images (example here).

Note: There might be two versions for for get_images where one does not handle splitting the images into name and tag and the other one is handling it.

What needs to get done

Implement the:

• parse_image_config function
• get_images function
  which can be share across charms. Make sure the functions are properly tested.

Use the functions in target charms. List (may not be complete please double check):

• kserve.
• katib charms.
• kfp-operators.
• notebook operator. Note: this is little different as we are populating the drop down with the list in config.
• Please check if I have missed something.

Definition of Done

1. Functions are implemented tested and merged
2. Function from chisme is used in the charms

Context

The current implementation of KubernetesResourceHandler has a limitation where using jinja's tags to reference a template from within another template, for example the include tag and the import tag.
With this limitation, we resort to duplicating files as a workaround. See an example in this pr, look at katib-config.yaml.j2 and katib-config-configmap.yaml.j2 in the katib-controller templates.

What needs to get done

1. Look into the usage of Jinja's tags
2. Implement this feature in KubernetesResourceHandler
3. Add an API in the base charm's kubernetes compontent
4. Write tests for krh and the base charm

Definition of Done

chisme's KubernetesResourceHandler and the base charm's kubernetes component allow reusing of jinja templates, tests included.

I think this message:

is probably that the "container" is not yet up, not that the pod is not up. The pod is what is executing this charm code in the first place

Content should include:

• purpose of the package overall and it's pieces
• usage examples (demo for helpers, KubernetesResourceHandler, etc)

Sometimes we may run pebble containers that have their own services/environment, etc, set up and do not need us to change anything. Currently, the PebbleServiceComponent would not handle this properly as:

• get_layer() is an abstract method that must be implemented
• get_layer() and the tools that use it (_update_layer(), get_services_not_active()), were not written the a null return in mind

The current workaround is to define everything in get_layer(), even if you didn't need to change anything.

It is not valid to return an empty layer from get_layer() because the update_layer code makes the assumption that we wrote everything in a single layer.

Sometimes, it is useful to do something in kubernetes (eg: apply) and then wait for those resources to be ready before continuing. We have done this in past sometimes by locally implementing a watcher loop around some lightkube code.

It would be nice if this option was available, perhaps as an option to KRH.apply(... block_until_ready=True) and similar commands? If we implement this, we could do something like apply the resources as normal and then loop around them waiting until they all show a ready status.

It seems like charms installing chisme's deepdiff dependency will end in error with the following message:

::    ::             running build_rust                                                                                          
::    ::             error: can't find Rust compiler                                                                             
::    ::                                                                                                                         
::    ::             If you are using an outdated pip version, it is possible a prebuilt wheel is available for this package but pip is not able to install from it. Installing from the wheel would avoid the need for a Rust compiler.      

Workaround

pin deepdiff==6.2.1 in charms

Solution

pin deepdiff in the setup.cfg file

When deploying the kubeflow bundle, at some point I got the following error in the juju debug-log:

unit-training-operator-0: 17:29:52 ERROR unit.training-operator/0.juju-log Uncaught exception while in charm code:
Traceback (most recent call last):
  File "./src/charm.py", line 207, in <module>
    main(TrainingOperatorCharm)
  File "/var/lib/juju/agents/unit-training-operator-0/charm/venv/ops/main.py", line 436, in main
    framework.reemit()
  File "/var/lib/juju/agents/unit-training-operator-0/charm/venv/ops/framework.py", line 866, in reemit
    self._reemit()
  File "/var/lib/juju/agents/unit-training-operator-0/charm/venv/ops/framework.py", line 931, in _reemit
    custom_handler(event)
  File "./src/charm.py", line 189, in _on_install
    self._check_container_connection()
  File "./src/charm.py", line 135, in _check_container_connection
    raise ErrorWithStatus("Pod startup is not complete", MaintenanceStatus)
charmed_kubeflow_chisme.exceptions._with_status.ErrorWithStatus: Pod startup is not complete

The error suggests the unit should be in MaintenanceStatus, but instead was in ErrorStatus. Although this does not prevent the unit from going to active and idle, this behaviour is not what we are expecting.

Steps to reproduce

1. Deploy this bundle
2. Watch the logs for training-operator
3. Watch the status of training-operator
4. For a brief moment, the unit is in error status rather than maintenance

Context

KubernetesComponent's function _get_missing_kubernetes_resources() returns desired resources that the Component expects to be present in the Kubernetes cluster but are not. However, it won't be able to verify namespaced K8s resources that are provided without a namespace and thus it will return the the resource is missing while it will have been applied successfully. E.g. if we provide a template with a Role (which is a namespaced resource) but without a namespace in its metadata, Kubernetes will append a (default?) namesapce to it when applying it. As a result, _get_missing_kubernetes_resources() will then not locate the resource applied.

Reproduce

Using a charm that follows Reconcile style (aka Base charm class):

• add a namespaced resource in its template but remove its namespace (e.g. remove metadata.namespace from this role)
• run a simple integration test (deploying the charm)
• watch the charm being in the following state

Unit           Workload  Agent  Address     Ports  Message
kfp-viewer/0*  blocked   idle   10.1.4.207         [kubernetes:auth-and-crds] Not all resources found in cluster.  This may be transient if we haven't tried to deploy t...

Proposed Solution

We should either:

• state explicitly that _get_missing_kubernetes_resources() expects namespaced resources (if present) to always come with a metadata.namespace field in order to be able to validate their existence in the cluster orp
• modify _get_missing_kubernetes_resources() to take into account the case of a namespaced resource without a metadata.namespace and then try to locate that resource in any namespace.

Description

Expose optional force parameter in apply() in kubernetes resource handler.

In some cases force parameter is required in order to apply resources in the cluster.

As is, apply_many and delete_many will immediately fail on the first lightkube error. We should enable them to (either by default or optionally) complete all the operations they are able to before raising an exception.

For example, if you use delete_many on a list of resources where the first in the list does not exist, delete_many will attempt to delete the first, see a ApiError(404), and fail immediately without trying to delete the other resources. This is particularly troubling for charm remove hooks where we want to attempt to delete everything, but are ok if some things are already gone.