-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LOG-1002: Add cloudwatch logforwarding type #839
LOG-1002: Add cloudwatch logforwarding type #839
Conversation
/hold |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
We may want to modify the naming and API but we should merge this as a first cut and work from there.
/retest |
@alanconway since the API is not firm here, I hesitate to merge because then that IS the API. I'm still working to create TP branches where we could merge this and call it beta. That's ultimately what I would most desire to deliver for ROSA unless we are confident in the api |
/lgtm cancel Here's the API enhancement proposal: openshift/enhancements#570 |
@alanconway review comments please |
LGTM but do we want to start the tech-preview branch for this? |
84fc4ac
to
a5e2f9f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, minor changes requested.
} | ||
func (conf *outputLabelConf) LogGroupPrefix() string { | ||
if conf.Target.Type == logging.OutputTypeCloudwatch { | ||
prefix := conf.Target.Cloudwatch.GroupPrefix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Put the TrimSpace here so we check for "" and use the trimmed value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe I can do that without losing the ability to treat the following as different cases:
- nil = use default
- non-nil and not empty = use value
remove_log_group_name_key true | ||
auto_create_stream true | ||
concurrency 2 | ||
aws_key_id "#{open('{{ .SecretPath "aws_access_key_id"}}','r') do |f|f.read end}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only set this if the key is found, otherwise we'll have a new crash loop when its missing. Here's what I did for the general TLS stuff:
{{- with $path := .SecretPathIfFound "tls.key"}}
tls_client_private_key_path "{{$path}}"
{{- end}}
Also if these keys are required, they should be checked as part of VerifyOutputSecret, but only for cloudwatch outputs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are absolutely required for the plugin to work. Will the generator code prior to the template successfully skip output generation for missing secrets?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added
|
||
//CLFVerifier is a collection of functions to control verification | ||
//of ClusterLogForwarding | ||
CLFVerifier ClusterLogForwarderVerifier |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this is the best approach. We need to customize the verify behavior per-output, not for the whole forwarder,
Perhaps a map of map[string]VerifyFunc = { "cloudwatch": ...; "kafka": ... }, so Normalize can call the right verify func for each output type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was added to allow the internal config generator bin to work without being connected to the cluster and really is not intended to be used otherwise. We can repurpose it if needed but ATM I don't meet the need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, understood. However we still need different secret verification for cloudwatch (needs "aws_...") vs. other TLS outputs. We could have a global map of verify functions keyed by output type, and have output types with special needs put a function in the map that the validation code will call if not nil. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure. if that is needed seems reasonable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not needed for this PR. This is OK
/hold cancel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alanconway, igor-karpukhin, jcantrill The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
LOG-1002: Add cloudwatch logforwarding type
Description
This PR add logforwarding to Cloudwatch capabilities
/cc @igor-karpukhin
/assign @alanconway
Links
https://issues.redhat.com/browse/LOG-1002
/hold