Comments (32)
+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.
from kompose.
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
from kompose.
@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?
from kompose.
@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.
from kompose.
@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)?
from kompose.
@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.
from kompose.
@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.
from kompose.
@ngtuna sure that example file is a great reference, on which I can base my work on! We can add more things going forward!
from kompose.
@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
from kompose.
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
from kompose.
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?
from kompose.
yaml or .ini file...
from kompose.
cool i will start working with yaml
as our input file, thanks!
from kompose.
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.
from kompose.
I don't think that ini is that easier on user compared to simple yaml.
ok
from kompose.
About this one more question,
- Where is this file situated? Is it similar to Kubernetes(
~/.kube/config
) like a~/.kompose/config
? or~/.kompose/defaults
from kompose.
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.
from kompose.
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.
from kompose.
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.
from kompose.
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
from kompose.
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.
from kompose.
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?
from kompose.
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.
from kompose.
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.
from kompose.
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.
from kompose.
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.
from kompose.
Ah... we still have #154 for the labels...
from kompose.
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.
from kompose.
@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.
- Overcomplicating by adding a file need to be managed -> We can dim it by introducing
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.
from kompose.
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
from kompose.
I think this can be closed and need not be open anymore!
from kompose.
@surajssd agreed.
from kompose.
Related Issues (20)
- [BUG] Unable to process YAML 1.2 files HOT 3
- [BUG] with-kompose-annotation=false not working in 1.30.0
- [BUG] v1.31.0 build failed HOT 6
- Remove Helm support HOT 3
- Improve --help pages
- Spelling / grammar / examples in the flag commands HOT 5
- [BUG] Following quickstart docs leads to panic HOT 3
- [BUG] .deb/rpm files no longer generated in releases HOT 1
- [BUG] COMPOSE_FILE env var is not honored HOT 1
- Do not add 'namespace: default' by default
- [BUG] Unit tests currently failing HOT 1
- Clean up the terminal output / add emojis / remove [INFO] HOT 5
- [BUG] Generated ConfigMap name too long HOT 4
- Add test for PR 1743
- [BUG] Kompose should raise and error when profiles are required HOT 8
- [BUG] escape double curly braces when converting to configmap HOT 1
- [BUG] main example isn't working for compose HOT 3
- Remove other useless keys in output HOT 2
- What is `io.kompose.network`? HOT 1
- [BUG] changelong not updated for multiple release HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kompose.