Description

The current setup for creating Spaces with Nauticus is straightforward, but often, administrators find themselves repeatedly configuring the same set of parameters, such as resource quotas, network policies, role bindings, etc. This repetition becomes a hindrance to efficiency. To streamline this process and make space creation more efficient, we propose the introduction of Space Templates.

Space Templates would be pre-configured templates that administrators could create, which include common configurations (e.g., resource quotas, network policies, role bindings, etc.).

Usage

A Space Template could be referenced in the Space resource during creation, and any spec within the Space resource would override the corresponding parameters in the Space Template.

Example:

apiVersion: nauticus.io/v1alpha1
kind: Space
metadata:
  name: my-space
spec:
  template: 
    name: my-template
    namespace: nauticus-system
  networkPolicy: 
    .... # This would override the network policy in 'my-space'

Here, my-template would be another Kubernetes custom resource of kind SpaceTemplate.

apiVersion: nauticus.io/v1alpha1
kind: SpaceTemplate
metadata:
  name: my-template
  namespace: nauticus-system
spec:
  resourceQuota: 
    ...
  networkPolicy: 
    ...
  roleBindings:
    ...

Deliverables

1. Define the SpaceTemplate CRD.
2. Update the Space CRD to reference a SpaceTemplate.
3. Update the Nauticus controller to handle SpaceTemplate references and overrides.
4. Update the documentation to include SpaceTemplate usage.

This feature would greatly streamline the creation of Spaces and improve the efficiency of administrators. I look forward to seeing this implemented!

Problem Description

Currently, the additionalRoleBindings field in the Space resource specification uses the clusterRoleName field to specify the role to be bound. However, this field is not sufficient as it does not provide enough information about the role to be bound.

Proposed Solution

• Update the additionalRoleBindings field in the Space resource specification to use the roleRef field instead of the
  clusterRoleName field.
• The roleRef field should include the following fields:
  • apiGroup: The API group of the role.
  • kind: The kind of the role (e.g. ClusterRole, Role).
  • name: The name of the role.

Impact

This change will improve the flexibility of the Space resource specification by allowing users to bind roles from different API groups and kinds. However, it will also require users to provide more detailed information when specifying the role to be bound.

Objective: To add the ability for users to specify that resources created in a Space should not be deleted when the Space is deleted.

Steps:

• Add an annotation "nauticus.io/ignore-deletion" to the Space CRD.
• Update the Nauticus controller code to check for this annotation when a Space is deleted.
• If the annotation is present, update the owner references of all resources within the Space to remove the Space as the owner. This will prevent Kubernetes from automatically deleting the resources when the Space is deleted.
• Create a field in the Space CRD that allow users to specify a grace period before the controller deletes the resources.
• Modify the controller to delete all resources in the space after the grace period, this will allow the users to drain their resources before they are deleted.
• Test the new feature by creating a Space and adding resources, then deleting the Space and verifying that the resources are not deleted automatically and the controller deletes them after the grace period.
• Document the new feature in the README and update the user documentation accordingly.

References

• https://kubernetes.io/docs/concepts/architecture/garbage-collection/
• https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion
• https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/

Details

This task involves adding end-to-end (E2E) tests to the Nauticus project using the ginkgo framework and testenv package. The tests will be created using kubebuilder and will be integrated into the project's Github Actions workflow to run automatically with each pull request and commit to the repository. The goal of these E2E tests is to ensure the overall functionality and integration of the Nauticus project in a real-world Kubernetes environment. The test cases will cover various scenarios and use cases of the project's features, such as creating, updating, and deleting spaces, and will verify the expected behavior and output. This task will also include setting up the necessary configuration and dependencies for the tests to run successfully.

This task is about setting up a Continuous Integration (CI) pipeline for building and publishing the Nauticus Helm chart. The objective is to automatically build and package the Helm chart whenever a change is pushed to the repository. The CI tool to be used for this task is Github Actions.

The steps involved in setting up the CI pipeline are as follows:

