Investigate a preference file

[ngtuna]

for example

[default]
provider=kubernetes
objects=deployments

[test]
provider=openshift
objects=petsets

[cuonglm]

@ngtuna What will be group in preference file used for?

We don't need to add command line flags to chose between group, do we?

[ngtuna]

@Gnouc yes we don't need flags in preference file. Let's go first with provider and default objects to be generated. Then we can discuss what should be added more.

[surajssd]

@ngtuna i would like to work on this issue!

Some questions regarding this, with prefernce file are we gonna have alternative to all the command line flags(not in the immediate PR but in the long run)?

[sebgoa]

@surajssd the original idea was to use this to create some profiles that would define defaults behavior. kind of like kubectl contexts.

for example

[default]

[oc]
provider=openshit
resource=replicationcontrollers

[sebgoa]
provider=kubernetes
resource=deployments

then maybe calling kompose profile sebgoa would make kompose up use k8s provider and deployments.
but kompose profile oc would make kompose up use openshift and RC.

things like --f, --q, --stdout,--y etc...don't need to change. They could be set in the context to shorten the kompose command but right now, I don't see it as necessary.

The big feature is to be able to switch provider but keep the kompose up UX.

[ngtuna]

@surajssd great to know you're stepping forward with this.

I don't think we are gonna have alternative to all flags. Basically preference file is a kind of kompose context which helps us easily switch between providers. Flags are still declared along with kompose commands. At this moment I suggest we should cover these below configurations in preference file:

• provider
• default objects to be generated

Look at the example file I put above.

Right now we are relying on kubectl configuration at ~/.kube/config. I'm not really sure but somehow IMO we should put API endpoint and authentication info into preference file as well.

[surajssd]

@ngtuna sure that example file is a great reference, on which I can base my work on! We can add more things going forward!

[surajssd]

@ngtuna about file format why can't the file format be yaml, as oppose to ini?
I certainly understand that ini file format is easy to write as opposed to yaml, but considering future additions, is ini file format a right way to go?

This will also need more feedback from all the folks.
Ping: @kadel @janetkuo

[kadel]

+1 for yml. If not for other reasons that at least so we don't introduce new file format.
docker-compose definition is already in yaml, it would be nice to have this in same format.

[surajssd]

Just a brain dump: right from the start of this file format creation we define a schema for it, and gojsonschema can help us with it going forward, even libcompose has defined a schema for docker-compose format here https://github.com/docker/libcompose/blob/35cdb15b37b0b7b471f382c4e0c5152d4414d902/config/schema.go

[surajssd]

hey @ngtuna @Runseb its cool if we go ahead with yaml right? I needed views of you guys so that I can start to work on it?

[sebgoa]

yaml or .ini file...

[surajssd]

cool i will start working with yaml as our input file, thanks!

[dustymabe]

how complicated does the config file need to be? might be easier on user if it is ini file.. if we think it will get complicated over time then yaml is best.

[kadel]

I think that at begging it might be fairly easy and simple, but will grow in the future.
I don't think that ini is that easier on user compared to simple yaml.

For example ini mentioned in #39 (comment) could look in yaml like this:

oc:
  provider: openshit
  resource: replicationcontrollers

sebgoa:
  provider: kubernetes
  resource: deployments

[dustymabe]

I don't think that ini is that easier on user compared to simple yaml.

ok

[surajssd]

About this one more question,

• Where is this file situated? Is it similar to Kubernetes(~/.kube/config) like a ~/.kompose/config? or ~/.kompose/defaults

[kadel]

I think it should be right next to docker-compose.yaml file, in the same directory. You will have separate preference files for each project.

[kadel]

@Runseb

the original idea was to use this to create some profiles that would define defaults behavior. kind of like kubectl contexts.

Do we really need profiles? What would be use case for having multiple profiles?
I would expect that most people are going to use only one profile anyway.

If user requires to have multiple configuration he could just have multiple preference files, and we can have option to chose which file to use, similar to how it is done with docker-compose.yaml. By default we read that but you can always use your own with -f.
We could do similar thing for preferences. By default it can be in kompose.yaml and you can choose different file with --conf option.

[sebgoa]

I could see myself having a k8s cluster and an oc endpoint, then wanting to switch between them.

But you are right I think, in any case we would need to pass an arg to specify which profile to use.

I have a preference to keep a single configuration file ~/.kompose that can have multiple profile, rather than asking users to write their own configuration file.

