--provider flag for kompose

[surajssd]

The way, "what artifacts to generate?" is not handled consistently.
Having a provider flag will enable the further implementation of pref file, so that the way artifacts generation is handled is unified.

convert ->

validate: --provider and individual flags(--ds, --rs) cannot be together

if --provider given
    if provider is openshift
        generate dc, imagestreams, svc, routes, pvc(if needed)
    else if provider is foo
        generate x, y, z
    else
        default to k8s
        generate deployments, svc, pvc(if needed)

else if individual flags are given generate those artifacts
    deployments, svc, daemonsets, replicasets, rc can be generated for both providers
    but imagestreams, routes can be created for openshift only


else if --provider is not given and individual flags are not given
    if pref file given read artifacts from there
    else
        default to k8s
        generate deployments, svc, pvc(if needed)

up ->

individual flags not supported

if --provider given
    if provider is openshift
        generate dc, imagestreams, svc, routes, pvc(if needed)
    else if provider is foo
        generate x, y, z
    else
        default to k8s
        generate deployments, svc, pvc(if needed)
else if --provider is not given
    if pref file given read artifacts from there
    else
        default to k8s
        generate deployments, svc, pvc(if needed)

Closing this unblocks #39

[surajssd]

@ngtuna @kadel do we need this flag?

[ngtuna]

@surajssd If we see the preference file is mandatory, then we can restrict provider declared in profile inside the file. Otherwise, somehow user wanna skip the file and go directly with --provider flag, but I will see there are might be other flags need to be declared along with. Of course support both cases makes kompose more flexible, but also reduce simplicity. I go with the first option. Let's wait for @kadel comment.

[surajssd]

@ngtuna we don't want to restrict user to have preference file, that's for sure.

Or we can use other approach as, create a pref file if its not there alongside docker-compose file, with default profile of k8s and artifacts/objects to generate will be deployments and svc.

Also for up it makes sense to have a --provider and if nothing is provided we anyways default to k8s.

[ngtuna]

Yes we can generate the file by default. And probably support a subcommand kompose config in order to keep user away from editing manually (probably lead to wrong configuration). Like kubectl config

[kadel]

@ngtuna @kadel do we need this flag?

I think that we should have global provider flag, that defaults to kubernetes)
We have global flags for specifying inputs (--bundle --file) we should also have global flag for output/provider

Provider flag can be still specified with --rc --rs ... options, but list of valid controller object will depend on provider flag.

This is how i think it could look like:

kompose up - defaults to Kubernetes Deployments

kompose --provider openshift up - defaults to OpenShift DeploymentConfig

kompose convert --rc - Kubernetes ReplicationController

kompose --provider openshift convert --dc - OpenShift DeploymentConfig (it is same as default, but in future we might add another controller objects even for OpenShift)

kompose convert --dc - This is invalid option as Kubernetes doesn't have DeploymentConfigs
kompose --provider openshift convert --rc - Even this is technical valid, we don't currently support that. So right now this should also throw error (but we might add it in future)

kompose --provider openshift convert -h - this will display all valid options and controller objects (right now just --dc) but only for OpenShift and same for kubernetes kompose convert -h or kompose --provider kubernetes convert -h (this will show that --rc --rs --d ...)

Default flag can be also specified in preference file, but using --provider flag can always overwrite what is in preference file.

Yes we can generate the file by default. And probably support a subcommand kompose config in order to keep user away from editing manually (probably lead to wrong configuration). Like kubectl config

I don't think that we should require config file, even if it is auto generated. Kompose should be able to run even without any config files.
I like the idea to have kompose config to set configuration options so user doesn't have to edit the that file. (Lets do that later, when we figure out rest of the this)