istio-ecosystem / sail-operator Goto Github PK

• #106
• #107
• #108

Is this the right place to submit this?

• This is not a question about how to use the sail-operator

Feature Description

Most of the user facing information for what the sail operator is and how to use it is located in the bundle/README. Whereas the information under the main README is focused more towards developers of the operator. The user facing information should be moved (or at least copied) to the main README and the developer focused information can either move to its own section in the README or can move to a separate README.

Additional Information

No response

We need to create the documentation and update the information about how to work and make contributions in this project

Is important to update the information under both of our read me files information to share the complete information about how it works, How can be used and best practices

We'll need some free-form text under docs/ that explains our API concepts and how our CRDs are supposed to be used

We currently default to in-place updates. Once we're happy with revision-based updates, we should make it the default.

Currently blocked by #86

We need to add templates to define the different types of issues that we want to add to this project. Initially, we will create templates for feature requests, bugs and Epics

Instead of 3.0.0 (the downstream version), the version should be set to 0.1.0.

This should also include making sure that the nightly builds will go to a 0.1-nightly channel going forward.

Feature Description

Support for the primary-remote deployment model using the sail-operator.

• #97
• #147
• #154
• #155
• #91

Currently, we do not support the use of the istio-injection label when using the RevisionBased updateStrategy type. Instead, users have to use the istio.io/rev label to select workloads or namespaces for injection. We should make sure that the operator sets the default revision to the currently active revision so that the istio-injection label can be used.

• Create release-0.1 branch
• Create prow jobs for new branch

In the past, we performed a SubjectAccessReview on behalf of the user who created/modified the CR in order to find out whether they have the required privileges. We don't currently do this in sail-operator, which is a potential security issue as it could enable privilege escalation.

Feature Description

Support for the external controlplane deployment model using the sail-operator.

• #97
• #147
• #91

The job is currently executed in the fork because that was easy to setup - credentials for pushing images and the GitHub bot account were already present. We should move this job to this repository though.

Now we have some debug information when the e2e test run fails, but we need to improve and add more information that can be helpful to detect earlier the failure.

Current debug information:

• Istio CR Yaml
• Pods in Istio CR namespace
• Logs from sail-operator pod
• Logs from istiod pod

We need to add more debugging information as:

• Operator Pod YAML
• OC describe
• More logs if possible

We need to update the information in the repository about the Ways to Work in the project. This will be based in the documentation that we already agree and adding valuable information that is already created in the upstream documentation for Istio

Is this the right place to submit this?

• This is not a question about how to use the sail-operator

Feature Description

Current state of support for multi-cluster deployments should be added to the user docs along with installation instructions for what is currently supported (primary-primary).

Additional Information

No response

Whenever we create a release, we'll also want to create a helm chart tarball that we can release e.g. here on GitHub releases

Acceptance Criteria:

• generate a Helm chart tarball when a new tag is created in the repository
• upload the Helm chart tarball to GitHub Releases
• tests:
  • verify that the chart installs correctly
  • chart linting

• #84
• #110

Feature Description

We will need to verify that the user has the required privileges to run an instance of Istio. In the past, we verified this using a SubjectAccessReview check. We might have to do something similar.

Acceptance Criteria

• verify that users can not perform privilege escalation through the operator

There needs to be e2e tests to ensure you can use the Sail operator and APIs to setup a multicluster istio deployment. The tests need to cover setting up:

1. multi-primary
2. primary-remote
3. external controlplane

These e2e tests should:

• Create two separate kind clusters
• Install the sail operator/crds into each
• Follow the upstream documentation for setting up the above multicluster deployments but use the Sail CRs rather than istioctl install ...: https://istio.io/latest/docs/setup/install/multicluster/multi-primary/
  • A shared trust will need to be created for both clusters: https://istio.io/latest/docs/setup/install/multicluster/before-you-begin/
• Ensure that istio is setup correctly after install

• #78
• #98
• #104

We'll need to update our user documentation, as the README.md doesn't cover all of the features of the sail-operator anymore. It should be in Markdown and cover all major features and API resources.

• #147
• #181
• #182

Is this the right place to submit this?

• This is not a question about how to use the sail-operator

Feature Description

As part of primary-remote support, the operator should be able to run / reconcile the sail CRDs without the istio CRDs installed in the cluster.

Additional Information

No response

It looks like the openshift profile is broken.

Deploying workloads fails during injection:

2m7s        Warning   FailedCreate        replicaset/productpage-v1-78dd566f6f   Error creating: pods "productpage-v1-78dd566f6f-" is forbidden: unable to validate against any security context constraint: [provider "anyuid": Forbidden: not usable by user or serviceaccount, provider restricted-v2: .initContainers[0].runAsUser: Invalid value: 0: must be in the ranges: [1000680000, 1000689999], provider restricted-v2: .initContainers[0].capabilities.add: Invalid value: "NET_ADMIN": capability may not be added, provider restricted-v2: .initContainers[0].capabilities.add: Invalid value: "NET_RAW": capability may not be added, provider "restricted": Forbidden: not usable by user or serviceaccount, provider "nonroot-v2": Forbidden: not usable by user or serviceaccount, provider "nonroot": Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid": Forbidden: not usable by user or serviceaccount, provider "machine-api-termination-handler": Forbidden: not usable by user or serviceaccount, provider "hostnetwork-v2": Forbidden: not usable by user or serviceaccount, provider "hostnetwork": Forbidden: not usable by user or serviceaccount, provider "hostaccess": Forbidden: not usable by user or serviceaccount, provider "hostpath-provisioner": Forbidden: not usable by user or serviceaccount, provider "node-exporter": Forbidden: not usable by user or serviceaccount, provider "privileged": Forbidden: not usable by user or serviceaccount]

It looks like istio_cni.enabled is not set to true

• #86
• #75
• #168

tbd

The Sail Operator creates an istiod for the remote profile but there should only be the injection webhook and the reader service account/roles on the remote cluster.

Is this the right place to submit this?

• This is not a question about how to use the sail-operator

Feature Description

As part of primary-remote support, the sail operator needs a way to be installed without the istio CRDs.

Additional Information

No response

The bundle-push target calls the docker-push target, which in turn depends on docker-build.

The effect of this is that when running make bundle-push, the operator image is built and pushed under the -bundle tag.