vmware-tanzu-labs / reference-platform-for-kubernetes Goto Github PK

See https://github.com/vmware-tanzu-labs/reference-platform-for-kubernetes/runs/2643363054?check_suite_focus=true

When deploying harbor role notary server goes into ImagePullBackOff.

 Warning  Failed   59m (x4 over 61m)    kubelet  Failed to pull image "projects.registry.vmware.com/rpk/notary-server-photon:v2.0.2": rpc error: code = NotFound desc = failed to pull and unpack image "projects.registry.vmware.com/rpk/notary-server-photon:v2.0.2": failed to resolve reference "projects.registry.vmware.com/rpk/notary-server-photon:v2.0.2": projects.registry.vmware.com/rpk/notary-server-photon:v2.0.2: not found

Support integrating with an external LDAP source rather than using the local LDAP server which is provisioned by default.

We should be using TLS for communication to our services. Currently, Harbor is the only service which is using certs. Add the appropriate annotations to the ingress resources in order to request certs for each of the services and verify they all work.

We need to:

1. Ensure certs exist for the ingress resources
2. Ensure users are redirected to the secure URLs

We should support active directory as an external-dns provider.

Add Velero as a backup module

There are problems with volume mounts on SELinux in which the volume mounts within the container show up with insufficient permissions errors.

We found that we can put SELinux into Permissive mode to get around that. Open to other fixes on this as well, but I think simply putting into Permissive mode or disabling is a sufficient fix at this point.

spring-cloud-gateway role fails as role is still using beta non ga code.

Currently, RPK is only supported in internet connected mode. To support offline installations:

1. Manifests would need to be delivered offline
2. Images would need to be delivered offline
3. DNS cannot be tied to AWS Route53

New process is to:

1. Fork
2. Merge to Develop

When new releases are cut, they are:

1. Develop > Master

Also, because we follow DCO, we need commits signing off by XYZ.

Clean.cluster make target doesn't clean all RPK created objects such as the Dex CRD's for identity role and Elasticsearch CRD's for logging

This allows the individual resources to be consumed outside of their individual manifest files.

Supported versions table in quick start guide has invalid formatting

External DNS Azure DNS template has some legacy ytt code causing issues when starting the pod.

The in the README.md file was not to disparage users based on their choice of platform management style, rather to easily identify what category they fall into and quickly be able to choose how to manage based on their needs. Bronze, Silver, and Gold gives the impression that one is better than the other, when, in reality, they are all equal and meant to be adjusted based on platform operator needs.

Move from the build/ directory within the project to an explicit ~/.rpk directory.
This should contain:

• inventory or inventories
• configuration which should set default variables for the Makefile
• manifests directory which is mounted at build time
• hosts file (doesn't need to exist...docker will create this for us) to mount as /etc/hosts during each run

See https://github.com/vmware-tanzu-labs/reference-platform-for-kubernetes/runs/2643362760?check_suite_focus=true

Need to test with KIND. Steps:

1. KIND_INVENTORY="ci/clusters/kind-cluster-unit.yaml" KIND_BASE_CONFIG="ci/clusters/kind-cluster-config-unit.yaml" KIND_CLUSTER="rpk-kind" make setup.kind && make setup.kind.networking - setup kind
2. ROLE=ingress make deploy.test.role - deploy ingress
3. ROLE=ingress make demo.test.role - demo ingress
4. ROLE=ingress make clean.test.role - clean ingress (this is where it fails)

Passwords inputs are required in cleartext currently. Would like a mechanism/framework to use Ansible-Vault (or equivalent) and pull in our vars that way.

A cheap alternative to this would be to, AT MINIMUM, require base64-encoded values.

Kibana takes a long time to come up. It used to take 25 mins to come up and @landerr and myself adjusted the resources. This helped it come up faster, but it still takes 5 mins to become available. For now, we are just looping until it becomes ready. We should still do this, but we need to find out why kibana is taking so long to become ready.

To Test
Deploy:

ROLE=logging make deploy.test.role

Observe that Kibana takes a long time to come up. Need to find out why this is and address the issue if possible, or document why if not possible to fix.

Considerations:

1. Does a newer version of the ECK operator fix this?

RPK assumes that the native integration isn't used. Add this to the identity docs. We need to have a fresh (no native config) install for this to work.

It looks like xip.io has been permanently shutdown. We need to remove support or modify to another dynamic DNS provider such as nip.io.

Problem:

As we progress RPK, we have no way of working with old inventory files. When new variables get added, users are unaware of it so their automation breaks. Backwards compatibility does not exist in these scenarios.

Idea:

Have a support role that has a template in it
Use build/inventory as the variables
Create the new inventory from the template and backup the old file for the user

make update.inventory perhaps could be the target

Right now roles that create projects/registries in Harbor ignore the TLS cert, we should instead collect Harbor's CA as a fact and use that in our calls to the API.

Use pre-flight steps to automatically login users of v7wk8s so that they do not have to do it out of band.