Add 'ingress' as core trait

[clareliguori]

As per conversation on https://github.com/oam-dev/spec/issues/299, this issue proposes adding 'ingress' as a core trait. Ingress feels widely applicable to many types of platforms and feels core to deploying many applications' Server components.

[vturecek]

@clareliguori thanks for bringing this up. I agree ingress is widely applicable. It's difficult to imagine a useful cloud-native implementation of OAM that doesn't have an ingress trait. But let me try to provide some counterpoints to making it a core trait as well as some alternative ideas, and see what you and others think.

Just so we have a shared understanding, core traits are currently defined as traits that MUST be implemented by a runtime as defined in the spec in order to be OAM-compliant.

With that, my biggest hesitation to making ingress a core trait is when considering implementations that are not cloud-native platforms. One of the goals of OAM is an application model that works anywhere. An OAM-compliant runtime for embedded devices could be one example where ingress is not needed or desirable.

Second, as a core trait, it would force all implementations to adopt the same set of configuration properties for ingress. I'm less hesitant about this because I do think there's some upside to having a prescriptive, consistent configuration for ingress, and implementations are still free to provide their own ingress traits in addition to a core ingress trait.

To say that every implementation MUST implement a trait with a specific schema (or workload type, or scope), without knowing what sort of runtimes will come in the future, carries a lot of weight. That's why we've initially said that the only traits that are required are those that are needed to support core workloads (like manual scaler, without which, the scaleable core workload types can't be scaled!).

So one alternative is to define a standard trait for ingress. It would not require OAM-compliant runtimes to use it, but it would urge implementations that do have an ingress to standardize on a consistent schema.

Curious to hear your thoughts on this. It's possible a "graduation program" could be the answer, whereby a trait graduates from extended to standard and finally to core if it turns out to be ubiquitous enough.

[wonderflow]

I agree make ingress as core trait.

An OAM-compliant runtime for embedded devices could be one example where ingress is not needed or desirable

In this case, the runtime also don't need Server as a core workload, but we already added six core workload types.

IMO, setting core workload and core trait is to make sure most of the common application pattern can be widely run in different platforms. So the less we define in core, OAM spec will be less useful in practice. While I have to admit we must be cautious to make sure the Spec can be widely adopted in different runtimes.

@clareliguori On the other hand, I'm really curious about your scenario on OAM, how do you use it? Is it high priority for your case to decide core things? Maybe we could give more help with this information.

[clareliguori]

This is not high priority for me and I don't have strong opinions about what Ingress should look like. I've just been playing around with OAM, seeing what it would take to translate OAM types into ECS resource types. I noticed that some of the traits implemented by Rudr weren't in the spec, so I wanted to raise that just in case they were overlooked when the spec was written. :)

[Haishi2016]

I agree with @wonderflow on making it a core trait. As he's stated, OAM spec will be less useful in practice unless OAM provides enough abstract for describing an application. And these abstractions are where OAM's value resides.

And I think it's justifiable for a particular implementation to decide if a trait leads to a null operation on the platform. The difference is that the intention is captured in the app model so that it can be materialized when possible, and ignored when it's irrelevant.