Create install script which will download the latest release and place it in the right folders which are in path.

1. Script that will download the latest release (not from source) from https://github.com/konveyor/move2kube/releases depending on the operating system and install it in the right path. A simpler version of https://github.com/helm/helm/blob/master/scripts/get-helm-3.
2. Also, please place the script in scripts folder and update the USAGE.md and README.md.

Install process should be as simple as curl https://raw.githubusercontent.com/konveyor/move2kube/master/scripts/install.sh | bash

Right now each source translator does their own traversal and their own m2kignore logic:

Pull the traversal code to a higher level, maybe here:

This avoids duplicating the m2kignore logic and should simplify the logic inside each source translator's GetServiceOptions

Description

Currently we are doing a bunch of path manipulations converting absolute paths to paths relative to the source directory plan.Spec.Inputs.RootDir, converting absolute paths to paths relative to the present working directory pwd, and vice versa.

In addition to being a source of source for bugs this also makes it harder to reason about the correctness of the code.

Examples:
https://github.com/konveyor/move2kube/blob/master/internal/source/any2kube.go#L64-L92
https://github.com/konveyor/move2kube/blob/master/internal/containerizer/dockerfilecontainerizer.go#L62-L75
https://github.com/konveyor/move2kube/blob/master/internal/containerizer/dockerfilecontainerizer.go#L101-L109

Proposal

1. Use absolute paths everywhere internally.
2. Convert the absolute paths to relative paths when marshalling.
3. Clean and convert relative paths to absolute paths when unmarshalling.
4. Remove the AbsRootDir and RelRootDir fields from plan.Spec.Inputs.
5. Remove plan.GetRelativePath.

1. Try out move2kube translate -s srcfolder, on a srcfolder which contains your application
2. If the dockerfile that is output is not satisfactory, update the containerizers templated dockerfiles in https://github.com/konveyor/move2kube/tree/master/internal/assets/dockerfiles/
3. Do a make generate
4. Create a pull request.

Config file format

More advanced users might want to configure move2kube.
Need to consider fixing the format of the qacache file so it can become a config file.
The format also needs to be clearly documented so people can use it.

Config filename convention

Also consider enforcing a filename convention for the config files something like m2kconfig-*.yaml
Currently we look at any and all yaml files and try to parse them into the qacache struct.

Most software already have a fixed filename or some filename format for their config files, so users will expect this when it comes to config files.

As a bonus it also allows you to easily enable/disable a config by simply renaming it. No need to delete it or move it to a different location.

Update

Identify an approach to support more than one deployment in a single yaml (

Description

Write unit tests to check the generated files are valid.

Add the below test just before

	t.Run("check if all clusters in constant were loaded", func(t *testing.T) {
		p := plantypes.NewPlan()
		loader := metadata.ClusterMDLoader{}
		cmMap := loader.GetClusters(p)
                //TODO: Read all .yaml files in internal/metadata/clusters, and find the value in metadata.name using say a regex
		for clustername := range <ALL NAMES IDENTIFIED IN ABOVE STEP> {
			if _, ok := cmMap[clustername]; !ok {
				t.Fatal("Missing builtin "+clustername+" cluster metadata. The returned cluster info:", cmMap)
			}
		}
	})

Google recently announced support for cnb (https://cloud.google.com/blog/products/containers-kubernetes/google-cloud-now-supports-buildpacks/).

Move2kube can easily support it out of the box as part of its cnb containerisation support.

The change required would be to

Add gcr.io/buildpacks/builder to the above array and then fix any tests that might need updates.

Description

This package normalizes certain strings in the intermediate representation.
It strips any whitespace and quotations/commas from each container's environment variables.

Two things need to be done:

1. The package is not written in the most idiomatic way.
2. The package needs unit tests.

Some examples of code that needs to be refactored:

• This should be for _, scObj := range ir.Services {
  https://github.com/konveyor/move2kube/blob/master/internal/optimizer/normalizecharactersoptimizer.go#L34-L35
• This should use TrimSpace https://golang.org/pkg/strings/#TrimSpace
  https://github.com/konveyor/move2kube/blob/master/internal/optimizer/normalizecharactersoptimizer.go#L40-L41
• This function shouldn't return an error since it isn't supposed to fail:
  https://github.com/konveyor/move2kube/blob/master/internal/optimizer/normalizecharactersoptimizer.go#L60-L64

How to get started

For this issue you should start with some simple tests that creates simple IR objects and calls the function on them.
Next step would be to make slight changes to the IR objects and create a separate subtest for each scenario.
Some scenarios that are good to test:

• Function called on an IR with no services.
• An IR containing services that have no containers.
• An IR containing services and containers but the containers have no environment variables.
• An IR containing services and containers and all the environment variables are valid.
• An IR containing services and containers and some of the environment variables are invalid (containing spaces and quotes).
• An IR containing services and containers and some of the environment variables are invalid but their names contain the string affinity.

How to add unit tests

Some guidelines:

• Look at the other tests in the package/project and write similar tests.
• Use subtests to test different paths through the function.
• Don't worry about testing every single path through the function. Focus on common use cases and failure modes.

Some helpful resources on how to write unit tests in Go:

• https://blog.golang.org/subtests
• https://youtu.be/hVFEV-ieeew

Code to be tested

Move2Kube collectors which can be invoked using move2kube collect help extract runtime information.

To allow translation from Amazon ECS and Azure Container Service, similar to how we have structured for Cloud Foundry in here (https://github.com/konveyor/move2kube/blob/master/internal/collector/cfappscollector.go).

We can write a collector which will access the running container instances, and extract metadata out of it and serialize it in a format similar to https://github.com/konveyor/move2kube/blob/master/types/collection/cfinstanceapps.go.

Requirements:

1. Access to Amazon ECS or Azure Container Service

Tasks involved:

1. Create a serialization format similar to https://github.com/konveyor/move2kube/blob/master/types/collection/cfinstanceapps.go
2. Write a collector to access the runtime using api and serialize the data similar to https://github.com/konveyor/move2kube/blob/master/internal/collector/cfappscollector.go

https://medium.com/star-systems-labs/kubectl-convert-update-api-versions-automatically-e669add17e3d

Check if any of these cases need to be handled, and if Move2kube already handle these cases.

Also, ensure when no other service is detected, it can do the conversion properly

As suggested by @akhil-ghatiki , it is good to have a make target which can emulate what travis does, so that it is easier to fix issues before checking in.

Ref : #50 (comment)

https://github.com/konveyor/move2kube/tree/master/internal/customizer

https://github.com/konveyor/move2kube/tree/master/internal/move2kube

Description

This file implements our CLI using this library https://github.com/AlecAivazis/survey

To ask the user a question we use one of these NewXProblem functions to create a Problem object:
https://github.com/konveyor/move2kube/blob/master/types/qaengine/problem.go#L260-L288

We pass the Problem object to FetchAnswer to get the answer from the user. Example:
https://github.com/konveyor/move2kube/blob/master/internal/customizer/registrycustomizer.go#L120-L131

We need unit tests for the functions in this file.

How to get started

❗ Please read the contribution guidelines first https://github.com/konveyor/move2kube/blob/master/contributing.md

Since these functions print to stdout and take input from stdin we need to use the goexpect library:
https://github.com/google/goexpect

For this issue you should start by running move2kube on some of the samples in your samples folder.
This will give you a good idea of what the output looks like and what the input it expects is.

Next write some simple tests that call the functions in this file.
Look at the examples https://github.com/google/goexpect#basic-examples and check if the functions are producing the correct output.

How to add unit tests

Some guidelines:

• Look at the other tests in the package/project and write similar tests.
• Use subtests to test different paths through the function.
• Don't worry about testing every single path through the function. Focus on common use cases and failure modes.

Some helpful resources on how to write unit tests in Go:

• https://blog.golang.org/subtests
• https://youtu.be/hVFEV-ieeew

Code to be tested

Description

The move2kube tool when run asks the user some questions about how to translate the project.
The answers gathered from this Question Answer (QA) session are stored in a yaml file that we call the QA cache.
The global variable qaengine is used to prompt the user and fetch answers during the QA session.

This package looks in the source folder for the QA cache yaml files and loads the filepaths into the plan.
It parses the yaml files it finds to check if they are qa cache files or not before adding them.
During the translate phase it also loads those caches into the QA engine.

How to get started

❗ Please read the contribution guidelines first https://github.com/konveyor/move2kube/blob/master/contributing.md

To gather some QA caches files to use as testdata, you can run move2kube on any of the projects in the samples folder.
You will find a file called m2kqacache.yaml in the output directory.

For this issue you should start with some simple tests that creates temporary directories and calls the functions on it.
Next step would be to make slight changes to the files in the directory and create a separate subtest for each scenario.
Some scenarios that are good to test:

• Function called on non existent directory.
• Function called on a file.
• Empty directory.
• Directory we don't have permission to read.
• Directory with only non yaml files.
• Directory with some yaml files that aren't QA cache files.
• Directory with some QA cache files and other random files.

How to add unit tests

Some guidelines:

• Look at the other tests in the package/project and write similar tests.
• Use subtests to test different paths through the function.
• Don't worry about testing every single path through the function. Focus on common use cases and failure modes.

Some helpful resources on how to write unit tests in Go:

• https://blog.golang.org/subtests
• https://youtu.be/hVFEV-ieeew

Code to be tested

Adding a new docker file based containerization technique for move2kube involves the following:

1. Check out other existing dockerfile containerizers in https://github.com/konveyor/move2kube/tree/master/internal/assets/dockerfiles
2. Write a detect script called m2kdfdetect.sh in a new folder similar to https://github.com/konveyor/move2kube/blob/master/internal/assets/dockerfiles/python/m2kdfdetect.sh
3. The detect script should return any parameters that will be required by the dockerfile as a json
4. Write a dockerfile (similar to https://github.com/konveyor/move2kube/blob/master/internal/assets/dockerfiles/python/Dockerfile) which uses the paramters passed above.
5. Do a make generate
6. Do a make build
7. Test whether move2kube translate -s srcfolder, where srcfolder is the folder where a folder containing the application that can be containerized using the above code is present. Check whether move2kube detects it.
8. Check into https://github.com/konveyor/move2kube/blob/master/internal/assets/dockerfiles/
9. Create a pull request.

The task involves the following:

1. Setting up a terminal with the cluster in context for kubectl
2. Run move2kube collect
3. Copy the m2k_collect/clusters/
4. Change name to .yaml
5. In yaml, change metadata.name to clustername used above
6. Check in to https://github.com/konveyor/move2kube/tree/master/internal/metadata/clusters
7. Do make generate
8. Submit a pull request after committing with git commit -s -m comment

If someone runs move2kube translate we look for a file called m2k.plan but we don't tell the user that:

Add a warning that we are going to use the plan file that we found.
The warning should also have the path of the file, just so there is no confusion.

Description

There are several unit tests that use reflect.DeepEqual for comparing the expected output with the actual output of the function. Currently the error messages when the equality check fails is not very helpful.

Example:

The error message simply prints the expected and actual outputs to the console with no indication of what is different between the two.

This is especially painful for large structs. The difference could be in a single field but finding that field can take ages.

Fix

Use the cmp package and https://pkg.go.dev/github.com/google/go-cmp/cmp#Diff to print more "human friendly" error messages.

Example:
https://github.com/HarikrishnanBalagopal/move2kube/blob/tekton2/internal/source/any2kube_test.go#L415-L417
Ignore the cmpopts.EquateEmpty() part, that is specific to that unit test.

How to get started

For this issue you should look into as many of the *_test.go files as possible and change the error messages.
Good places to start:

• https://github.com/konveyor/move2kube/blob/master/internal/source/any2kube_test.go
• https://github.com/konveyor/move2kube/blob/master/internal/containerizer/dockerfilecontainerizer_test.go
• https://github.com/konveyor/move2kube/blob/master/internal/containerizer/manualcontainerizer_test.go
• https://github.com/konveyor/move2kube/blob/master/internal/containerizer/reusecontainerizer_test.go
• https://github.com/konveyor/move2kube/blob/master/internal/containerizer/s2icontainerizer_test.go
• https://github.com/konveyor/move2kube/blob/master/internal/move2kube/planner_test.go

On the lines of docker-compose support, add support for mesosphere.

Use a go based library which can parse mesosphere deployment files and convert it to IR.

https://github.com/konveyor/move2kube/tree/master/internal/parameterizer

Right now we always set the backend service port of an ingress path to the default port:

Add support for setting a custom port.
Use case: preserving ports while translating docker compose and old k8s projects.

Enhance make build-cross and make dist to make the zip files contain the files that are directly required instead of having the platform name as folder name in the base folder.

Description

This package looks in the source folder for k8s yaml files and loads the filepaths into the plan.
It parses the yaml files it finds to check if they are k8s resources.
It also transforms the files into runtime objects during translate phase.

How to get started

For this issue you should start with some simple tests that creates temporary directories and calls the functions on it.
Next step would be to make slight changes to the files in the directory and create a separate subtest for each scenario.
Some scenarios that are good to test:

• Function called on an empty directory.
• Directory we don't have permission to read.
• Directory with only non yaml files.
• Directory with some non k8s yaml files.
• Directory with some k8s yamls and other non k8s files.

How to add unit tests

Some guidelines:

• Look at the other tests in the package/project and write similar tests.
• Use subtests to test different paths through the function.
• Don't worry about testing every single path through the function. Focus on common use cases and failure modes.

Some helpful resources on how to write unit tests in Go:

• https://blog.golang.org/subtests
• https://youtu.be/hVFEV-ieeew

Code to be tested

Improve Code coverage for unit tests in the various packages of move2kube.

Refactor the CI/CD pipeline creation into multiple apiresource files instead of having it all in one single file.

Note: Also look at removing RepoInfo from the plan. Try to move the git repo detection to translate phase.

move2kube translate does not support the .env file while parsing the docker-compose.yaml file. It returns an error-

Error while loading docker compose config : 1 error(s) decoding:

* error decoding 'Ports': No port specified: :<empty> 
ERRO[0009] Unable to parse docker compose file dock-com/docker-compose.yaml using *compose.V3Loader : 1 error(s) decoding:

* error decoding 'Ports': No port specified: :<empty> 

The below files can be used to reproduce the error.

# this is the docker-compose.yaml file
version: '3.4'
services:
    goodbot:
        image: python
        env_file:
            - .env
        ports:
            - ${PORT}:${PORT}

# this is .env file
PORT=123

(kompose convert also has similar issue- kubernetes/kompose#1289)

Description

Bug

https://github.com/konveyor/move2kube/blob/master/internal/apiresource/networkpolicy.go#L56-L60
The object gets appended even when there is an error.

Fix: Add a continue inside the if block.

Too many checks and error messages

https://github.com/konveyor/move2kube/blob/master/internal/apiresource/networkpolicy.go#L53-L64
The variables supportedKinds and networkPolicyKind do not change inside the loop. However it keeps checking
if the string networkPolicyKind is present in the array supportedKinds over and over.
Every time the check fails it prints an error message resulting in lots of error messages about the same thing.

Fix: Move the check and error outside the loop.

Add unit tests.

Add unit tests for all these functions:
https://github.com/konveyor/move2kube/blob/master/internal/apiresource/networkpolicy.go#L43-L113

How to get started

❗ Please read the contribution guidelines first https://github.com/konveyor/move2kube/blob/master/contributing.md

First fix the bugs mentioned above, then write the unit tests for the fixed functions.
Since the functions really only have 1 or 2 paths through them the unit tests can also be very simple.

How to add unit tests

Some guidelines:

• Look at the other tests in the package/project and write similar tests.
• Use subtests to test different paths through the function.
• Don't worry about testing every single path through the function. Focus on common use cases and failure modes.

Some helpful resources on how to write unit tests in Go:

• https://blog.golang.org/subtests
• https://youtu.be/hVFEV-ieeew

Code to be tested

Update copysources.sh with the default value of the source path, so that it works even if no parameters are provided.

This will require changing the copysources.sh template and feeding it with the value of source folder relative to the output folder.

https://github.com/kubernetes-sigs/kustomize

Description

1. As mentioned in the TODO https://github.com/konveyor/move2kube/blob/master/internal/metadata/k8sfiles_test.go#L77
   we should not continue when the directory has incorrect permissions and we can't read it.

2. The functions we are testing https://github.com/konveyor/move2kube/blob/master/internal/metadata/k8sfiles.go#L36-L80 may not be the most idiomatic way to write them. For example: we have a continue and an else block.

Changes to be made

Return with the error in the if block.

Change the test to expect the error.

Change the functions to be more idiomatic go.

Allow fan-out ingress support in https://github.com/konveyor/move2kube/blob/master/internal/apiresource/service.go

Currently the pipeline resource is very much tailored for CI/CD pipeline generation:

Make the creation of the pipeline more generic so it can be used for more things.

What needs to be done:

1. Checkout the completion scripts in https://github.com/helm/helm/blob/master/cmd/helm/completion.go
2. Model move2kube to have similar commands for generating completion scripts

Description

This shell script is used to install the dependencies of the project.
Currently it does not pass checks by the linter shellcheck https://www.shellcheck.net/

Line 22:
elif [ "$(expr substr $(uname -s) 1 5)" == "Linux" ]; then
          ^-- SC2003: expr is antiquated. Consider rewriting this using $((..)), ${} or [[ ]].
                      ^-- SC2046: Quote this to prevent word splitting.

How to get started

❗ Please read the contribution guidelines first https://github.com/konveyor/move2kube/blob/master/contributing.md

As the error says rewrite the expression using one of $((..)), ${} or [[ ]]
Also make sure there are no other errors.
You can run shellcheck locally: https://github.com/koalaman/shellcheck
or as a vscode extension: https://marketplace.visualstudio.com/items?itemName=timonwong.shellcheck

Guidelines

• Bash tutorial: https://mywiki.wooledge.org/BashGuide
• FAQ about common tasks: https://mywiki.wooledge.org/BashFAQ
• Things NOT to do: https://mywiki.wooledge.org/BashPitfalls
• Bash reference: https://mywiki.wooledge.org/BashSheet

I see two weird things in the deployment yaml generated when running the local UI version on the cloud-foundry sample app in move2kube-demos:

1. funky character for the value of PORT env var
2. Duplicate containerPort elements for the same 8080 port in the ports section

I targzipped the cloud-foundry sample folder, and uploaded to the UI. Did not run collect. Chose new Dockerfile plan option.

Attaching screen shot.
Q&A cache in the follow up comment below.