How can a developer represent the application prior to application configuration?

[artursouza]

Issue

A developer defines the components, on the other hand, an application is composed of multiple components (usually microservices). The only place where components are grouped together is at the ApplicationConfiguration, which is supposed to be authored by ops team.

Proposal

Create a new concept, called "Application" that will be a way to define a set of components (without traits or param values or scopes). Then, ApplicationConfiguration references the Application and provides all required params and (probably) also add traits and scopes. If the ApplicationConfiguration does not specify one of the components because there is no trait or params to be added, the component is still considered as part of the ApplicationConfiguration since it refers the Application.

[wonderflow]

Could you give a real case why a developer want to define a set of components (especially without traits or param values or scopes)?

In our cloud team, we really feel application configuration not enough, but that's not for developer. Because we have multiple clusters and multiple availability zones, while application configuration can only used in one cluster. So in my view, the new concept Application should leave for that multiple cluster case.

[artursouza]

@wonderflow It might be different things. What you are describing (correct me if I am wrong here) is to have some sort of ApplicationConfigurationTemplate, where some params can be defined in an ApplicationConfiguration. Then each cluster would be a different ApplicationConfiguration for the same ApplicationConfigurationTemplate.

My initial proposal is more dev oriented. In the example of a developer to build an application with 4 different components. The application does not work with only 3 of those, must be all 4. So, the developer could define an Application (without traits or scopes) that says these 4 component together defines Application A. This way, when the app operator is creating an ApplicationConfiguration, all the components for the app are automatically inherited. Only traits, scopes and params must be defined.

[Haishi2016]

I agree the Application object should be dev oriented. It should provide an abstract modeling langauge for developers to design the topology of their applications. In my mind, the Application object won't be a generic model that can include everything. Instead, it shall be an opinionated model that abstract common construct of a distributed application. For instance, ingress, scaling limitations, network scopes, as well as sites (for multi-site applications) should be built-in attributes of the Application model. Then, at operation time, operations can decide to attach traits to these properties to realize how the developer intention is fulfilled.

This allows us to have a clear separation - all the developer ever needs to touch is the Application object. Application describes the application topology, a responsibility that is currently mixed into ApplicationConfiguration. Once this is separated out, ApplicationConfiguration is purely for configuration overrides, as it should have been.

ApplicationConfiguration also serves as a Deployment, a concept I think we should separate out by itself. A Deployment can be a single component or an Application, which can be associated with an optional ApplicationConfiguration.

A separate Deployment object make tricky things like canary deployment natural - we can simply define a Deployment that includes two Application versions and then associate traffic shaping policy on it. This kind of deployment is hard to express without a separate Deployment concept.

[resouer]

In addition, Application object will be descriptor for app metadata, i.e. author/maintainer, name, release/version of the app. xref: app crd in kube. I'm generally in favor of this idea.

[artursouza]

I am not sure if Application should be aware of Traits like (ingress, scaling) or scopes (network, health) since it crosses the line (IMO) between dev and ops. I see Application as a formal description of the application's architecture, prior to bringing deployment related concepts. If we bring all these concepts to Application, then it will be almost a copy and paste of ApplicationConfiguration - giving ops just the chance to populate params.

[Haishi2016]

The Application should NOT know about traits. These will be abstracts that we offer. And these abstracts will be the key value the application model contributes to the community. This is definitely not copy&paste. Otherwise, if you think about it, the OAM application is a collection of things that you can attach additional things. It's very generic and extensible for sure. But we are lacking of modeling language that allow user can describe their application topology in a platform-agnostic way with high precision - instead of making assumptions on how particular traits, or even implementations of traits, work.

[artursouza]

I agree with Haishi’s points. Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Haishi2016 <notifications@github.com> Sent: Wednesday, March 18, 2020 3:53:28 PM To: oam-dev/spec <spec@noreply.github.com> Cc: Artur Souza <artursouza.ms@outlook.com>; Author <author@noreply.github.com> Subject: Re: [oam-dev/spec] How can a developer represent the application prior to application configuration? (#334) The Application should NOT know about traits. These will be abstracts that we offer. And these abstracts will be the key value the application model contributes to the community. This is definitely not copy&paste. Otherwise, if you think about it, the OAM application is a collection of things that you can attach additional things. It's very generic and extensible for sure. But we are lacking of modeling language that allow user can describe their application topology in a platform-agnostic way with high precision - instead of making assumptions on how particular traits, or even implementations of traits, work. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foam-dev%2Fspec%2Fissues%2F334%23issuecomment-600898332&data=02%7C01%7C%7Ca70651618b7b4f424cc308d7cb8f2d02%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637201688101352370&sdata=NxxPQHPhYhBq52pkfAoim15v9tiu%2FWvJQ%2B%2FSuTBrAwo%3D&reserved=0>, or unsubscribe<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAA77CRJT4TYGCSBIGEGMMTRIFGGRANCNFSM4LHMMJAA&data=02%7C01%7C%7Ca70651618b7b4f424cc308d7cb8f2d02%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637201688101362379&sdata=C%2BVGR96P%2BT%2FE0JuC5rNO7IaCfAKJpDMLj%2F%2BcNBFwBCw%3D&reserved=0>.

[wonderflow]

Could someone draft a proposal for it? Including some cases and YAML examples, then we could understand and discuss deeply.

[artursouza]

Yes. That is on me.

[artursouza]

Prior related work:
#185
#148

[negz]

I wonder if we could do this with something like a simple label selector?

---
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: cool-component-a
  labels:
    app: coolapp
---
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: cool-component-b
  labels:
    app: coolapp
---
# This new object kind helps discover groups of components.
apiVersion: core.oam.dev/v1alpha2
kind: ComponentGroup  # Probably needs a better name.
metadata:
  name: cool-components
spec:
  componentSelector:
    matchLabels:
      app: coolapp

[artursouza]

It can work. I am concerned about the double reference - the group and the components need to know the labels. I was thinking about a solution where component can be reused and shared without any dependency with the layer above (group or application or whatever we decide to be)

[Haishi2016]

I generally lean towards a single application manifest deploying the whole topology as the single source of truth. Scattering truth to more places make things like version management difficult.

[hongchaodeng]

@Haishi2016
Are you proposing that we would have ApplicationModel which dev uses:

kind: ApplicationModel
spec:
  componnets:
  - name: a
  - name: b

Then ops defines ApplicationConfiguration:

kind: ApplicationConfiguration
spec:
  componnets:
  - name: a
    paramValues: ...
    traits: ...
  - name: b

Right?

[Haishi2016]

@hongchaodeng Yes, along those lines. I also think the ApplicationModel can define parameters with default values, and ApplicationConfiguration can override them. I'll work with @artursouza to come up with a proposal for feedback.