Defining applications in a single file

[concaf]

Looking at the examples, the only way I can see for defining multiple microservices, is by putting them in different files.

e.g. - https://github.com/surajssd/opencomposition/tree/master/examples/allnomagic here, db.yaml and web.yaml have to be separate files.

This is fine and good practice under certain scenarios, but I also want to be able to define this in a single file.

[pradeepto]

Any particular reason why you would want to define the whole thing in a single file? Advantages? Would this not lead to "more than "one true way" to do things scenario"?

[kadel]

I think its OK to force one file / one app way.

[concaf]

Having multiple files for different microservices makes no sense for smaller applications, that will just increase the user time.
We should be giving the user the choice to do whichever way they want, not what we think is correct for them.
I strongly disagree in enforcing one way for the user to structure their application, we should not be doing that, it should be left up to them. The tooling should be able to take in multiple files at the same time and do the conversion/deployment.

[kadel]

We can always add support for multiple apps in one file later.
Let's try to go with the one file one app for now.
If it's proven cumbersome we can always add support for it later.

[pradeepto]

But the whole point of James S was that we should write define one application/service per file. If we do it otherwise or keep that as a second priority, I am not sure how this serves the purpose.

[pradeepto]

Having multiple files for different microservices makes no sense for smaller applications, that will just increase the user time.

I can perhaps agree with that but ...

We should be giving the user the choice to do whichever way they want, not what we think is correct for them.

Being opinionated is very important.

I strongly disagree in enforcing one way for the user to structure their application, we should not be doing that, it should be left up to them.

We are enforcing other things, I am sure. So why not this bit?

[concaf]

@pradeepto -

But the whole point of James S was that we should write define one application/service per file. If we do it otherwise or keep that as a second priority, I am not sure how this serves the purpose.

Yes, he did, and I respectfully disagree.

We are enforcing other things, I am sure. So why not this bit?

We should not be enforcing everything.

IMHO, this is a huge step backward in terms of UX, we should let the users decide how they want to structure their application, and what fits best for their scenario, if they want to keep everything in the same file or they want put it in different version control. This increases my developer time by a lot if I have 2 small microservices, and I have to juggle between files.

Every spec that I know of provides a way to define multiple objects in one file, OpenShift templates, Docker Compose, OpenCompose.

[pradeepto]

OK. But doing multiple apps in multiple files shouldn't be a secondary requirement.

[concaf]

@pradeepto what does secondary requirement mean here?

[concaf]

let's decrease the priority and reconsider this later

[concaf]

or let's not! :)

One way can be that we support defining multiple services by separating with a ---, so a small file will look like -

name: web
containers:
- image: quay.io/tomkral/nonroot-nginx
services:
- ports:
  - port: 8080
---
name: db
containers:
- image: mongo
services:
- ports:
  - port: 3306

Thoughts on this? @pradeepto @kadel @surajssd

[kadel]

I still don't think that we have a good reason to do that.

But if we are doing it than what @containscafeine is suggesting is a good way to do it.

[surajssd]

One way can be that we support defining multiple services by separating with a ---, so a small file will look like -

@containscafeine 👍

[surajssd]

But having everything in one file is a bad idea, because:

• programmers are more comfortable with multiple files as opposed to single file having everything

• also it brings separation of concerns since each team will be working on their own micro-service which is part of whole application

• this brings in complications of how do we do conversion, should we convert everything each time or do we allow user a mechanism to say only convert this particular one app from list of apps

• since we don't need to create configs of database everytime but only of the app user is working on

• so with current approach we can do:

  • day0:

$ kapp convert -f db.yaml -f web.yaml | oc create -f -

- day1: when the app has changed

$ kapp convert -f web.yaml | oc apply -f -

• With new approach I don't know how this will happen maybe we will have to add flags that says only convert this particular app using some extra flag or something like that, not sure how this is improving UX in anyway.

[concaf]

@surajssd -

this brings in complications of how do we do conversion, should we convert everything each time or do we allow user a mechanism to say only convert this particular one app from list of apps

I think for this issue we should generate everything, and then specifying one particular app for generation should be covered separately, but I agree, it should be.

Also, I agree that this is not going to improve UX a lot, but this could be a use case, so let's go ahead and this. This will not be the preferred way of doing it, but one of the ways!

TODO:

• Open an issue to track specifying the app to generate k8s artifacts for, once this issue is implemented