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

artursouza · 2020-03-13T21:28:08Z

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 · 2020-03-14T03:16:20Z

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 · 2020-03-14T20:19:07Z

@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 · 2020-03-14T21:14:28Z

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 · 2020-03-15T04:58:15Z

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 · 2020-03-17T18:54:35Z

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 · 2020-03-18T22:53:16Z

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 · 2020-03-19T14:54:30Z

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%2Fgit.luolix.top%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%2Fgit.luolix.top%2Fnotifications%2Funsubscribe-auth%2FAAA77CRJT4TYGCSBIGEGMMTRIFGGRANCNFSM4LHMMJAA&data=02%7C01%7C%7Ca70651618b7b4f424cc308d7cb8f2d02%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637201688101362379&sdata=C%2BVGR96P%2BT%2FE0JuC5rNO7IaCfAKJpDMLj%2F%2BcNBFwBCw%3D&reserved=0>.

wonderflow · 2020-03-22T02:51:59Z

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

artursouza · 2020-03-22T15:50:55Z

Yes. That is on me.

artursouza · 2020-03-24T18:10:34Z

Prior related work:
#185
#148

negz · 2020-03-24T18:30:23Z

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 · 2020-03-24T20:15:36Z

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 · 2020-03-24T20:36:20Z

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 · 2020-03-25T02:57:09Z

@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 · 2020-03-25T14:26:16Z

@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.

artursouza · 2020-03-25T14:28:07Z

I am on the same page as Haishi.

hongchaodeng · 2020-03-28T19:48:52Z

Is this PR: #342
originated from this issue?

artursouza · 2020-03-28T19:50:12Z

Related but Deployment is separate from Application.

hongchaodeng · 2020-03-28T19:59:42Z

Thanks for explaining.
Just in case let me rephrase again:

The Application is a construct that groups components and describes their topology
The Deployment is about runtime configuration of Application

ryanzhang-oss · 2020-04-02T06:41:03Z

Prior related work:
#185
#148

Please take a look at #336, it's very much related

resouer · 2020-09-20T18:31:40Z

Close in favor of #306

resouer mentioned this issue Mar 30, 2020

component should be mutable in alpha2 #343

Merged

resouer mentioned this issue Apr 15, 2020

Composing apps and their infra dependencies crossplane/crossplane#1163

Merged

This was referenced Apr 27, 2020

[Proposal] - introduction of Deployment #342

Open

Tracking remaining but notable issues in v1alpha2 release #353

Closed

resouer mentioned this issue May 9, 2020

Application and infrastructure composition crossplane/crossplane#1343

Closed

7 tasks

resouer added this to the v0.2.2 milestone Sep 20, 2020

resouer closed this as completed Sep 20, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

artursouza commented Mar 13, 2020

wonderflow commented Mar 14, 2020

artursouza commented Mar 14, 2020

Haishi2016 commented Mar 14, 2020

resouer commented Mar 15, 2020

artursouza commented Mar 17, 2020

Haishi2016 commented Mar 18, 2020

artursouza commented Mar 19, 2020 via email

wonderflow commented Mar 22, 2020

artursouza commented Mar 22, 2020

artursouza commented Mar 24, 2020

negz commented Mar 24, 2020

artursouza commented Mar 24, 2020

Haishi2016 commented Mar 24, 2020

hongchaodeng commented Mar 25, 2020

Haishi2016 commented Mar 25, 2020

artursouza commented Mar 25, 2020

hongchaodeng commented Mar 28, 2020

artursouza commented Mar 28, 2020

hongchaodeng commented Mar 28, 2020

ryanzhang-oss commented Apr 2, 2020

resouer commented Sep 20, 2020

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

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

Comments

artursouza commented Mar 13, 2020

Issue

Proposal

wonderflow commented Mar 14, 2020

artursouza commented Mar 14, 2020

Haishi2016 commented Mar 14, 2020

resouer commented Mar 15, 2020

artursouza commented Mar 17, 2020

Haishi2016 commented Mar 18, 2020

artursouza commented Mar 19, 2020 via email

wonderflow commented Mar 22, 2020

artursouza commented Mar 22, 2020

artursouza commented Mar 24, 2020

negz commented Mar 24, 2020

artursouza commented Mar 24, 2020

Haishi2016 commented Mar 24, 2020

hongchaodeng commented Mar 25, 2020

Haishi2016 commented Mar 25, 2020

artursouza commented Mar 25, 2020

hongchaodeng commented Mar 28, 2020

artursouza commented Mar 28, 2020

hongchaodeng commented Mar 28, 2020

ryanzhang-oss commented Apr 2, 2020

resouer commented Sep 20, 2020