Doc bug: need more complete description of Ingress

[omkensey]

Describe the bug
Ingress trait and ComponentSchematic documentation are not clear on some things about using Ingress, such as:

• how to front multiple ComponentSchematics with a single ingress
• how to most compactly define multiple Ingress paths that apply to the same ApplicationConfig
• how to indicate that an Ingress path should apply to any hostname

Specifically, I'm trying to recreate the Istio BookInfo demo as a Rudr app definition. I can easily create a Kubernetes Ingress to do what's desired, as below:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: bookinfo
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /login
        pathType: Exact
        backend:
          serviceName: productpage
          servicePort: 9080
      - path: /logout
        pathType: Exact
        backend:
          serviceName: productpage
          servicePort: 9080
      - path: /productpage
        pathType: Exact
        backend:
          serviceName: productpage
          servicePort: 9080
      - path: /static
        pathType: Prefix
        backend:
          serviceName: productpage
          servicePort: 9080
      - path: /api/v1/products
        pathType: Prefix
        backend:
          serviceName: productpage
          servicePort: 9080

but the BookInfo app depends on various Services existing as well, some of which (reviews) have selectors that select pods from multiple Deployments. It's not clear whether I can just define them as separate ComponentSchematics and then reference them all from a single ApplicationConfig somehow, or if I need to do something different, or if this is not actually (currently) possible to define in OAM and/or Rudr.

[resouer]

@omkensey Hi Joe, the OAM spec has been released to v1alpha2 which is slightly different, for example, ComponentSchematic is gone :-) Please check this slides for a diff.

The recommend k8s implementation of OAM v1alpha2 is Crossplane project, and here's a quick installation guide for you getting started:

Would you mind to play with Crossplane and migrate further issue to https://github.com/crossplane/crossplane/issues?

One possible issue could be:

some of which (reviews) have selectors that select pods from multiple Deployments

This will need to be modeled by Scope, while Scope is currently not implemented in Crossplane (yet).

[resouer]

In general, traffic mgmt related apps like BookInfo should be able to be modeled easily with OAM.

The mapping would be:

• Component - Deployment
• Trait - Service/Ingress per Deployment
• Scope - Service/Ingress/APIGateway across Deployments
• ApplicationConfiguration - a YAML file to grouping Component/Trait/Scope together

We will start working on implementing Scope in Crossplane ASAP, and at the meantime, it would be grateful if you can try to category BookInfo API resources into the OAM objects above.

Note that in v1alpha2, OAM defines K8s resource directly in YAML files, please heck this example.