kubev2v / forklift-operator Goto Github PK

Add GET/LIST namespaces to virt-controller clusterrole.

Add:

• AVIER_URL
• XAVIER_USER
• XAVIER_PASSWORD

To the virt-controller ConfigMap.

These should be the correct values:

  XAVIER_URL: http://xavier-analytics-kieserver:8080/services/rest/server/containers/instances/xavier-analytics_0.0.1-SNAPSHOT
  XAVIER_USER: kie-admin-user
  XAVIER_PASSWORD: kie-admin-password

When the target namespace for the VMs doesn't exist, virt-controller needs to create it, so we need to add more permissions to allow that.

I've referred the docs present in https://github.com/konveyor/forklift-operator/blob/main/docs/k8s.md, and https://forklift-docs.konveyor.io/documentation/doc-Migration_Toolkit_for_Virtualization/master/index.html#migrating-virtual-machines-from-cli.

The correct pods are not brought up and there is no k8s specific detailed guide.

Currently forklift operator is not cleaning up resources during reconcile when features are turned off on the CR (i.e feature_ui = false), the result is that the feature lingers on the namespace even though is not used/needed.

Steps to reproduce :

1. Deploy Forklift with all features enabled
2. Turn off one or more features
3. Watch the namespace

We need to supply resource contrains for the validation pod , essentially a set of default memory and cpu requests/limits for the service. @pemcg @fabiendupont any hints/ideas on these?

I have attempted to install this Operator on two different Openshift 4.8 platforms. Both of them give authentication failed when logging into the "virt" route after creating the forklift controller. I did validate that I was a part of the cluster-admin group when verifying.

We need to supply resource contrains for the must-gather-api pod , essentially a set of default memory and cpu requests/limits for the service. @aufi @fabiendupont any hints/ideas on these?

cc @fdupont-redhat

We have a modal in the UI to show version numbers which currently only shows the git sha1 of each forklift repo. As discussed on today's scrum, we should provide the UI with environment variables for the version numbers of the forklift operator, OCP and Kubernetes.

Problem Description

Kubernetes has been deprecating API(s), which will be removed and are no longer available in 1.22. Operators projects using these APIs versions will not work on Kubernetes 1.22 or any cluster vendor using this Kubernetes version(1.22), such as OpenShift 4.9+. Following the APIs that are most likely your projects to be affected by:

• apiextensions.k8s.io/v1beta1: (Used for CRDs and available since v1.16)
• rbac.authorization.k8s.io/v1beta1: (Used for RBAC/rules and available since v1.8)
• admissionregistration.k8s.io/v1beta1 (Used for Webhooks and available since v1.16)

Therefore, looks like this project distributes solutions in the repository and does not contain any version compatible with k8s 1.22/OCP 4.9. (More info). Following some findings by checking the distributions published:

• konveyor-forklift-operator.v2.0.0-beta.0: this distribution is using APIs which were deprecated and removed in v1.22. More info: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22. Migrate the API(s) for CRD: (["forkliftcontrollers.forklift.konveyor.io" "hosts.forklift.konveyor.io" "migrations.forklift.konveyor.io" "networkmaps.forklift.konveyor.io" "plans.forklift.konveyor.io" "providers.forklift.konveyor.io" "provisioners.forklift.konveyor.io" "storagemaps.forklift.konveyor.io"])

NOTE: The above findings are only about the manifests shipped inside of the distribution. It is not checking the codebase.

How to solve

It would be very nice to see new distributions of this project that are no longer using these APIs and so they can work on Kubernetes 1.22 and newer and published in the community-operators collection. OpenShift 4.9, for example, will not ship operators anymore that do still use v1beta1 extension APIs.

Due to the number of options available to build Operators, it is hard to provide direct guidance on updating your operator to support Kubernetes 1.22. Recent versions of the OperatorSDK greater than 1.0.0 and Kubebuilder greater than 3.0.0 scaffold your project with the latest versions of these APIs (all that is generated by tools only). See the guides to upgrade your projects with OperatorSDK Golang, Ansible, Helm or the Kubebuilder one. For APIs other than the ones mentioned above, you will have to check your code for usage of removed API versions and upgrade to newer APIs. The details of this depend on your codebase.

If this projects only need to migrate the API for CRDs and it was built with OperatorSDK versions lower than 1.0.0 then, you maybe able to solve it with an OperatorSDK version >= v0.18.x < 1.0.0:

$ operator-sdk generate crds --crd-version=v1
INFO[0000] Running CRD generator.
INFO[0000] CRD generation complete.

Alternatively, you can try to upgrade your manifests with controller-gen (version >= v0.4.1) :

If this project does not use Webhooks:

$ controller-gen crd:trivialVersions=true,preserveUnknownFields=false rbac:roleName=manager-role paths="./..."

If this project is using Webhooks:

1. Add the markers sideEffects and admissionReviewVersions to your webhook (Example with sideEffects=None and admissionReviewVersions={v1,v1beta1}: memcached-operator/api/v1alpha1/memcached_webhook.go):

2. Run the command:

$ controller-gen crd:trivialVersions=true,preserveUnknownFields=false rbac:roleName=manager-role webhook paths="./..."

For further information and tips see the comment.

We need to establish some reasonable default resource requirements for MTV and sub components, this allows a safer operation and help the k8s scheduler make more informed decisions, so far we have :

• virt-controller (2 container pod)
  requests : CPU 100m , Memory 350Mi
  limits : CPU 100m , Memory 800Mi

• virt-ui (1 container pod)
  requests : CPU 100m , Memory 150Mi
  limits : CPU 100m , Memory 800Mi

Please update CRDS changed in: kubev2v/forklift-controller#145

I've deployed Konveyor for VMs using OLM and the virt-controller cluster role is missing, so it's not possible to adjust privileges.

As virt-operator only targets OpenShift 4.6+ clusters, we will only provide OLM deployment.

Add optional properties for the following environment variables:

• LOG_LEVEL: Set the verbosity.
• PROFILE_KIND: Kind of profile (memory|cpu|mutex).
• PROFILE_PATH: Profiler output directory.
• PROFILE_DURATION: The duration (minutes) the profiler will collect data. (0=indefinately)

when specified, would be set on both (inventory, controller) containers.

Also, please mount an additional (profiler) EmptyDir in the pod for both containers and mount in: /var/cache/profiler.

Add policy agent settings for only the inventory container:

POLICY_AGENT_URL

The URL for the forklift-validation service. There isn't a route so the URL will need to be for the service which I think is http:// and port 8181.

POLICY_AGENT_SEARCH_INTERVAL

The search interval in seconds. The default is 10.

After reviewing the MTV You tube, I decided to deploy the MTV Operator. I started with the Beta, then realized that I had the Beta and that the GA was available. So as the Beta Operator was sitting in pending upgrade, I deleted it, deleted the project. Then deployed the GA version.

Result is the new Openshift-mtv project was created, the operator shows installed but the status is Upgrade Pending.....

How to proceed?