component: add external resource definition

[hongchaodeng]

This PR tries to address dependency problems of external resources. Specifically, cloud resources, k8s resources, even Hydra components that a user application depends on.

The justification for this new definition is that, in current spec, only extended workload touched it a little bit, but many resources aren't workload -- e.g. k8s namespace. Secondly, we want to model it as component's dependencies to make it component centric -- look at the example in the PR.

I add a flat layer of resources under component. Another option would be to define a new type called ResourceType -- In that way, we can have Resource decoupled and make common resource types like Database, Object Storage Bucket, etc.

[mikkelhegn]

Extended workload types were meant to solve this: https://github.com/microsoft/hydra-spec/blob/master/3.component_model.md#extended-workload-types. Why does this concept not fulfill your requirements?

To comment on the examples, I think some could also be placed differently in the model:

• kube-namespace --> Application Scope
• dns --> Trait (if it's external, it woudl be together with an ingress trait)
  Why would these not work?

Regarding the Hydra-component dependency, can you give an example of a use case, and how the runtime should fulfill this? Today every component in the same ApplicationsConfiguration will be deployed together.

[resouer]

@hongchaodeng

I have similar concern.

The "external resources" should be defined by Hydra types, leaking platform/runtime concepts to app level is the last thing we want to see.

Also, I'm worrying about this change could break the fundamental model of Hydra, just imagine a user define everything as "external resources" here, no traits, no application scope.

If I understand correctly, the main purpose of this proposal is: accounting all resources related to given application (dependency is one of them).

I think it's partially in scope of #95, one general direction in my mind is.

1. Use Hydra types to define the resources for an application as possible;
2. Use Application Scope to account these resources.

If there's some resource in your mind can not be covered, we may want to create another issue for discussion.

[hongchaodeng]

@mikkelhegn Thanks for your reply.

After some internal discussion, we identified some issues in this PR. Nonetheless, there are use cases that are non-Workload/Trait/AppScope.

Let me collect the use cases and create an issue first. We will provide better context and examples to ignite further discussion.

[mikkelhegn]

Sounds good - closing this for now.