discuss: ApisixRoute change struct

[gxthrj]

No description provided.

[tokers]

The ApisixRoute should leverage the advantages of APISIX Routes as soon as possible, for instance, the flexible route match, native plugins support.

apiVersion: apisix.apache.org/v2alpha1
kind: ApisixRoute
metadata:
  name: httpbin-route
spec:
  http:
    - priority: 10
      name: rule1
       match:
         paths:
           - "/a"
           - "/bb*"
         methods:
          - GET
          - POST
        hosts:
          - a.com
          - aa.com
        remote_addrs:
          - 192.168.1.0/24
          - 10.0.5.12
        nginxVars:
          - subject: "$remote_addr"
            op: in
            array:
                - 127.0.0.1
                -  10.0.5.11
      backend:
        serviceName: httpbin
        servicePort: 8080
        resolveGranularity: endpoint # by default is endpoint, optional value can be "service".
      plugins:
        - name: redirect
           enable: true
           config:
             aaa: bbb
             ccc: ddd

The scripts are used by plugin orchestration, we don't use it.

[tokers]

@gxthrj

[gxthrj]

I think it might be a good idea to keep the pathtype, the structure is more expressive than *, and it will be easy to expand

[gxthrj]

Are priority and match the same level ?

[gxthrj]

I think it is more readable using upstream instead of route
Such as

upstream:
  serviceName: xxx
  servicePort: xxx

[tokers]

I think it is more readable using upstream instead of route

Such as

upstream:

  serviceName: xxx

  servicePort: xxx

Might as well. The route here is a verb.

[tokers]

Are priority and match the same level ?

Yep.

[tokers]

I think it is more readable using upstream instead of route
Such as

upstream:

  serviceName: xxx

  servicePort: xxx

Might as well. The route here is a verb.

What about backend? Just like Ingress.

[tokers]

I think it might be a good idea to keep the pathtype, the structure is more expressive than *, and it will be easy to expand

Well, I think anyone who uses Linux is familiar with "*"; Also, I think we don't need to consider the extensibility now, it depends on Apache APISIX's iteration and if so, just use a new version of ApisixRoute.

[gxthrj]

I think it is more readable using upstream instead of route
Such as

upstream:

  serviceName: xxx

  servicePort: xxx

Might as well. The route here is a verb.

What about backend? Just like Ingress.

Agreee

[gxthrj]

We need a field to specify whether to use pod IP or cluster service.

[tokers]

We need a field to specify whether to use pod IP or cluster service.

We always use Cluster Service, why we need this field?

[gxthrj]

We need a field to specify whether to use pod IP or cluster service.

We always use Cluster Service, why we need this field?

I mean is to give users the ability to choose whether to automatically register the pod IP.
The difference is that the node under upstream in APISIX is the pod IP or the cluster server name.

[tokers]

We need a field to specify whether to use pod IP or cluster service.

We always use Cluster Service, why we need this field?

I mean is to give users the ability to choose whether to automatically register the pod IP.

The difference is that the node under upstream in APISIX is the pod IP or the cluster server name.

What is automatically register pod ip? What can we get from it?

[gxthrj]

I mean to give users a choice, use clusterip or POD IP

[tokers]

I mean to give users a choice, use clusterip or POD IP

Got it.

[pioneer-hash]

Will the routing rules under Ingress be the same as the standard version of Apisix?

[tokers]

Will the routing rules under Ingress be the same as the standard version of Apisix?

Sure~.

[pioneer-hash]

Is there any progress on Apisix-Route？

[tokers]

@pioneer-hash See #262 for more details.