1. Create a Github Actions workflow to build the Helm chart.
2. The workflow should clone the repository, run the Helm chart build command, and package the chart into a .tgz file.
3. The packaged chart should then be published to a chart repository, such as ChartMuseum, Google Cloud Storage, or any other repository of your choice.
4. Finally, the workflow should run tests to validate the chart and its components.
5. The goal is to have a fully automated process for building, packaging, and publishing the Helm chart, ensuring that the chart is always up-to-date and available for users to install in their Kubernetes clusters.

Problem Description

Currently, the Nauticus Controller does not have a continuous integration (CI) pipeline set up to automatically build and push the Docker image of the controller to multiple registries.

Proposed Solution

• Implement a Github Actions workflow to automatically build and push the Docker image of the controller to multiple registries.
  The workflow should include the following steps:
  • Build the Docker image of the controller.
  • Push the image to multiple registries (e.g. Docker Hub, GitHub Packages, and any other private or public registries)

Impact

This change will automate the build and push process of the Docker image, reducing the manual effort required to release new versions of the controller and making it easier to distribute the controller to users.

Problem Description

Currently, the Space resource specification does not have a field for creating and managing service accounts. However, in some cases, users may need to create service accounts with different annotations (such as cloud provider bindings) within a Space.

Proposed Solution

• Add a new field serviceAccounts in the Space resource specification that allows for the creation of a list of service accounts.
• Each service account should include the following fields:
  • name: The name of the service account.
  • namespace: The namespace where the service account should be created.
  • annotations : The annotations of the service account (e.g. cloud provider bindings)

Details

This task involves adding the Kubernetes Conditions feature to Nauticus. Kubernetes Conditions are used to track the state of a Kubernetes resource, such as a deployment, and its readiness. This feature will allow Nauticus to more accurately reflect the current state of a space and its resources, making it easier for users to manage and monitor their spaces. The implementation of Kubernetes Conditions will require changes to the Nauticus controller and may also require updates to the Nauticus API. The end result of this task should be a more robust and user-friendly Nauticus, allowing for better management and monitoring of spaces and their associated resources.

Reference

1. https://github.com/cert-manager/cert-manager/blob/f058c815a379afc36e9abff21454fc3423e40f78/pkg/api/util/conditions.go
2. https://maelvls.dev/kubernetes-conditions/

Objective: To add the ability for users to set resource limits and constraints on the Spaces created using the Nauticus controller.

• Add a new field "limitRange" to the Space Custom Resource Definition (CRD) to allow users to specify resource limits and constraints.

• Update the Nauticus controller code to read the limitRange field and apply the specified limits and constraints to the underlying Kubernetes namespace.

• Test the new feature by creating a Space with limitRange set and verifying that the limits are properly enforced on the underlying namespace.

• Document the new feature in the README and update the user documentation accordingly.

Note: Limit Ranges allow you to set constraints on the resource usage of pods, it will be a good idea to add the possibility to set limitRanges on the Space, it will be the user's responsibility to set the right limit depending on the workloads they will run on the space.

Bug description

Issue: When creating a space from a template with resource quota override, the initial creation works as expected. However, subsequent edits to the space, specifically updating the overridden resource quota values, do not prompt any reaction or update from the nauticus-controller.

How to reproduce

Steps to reproduce the behavior:

1. Set Up a Kind Cluster: Initialize a new kind cluster for testing.
2. Apply the Space Template: Use the space template provided in config/samples to set up the initial space.
3. Apply the Space Override: Implement a resource quota override on the created space.
4. Edit the Space: Use kubectl edit to modify the space, particularly changing a resource quota value.

Expected behavior

The expected behavior is that the nauticus-controller should detect changes made to the space's resource quota and update accordingly. This should include applying the new quota values to the space.

Logs

If applicable, please provide logs of nauticus-controller.

Nothing happens, so there is no logs.

Additional context

Nauticus version: v0.2.0
Helm Chart version: v0.2.0
Kubernetes version: v1.27.2

Objective: To create a documentation page for the Nauticus controller, to provide users with clear and comprehensive information about how to use the controller and its features.

