Logging operator contract abstraction

[mdemirhan]

We are currently exposing fluentd config as part of our operator contracts to allow plugging in different logging backends. This is approach will make it harder for us to move to a different collection agent in the future - changing agents will not be seamless and will require cluster operators to take action.

We should re-evaluate this decision before the product is v1. The other option is:

• Create a config of our own as part of operator contracts and let the operator edit our config. Our system needs to generate the appropriate fluentd config (or whatever agent we are using) based on this
• Define a "plugin author" contract and allow contributors to add support for more backends

[loganlee]

I support this idea. I believe that even if fluentd is a dominant pattern, this is an appropriate abstraction point to allow alternatives.

…

On Thu, May 17, 2018 at 11:46 AM Mustafa Demirhan ***@***.***> wrote: We are currently exposing fluentd config as part of our operator contracts to allow plugging in different logging backends. This is approach will make it harder for us to move to a different collection agent in the future - changing agents will not be seamless and will require cluster operators to take action. We should re-evaluate this decision before the product is v1. The other option is: - Create a config of our own as part of operator contracts and let the operator edit our config. Our system needs to generate the appropriate fluentd config (or whatever agent we are using) based on this - Define a "plugin author" contract and allow contributors to add support for more backends — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#906>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACTWN7vXkm08-TUe0jipIRN3AQ1dyc0Cks5tzcVmgaJpZM4UDlTE> .

-- *Logan Lee | Senior **Director, Product Management* lolee@pivotal.io *|* *+1-415-713-9894 **|* *pivotal.io <http://www.pivotal.io/>*

[evankanderson]

/kind spec

I see two PRs were merged, is this done?

[evankanderson]

/assign mdemirhan
/assign loganlee

[yanweiguo]

The tow merged PRs are relative. This is not done yet.

[knative-housekeeping-robot]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

[knative-housekeeping-robot]

Stale issues rot after 30 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.
Rotten issues close after an additional 30 days of inactivity.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle rotten

[knative-housekeeping-robot]

Rotten issues close after 30 days of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/close

[knative-prow-robot]

@knative-housekeeping-robot: Closing this issue.

In response to this:

Rotten issues close after 30 days of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.