Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

New TrafficLog design (new name: MeshLogging) #4733

Closed
lahabana opened this issue Aug 2, 2022 · 3 comments · Fixed by #4908
Closed

New TrafficLog design (new name: MeshLogging) #4733

lahabana opened this issue Aug 2, 2022 · 3 comments · Fixed by #4908
Assignees
Labels
area/policies kind/design Design doc or related triage/accepted The issue was reviewed and is complete enough to start working on it

Comments

@lahabana
Copy link
Contributor

lahabana commented Aug 2, 2022

Description

Rebuild traffic log to have it work with the new selectors.

Open questions:

@lahabana lahabana added triage/pending This issue will be looked at on the next triage meeting kind/design Design doc or related triage/accepted The issue was reviewed and is complete enough to start working on it area/policies and removed triage/pending This issue will be looked at on the next triage meeting labels Aug 2, 2022
This was referenced Aug 2, 2022
@slonka slonka changed the title New TrafficLog design New TrafficLog design (new name: MeshLogging) Aug 25, 2022
@slonka
Copy link
Contributor

slonka commented Aug 30, 2022

@lahabana - could you explain how inlining would make it easier to have per zone backends?

should the backends be inlined in the policy? This would make it easier to have per zone backends.

FYI @lobkovilya

@lahabana
Copy link
Contributor Author

Because you define a policy:

name: log-zone-a
spec:
   targetRef:
      type: proxySubset
      tags:
        kuma.io/zone: foo
    to:
       - targetRef:
            type: mesh
          default:
             backend: my-zone-specific-backend 

@slonka
Copy link
Contributor

slonka commented Aug 31, 2022

I'm still not sure. It's this:

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  logging:
    backends:
      - name: logstash-zone-a
        type: tcp
        conf:
          address: 127.0.0.1:5000
      - name: logstash-zone-b
        type: tcp
        conf:
          address: 127.0.0.2:5000
---
type: MeshLogging
mesh: default
name: log-zone-a
spec:
  targetRef:
    kind: MeshSubset
    tags:
      kuma.io/zone: zone-a
  from:
    - targetRef:
        kind: Mesh
        name: default
      default:
        backends:
          - logstash-zone-a
---
type: MeshLogging
mesh: default
name: log-zone-b
spec:
  targetRef:
    kind: MeshSubset
    tags:
      kuma.io/zone: zone-b
  from:
    - targetRef:
        kind: Mesh
        name: default
      default:
        backends:
          - logstash-zone-b

vs this:

type: MeshLogging
mesh: default
name: log-zone-a
spec:
  targetRef:
    kind: MeshSubset
    tags:
      kuma.io/zone: zone-a
  from:
    - targetRef:
        kind: Mesh
        name: default
      default:
        backends:
          - name: logstash-zone-a
            type: tcp
            conf:
              address: 127.0.0.1:5000
---
type: MeshLogging
mesh: default
name: log-zone-b
spec:
  targetRef:
    kind: MeshSubset
    tags:
      kuma.io/zone: zone-b
  from:
    - targetRef:
        kind: Mesh
        name: default
      default:
        backends:
          - name: logstash-zone-b
            type: tcp
            conf:
              address: 127.0.0.2:5000

how is one easier than the other? or, is my example wrong?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
area/policies kind/design Design doc or related triage/accepted The issue was reviewed and is complete enough to start working on it
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants