Modularize convert into loader & transformer

[ngtuna]

This is an initial step of modularizing convert function into loader and transformer. I found a bit difficult to create the komposeObject interface due to Go import cycle problem. The easiest thing I can do is creating the shared struct komposeObject in a separate package which loader and transformer can use. Although I think komposeObject interface is still a good idea.

@kadel I'm looking for comment from your side.

[ngtuna]

#55

[kadel]

Hi @ngtuna I just give quick look to this PR.

kobject pkg looks goot.
But with loaders and transformers I had something little bit else in my mind.
I thought that every loader and every transformer would be in its own package.
so we would have kubernets, openshift, dockercompose and bundle packages.

Decisions which loader or transformer to use would be in app.go. You are on good track with loaders switch I think that there should be something similar for transformers also. If we put all that decisions outsde of tranfromers packages, it will be easy to add more transformers in the future.
But i guess this is little bit harder to do right now, as openshift and kubernetes are tight together right now :-( - but I can help with that.

[ngtuna]

@kadel Agreed. I suggest that I should add one more commit to the PR for creating separate packages for every loader and transformer, then we can merge it upstream and let people contribute more based on this construction.

[ngtuna]

I'm creating shared functions (lot of) for both k8s and openshift packages then we should be good. For the switch decision of which output provider that transformer should refer to, I think at this moment if --deploymentconfig is used, then go to openshift, otherwise go by default to k8s.

[ngtuna]

@kadel There are things happened on my mind:

• Loader and transformer would be sit in their own packages no doubt. So we have at this time bundlefile, dockercompose, kubernetes, openshift packages.
• With bundlefile & dockercompose, they shared the same sort of functions such as:
  • loadImage()
  • loadEnvvars()
  • loadPorts()
  • others: loadWorkingDir(), loadCommand(), loadVolumes(), etc
• Similar to k8s and openshift, they also looks the same. Even they shared lot of common functions.
  • initRC()
  • initSC()
  • initDC()
  • initDS()
  • initDeploymentConfig() (OpenShift only)
  • configEnvvars()
  • configPorts()
  • configServicePorts()
  • configVolumes()
  • others: configWorkingDir(), configCommand(), etc

So, I would suggest to create loader and transformer interfaces. Then let bundlefile, dockercompose, k8s, openshift implement the interface they belong to. Upcoming providers and input formats will be implemented following this structure.

Thought?
/cc @Runseb @janetkuo

[kadel]

👍 @ngtuna
I would only suggest to make those interfaces smaller and generic so it is easy to add more transformers/loaders in future.

for loader I can image just something like this:

loadFiles(files []string) (KomposeObject, err)

for transformer:

loadKomopse(kobject KomposeObject, format string) (map[string]string, err)

returned map[string]string would look for example like this:

{ 
   "foobar-rc.yaml": "
apiVersion: v1
kind: ReplicationController
.........
",
   "foobar-service.yaml": "
apiVersion: v1
kind: service
.........
}

That this returned map could be either saved to files, or displayed to stdout.
But I'm not sure if returning it as this big map is good idea. :-(

[ngtuna]

@kadel I'm gonna merge this PR to skippbox:loader-transfomer and then switch to work on that branch, because there are some changes of convert function I would like to rebase from skippbox:master. I will send another PR for that work.