• Create a new repository on GitHub to hold the documentation files.
• Use markdown files to write the documentation, covering topics such as installation, usage, and troubleshooting.
• Use GitHub Pages to host the documentation, by enabling it on the repository settings.
• Use a theme or template to make the documentation look good and easy to navigate.
• Create a link to the documentation page in the main Nauticus repository.
• Test the documentation page by visiting it and ensuring that all links work and the information is clear and correct.

Note: The documentation page will be the first point of contact for the users, it should be simple, clean and easy to navigate, it's important to keep it updated as the project evolves.

The objective of this task is to make the Nauticus documentation version-able using mike. Mike is a Python utility that helps in deploying multiple versions of documentation to a Git branch, which can be hosted on Github via gh-pages.

The following steps are involved in this process:

1. Configuring mike to generate the documentation in the required format, such as HTML, PDF, etc.

2. Integrating mike with Github Actions, to automate the process of building and deploying the documentation.

3. Defining a versioning strategy for the documentation and updating it with every change in the code.

4. Updating the README file of the repository with a link to the versioned documentation.

By the end of this task, the Nauticus documentation will be version-able and easily accessible for all stakeholders, helping them stay updated with the latest changes in the code.

Reference

https://github.com/jimporter/mike

Describe the feature

This should change:

...
spec:
  owners:
    - name: [email protected]
      kind: Group

A kind is not sufficient to definitively identify which API group we mean here. Instead, we should specify owners more like:

...
spec:
  owners:
    - name: [email protected]
      apiGroup:  rbac.authorization.k8s.io
      apiResources: groups # yes, the lowercase plural form that you see at the HTTP layer
    - name: [email protected]
      apiGroup:  some.other.example
      apiResources: externalserviceaccounts # for this example, it could be an aggregated API
    - name: [email protected]
      apiGroup:  avatars.some.other.example
      apiResources: users # ambiguous name, disambiguated by API group

We also shouldn't assume that Kubernetes RBAC is the only game in town. You can have a conformant Kubernetes cluster that uses a different access control mechanism and runs with RBAC disabled.

Expected behavior

There's never ambiguity about how we refer to owners.

Problem Description

Currently, the Nauticus Controller does not have a Helm chart, making it difficult to deploy and manage the controller in a Kubernetes cluster.

Proposed Solution

• Create a Helm chart for the Nauticus Controller.

Impact

This change will make it easier to deploy and manage the Nauticus Controller in a Kubernetes cluster. Users will be able to use the Helm chart to quickly and easily install the controller and configure it to their specific needs.

Further Steps

• Publish the chart in a public or private helm repository
• Add CI/CD pipeline to automatically update the chart when new version of the controller is available
• Add test for the chart by using tools such as Helmfile and Helm test

This task is about implementing a continuous integration (CI) pipeline using Github Actions to release the Nauticus controller and its associated manifests. The goal is to automate the process of building and publishing the Nauticus controller and its manifests to a repository, such as GitHub releases or a package manager like Helm. The CI pipeline will be triggered whenever changes are pushed to the repository, and it will compile the code, run tests, and publish the artifacts. The pipeline should include steps to:

1. Check out the code from the repository
2. Build the Nauticus controller and its manifests
3. Test the built artifacts
4. Publish the built artifacts to a repository (e.g., GitHub releases or a package manager)

By implementing a CI pipeline, the development team will be able to automate the release process, ensure that the released code is of high quality, and receive feedback quickly. This will help to streamline the development process and increase efficiency.

The goal of this task is to implement Prometheus metrics for the Nauticus controller. This will involve creating new endpoints in the controller to expose metrics in a Prometheus-compatible format and configuring Prometheus to scrape these endpoints. The metrics should include information about the number of spaces, resource quotas, and network policies created, updated, and deleted. Additionally, it should include information about the number of errors that occur during these operations. The implementation should follow best practices for Prometheus metric collection and should be thoroughly tested before being merged into the main codebase. A documentation should be added to the official documentation of nauticus about how to use these metrics. The task should also include the setup of grafana dashboard for the metrics.