need more thinking on this, we need to have a good feel for the UX.

[dustymabe]

is it possible that we could add "profile" information to the ~/.kube/config file similar to the way a user can add content to a .gitconfig file that isn't specific to git, but specific to tools that surround git

[kadel]

I have a preference to keep a single configuration file ~/.kompose that can have multiple profile, rather than asking users to write their own configuration file.

It depends what will be in that file. I was imagining that there might be some project specific stuff, like discussed in #154 , than it wouldn't make much sense to have one global file.
I expect that we will find more and more cases where we need provide some additional values on top of docker-compose.yaml file, it that case it would be better to have per project config file.
But we can also go with labels approach and modify docker-compose.yaml file in that case it would probably make more sense to have one global config.

I could see myself having a k8s cluster and an oc endpoint, then wanting to switch between them.

But you are right I think, in any case we would need to pass an arg to specify which profile to use.

This is probably just a matter of taste :-). For me it is just more clear to switch between files that are kept with project, than to have everything in one file with multiple sections.

[surajssd]

Since we had a discussion also about having registry info in your pref file, it makes sense to have single global file, with URL to registry, auth info, etc.

Because a user will not like having to copy things around?

[kadel]

sone of that information can be in docker-compose.yml like url to registry.
URL of registry is part of image name and you can specify image name when doing build in docker-compose file.
I don't know if you can do auth in docker-compose, so this might be trickier.

[kadel]

We should probably agree what this preference file should be for.

I see it as configuration for how kompose does conversion and deploy for given project.
When multiple people works on same project this file is committed with source so everyone is using same config and have same conversion result. Similar to how everyone is using same docker-compose file. This file acts as docker-compose extension providing additional information needed for conversion to k8s and it is specific for given project.

If I understand it correctly than @sebgoa sees it as global config file for kompose program.
What other thinks will be configured as global values for kompose?
Right now I can see only one thing, and that is provider. Maybe default controller object? But I think that controller object should be also per project configuration. Fo one project I might want DaemonSets and for other just regular Deployments.
If it is just about provider, that we can use global flag that can be set from env variable so user doesn't have to type it every time.

[kadel]

This is starting to block us a little bit.

I'm still convinced that this should be file in project directory (next to docker-compose.yml).
Doing it like this all settings can be easily shared between developers and it can contain additional data required for proper conversion to k8s. This will also solve problems like #163 #154.

[ngtuna]

While the location of pref file still in conversation, I am not sure if everybody agrees with me that keep the docker-compose file unchanged would be a good taste for UX. People bring their compose (or bundle) file in and use kompose in order to convert things, they won't expect have to edit the original file as an additional requirement for the conversion.

[ngtuna]

Ah... we still have #154 for the labels...

[kadel]

I'm still not sure what benefit this brings to users. 😕

For me it just adds unnecessary complexity.

When will user need multiple profiles with different settings (like different controller object or different provider)? Is there a real use-case for it?

I can think only one case and profiles is overkill for it:
I'm using old Kubernetes and I don't want to use Deployments. Than it is annoying to always remembering adding --rc or I'm using OpenShift than I have to always use -p openshift.
But this can be easily solved if we have ENV variable for every option in commandline. Users than can do export KOMPOSE_PROVIDER=openshift or export KOMPOSE_RC=true in their .bashrc.
Or if we don't want that than it can be preference file, but only think that it will do is change defaults, nothing more.

I don't think that we need complicate this with multiple profiles.

[ngtuna]

@kadel Yes I agree the preference file is now a bit of overcomplicating. The idea of this file originally happened during summer when @sebgoa would like to see a good way to switch between providers and default objects. But now kompose has changed a lot. So now we should again investigate the advantages and disadvantages of having a preference file and probably define an alternative solution.

• Advantages:

  • user get rid of typing flags
  • a good place for general settings of kompose. Which settings are general would probably be defined more in future but now we only have two settings: default objects and provider. Definitely we can apply ENV as @kadel mentioned above. I see it's commonly used.

• Disadvantages:

  • Overcomplicating by adding a file need to be managed -> We can dim it by introducing kompose setting command for example.

I'd like to take a look at the case user want to deploy composed-app to multiple k8s environments. Kompose is relying on kube config, that means he need to switch context first (by kubectl) prior to run kompose up. So, probably switching context would be a setting.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[surajssd]

I think this can be closed and need not be open anymore!

[cdrage]

@surajssd agreed.