Skip to content
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

Hostname lookup in debug and on/off setup #428

Merged
merged 7 commits into from Oct 2, 2019

Conversation

dabcoder
Copy link
Contributor

Attempts to address #416.

@dabcoder dabcoder requested a review from a team as a code owner August 16, 2019 14:51
@bkabrda
Copy link
Contributor

bkabrda commented Aug 19, 2019

I'm wondering whether it might be better to add an argument to get_hostname, e.g. def get_hostname(from_config=True), so that people using this from outside of the library could use it better (while preserving current behavior). Additionally, I see you added the argument to the docstring of initialize, but I don't actually see the argument there - perhaps you forgot about it?

@dabcoder
Copy link
Contributor Author

I'm wondering whether it might be better to add an argument to get_hostname, e.g. def get_hostname(from_config=True), so that people using this from outside of the library could use it better (while preserving current behavior).

That is a possibility, good point. Will look into that.

Additionally, I see you added the argument to the docstring of initialize, but I don't actually see the argument there - perhaps you forgot about it?

No I was looking at other optional arguments such as cacert:

:param cacert: Path to local certificate file used to verify SSL \
certificates. Can also be set to True (default) to use the systems \
certificate store, or False to skip SSL verification
:type cacert: path or boolean
but it's not used anywhere in the initialize method either, so was not sure how to reference it.

@bkabrda
Copy link
Contributor

bkabrda commented Aug 19, 2019

I'm not sure about the cacert specifically, but we should either:

  • Make this a global configuration variable and then not pass it to initialize.
  • Make this an argument to initialize, thus passing it to get_hostname, which is called inside initialize.

@dabcoder dabcoder force-pushed the davidb/hostname-from-agent-config branch from 1153e6f to c8a2b18 Compare August 20, 2019 08:21
@dabcoder dabcoder changed the title [WIP] Hostname lookup in debug and on/off setup Hostname lookup in debug and on/off setup Aug 23, 2019
@dabcoder dabcoder force-pushed the davidb/hostname-from-agent-config branch from 75660fd to c2de2ca Compare August 26, 2019 09:30
@apenney
Copy link

apenney commented Sep 25, 2019

Just a bump to ask how this one is going?

I was reminded this morning when adding a new log source and realizing I see over 250,000 of these errors a day in our logs.

Copy link
Contributor

@jd jd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clearly log.info was not a good choice here. :)

@apenney
Copy link

apenney commented Sep 25, 2019

You're the best!

Copy link
Contributor

@bkabrda bkabrda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the additional work, @dabcoder. Some points (trying to make my last comment clearer):

  • As mentioned in my previous comment, I'd prefer if this was configurable through initialize (so add a new argument hostname_from_config=True, so that users can set that to False and try what their app will do in future when we remove this completely.
  • I think the warning should be emitted on log.warning level, additionally recommending that the user should call initialize with hostname_from_config=False to get rid of this warning. This will make sure that users who want to get rid of this warning explicitly consent to not using config while users who want to keep trying to use the config will get warned when the config is not accessible.

Does that sound good to everyone? (@apenney would appreciate your feedback on this)

@@ -29,7 +29,7 @@
logging.getLogger('datadog.threadstats').addHandler(NullHandler())


def initialize(api_key=None, app_key=None, host_name=None, api_host=None,
def initialize(api_key=None, app_key=None, host_name=None, hostname_from_config=True, api_host=None,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd honestly put the new argument at the very end of the argument list, because it someone is doing right now initialize("xxx", "yyy", None, "some_api_host"), this would break their code. Optional arguments should always be added to the end.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Done in the last commit

datadog/__init__.py Show resolved Hide resolved
@bkabrda
Copy link
Contributor

bkabrda commented Oct 2, 2019

/azp run DataDog.datadogpy.integration

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Contributor

@bkabrda bkabrda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM now, merging. Thanks!

dabcoder pushed a commit to dabcoder/datadogpy that referenced this pull request Nov 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants