EDS-D91BEM - Custom configuration per application ( Owner )

[medo-freiheit]

No description provided.

[hannesg]

🤔 I'm wondering how we will build additional features on top of this.

Do we plan to have notifications per team? Or cluster-per team? How would we build this on top of this?

Apart from this, please use consistent naming ( team or owner ).

[medo-freiheit]

I'm wondering how we will build additional features on top of this.

@hannesg, there will be a file let's call it Kuberpult-custom-config for each service ( optional ), it should be something like this :

{
"Owner": "team-name",
"feature1": "value1",
"featureN": "valueN",
}

this file will be sent using publish. sh whenever we release a new version.
However, the names of the features will be fixed and should be the same in the ApplicationConfig:

type ApplicationConfig struct {
	Owner string `json:"owner"`
}

[hannesg]

I'm wondering how we will build additional features on top of this.

@hannesg, there will be a file let's call it Kuberpult-custom-config for each service ( optional ), it should be something like this :

{
"Owner": "team-name",
"feature1": "value1",
"featureN": "valueN",
}

this file will be sent using publish. sh whenever we release a new version. However, the names of the features will be fixed and should be the same in the ApplicationConfig:

type ApplicationConfig struct {
	Owner string `json:"owner"`
}

I have some regards to that design.

I'm wondering how we will build additional features on top of this.

@hannesg, there will be a file let's call it Kuberpult-custom-config for each service ( optional ), it should be something like this :

{
"Owner": "team-name",
"feature1": "value1",
"featureN": "valueN",
}

this file will be sent using publish. sh whenever we release a new version. However, the names of the features will be fixed and should be the same in the ApplicationConfig:

type ApplicationConfig struct {
	Owner string `json:"owner"`
}

🤔 I think usually we want to have features per-team. Did you discuss namespaces already? I see that they incur more effort but it would fit much better to our (newer) monorepos where two teams can easily have the same service name without clashing. I would really like to move more in the direction of having one namespace per team.

[sven-urbanski-freiheit-com]

I'm wondering how we will build additional features on top of this.

@hannesg, there will be a file let's call it Kuberpult-custom-config for each service ( optional ), it should be something like this :

{
"Owner": "team-name",
"feature1": "value1",
"featureN": "valueN",
}

this file will be sent using publish. sh whenever we release a new version. However, the names of the features will be fixed and should be the same in the ApplicationConfig:

type ApplicationConfig struct {
	Owner string `json:"owner"`
}

I have some regards to that design.

I'm wondering how we will build additional features on top of this.

@hannesg, there will be a file let's call it Kuberpult-custom-config for each service ( optional ), it should be something like this :

{
"Owner": "team-name",
"feature1": "value1",
"featureN": "valueN",
}

this file will be sent using publish. sh whenever we release a new version. However, the names of the features will be fixed and should be the same in the ApplicationConfig:

type ApplicationConfig struct {
	Owner string `json:"owner"`
}

thinking I think usually we want to have features per-team. Did you discuss namespaces already? I see that they incur more effort but it would fit much better to our (newer) monorepos where two teams can easily have the same service name without clashing. I would really like to move more in the direction of having one namespace per team.

I don't agree that namespaces are really the way we want to go, or at least I don't see it as a priority.
Since we can't reach you right now, we will move on with how it is now (json structure), and then schedule a meeting with us three, to discuss what we really want to achieve in the future. I don't think one file per attribute is the way to go, it's just a lot of files that could be one.

[sven-urbanski-freiheit-com]

I'm wondering how we will build additional features on top of this.

@hannesg, there will be a file let's call it Kuberpult-custom-config for each service ( optional ), it should be something like this :

{
"Owner": "team-name",
"feature1": "value1",
"featureN": "valueN",
}

this file will be sent using publish. sh whenever we release a new version. However, the names of the features will be fixed and should be the same in the ApplicationConfig:

type ApplicationConfig struct {
	Owner string `json:"owner"`
}

I have some regards to that design.

I'm wondering how we will build additional features on top of this.

@hannesg, there will be a file let's call it Kuberpult-custom-config for each service ( optional ), it should be something like this :

{
"Owner": "team-name",
"feature1": "value1",
"featureN": "valueN",
}

this file will be sent using publish. sh whenever we release a new version. However, the names of the features will be fixed and should be the same in the ApplicationConfig:

type ApplicationConfig struct {
	Owner string `json:"owner"`
}

thinking I think usually we want to have features per-team. Did you discuss namespaces already? I see that they incur more effort but it would fit much better to our (newer) monorepos where two teams can easily have the same service name without clashing. I would really like to move more in the direction of having one namespace per team.

I don't agree that namespaces are really the way we want to go, or at least I don't see it as a priority. Since we can't reach you right now, we will move on with how it is now (json structure), and then schedule a meeting with us three, to discuss what we really want to achieve in the future. I don't think one file per attribute is the way to go, it's just a lot of files that could be one.

Summary of our discussion:

• We put the config (owner) in an individual file - this is easy to diff and also does not encourage the addition of features per service (we don't want too many)
• We will discuss namespaces at another point and if we decide to implement them, it will be in a different PR.