Skip to content

Conversation

@marcaurele
Copy link
Contributor

I would like to propose a change to move the prometheus_multiproc_dir env variable in upper case to follow the convention of such variable. It feels strange to have to declare it in lower case.

The code adds a deprecation warning to inform the user about the change and transform it to upper case if needed. It also take care of precedence in case both are declared.

Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
@marcaurele
Copy link
Contributor Author

cc @csmarchbanks

Copy link
Member

@csmarchbanks csmarchbanks left a comment

Choose a reason for hiding this comment

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

Thank you for your contribution!

I think accepting an upper case environment variable certainly makes sense. However, I am not sure we need to deprecate the lower case version though as it is still valid. I don't have a windows machine to test on right now, but is there any concern about case insensitivity?

Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
marcaurele added a commit to marcaurele/client_python that referenced this pull request Feb 14, 2021
Following PR prometheus#624

Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
if 'prometheus_multiproc_dir' in os.environ:
if 'prometheus_multiproc_dir' in os.environ and 'PROMETHEUS_MULTIPROC_DIR' not in os.environ:
os.environ['PROMETHEUS_MULTIPROC_DIR'] = os.environ['prometheus_multiproc_dir']
warnings.warn("You should declare the env variable in upper case PROMETHEUS_MULTIPROC_DIR'", DeprecationWarning)
Copy link
Member

Choose a reason for hiding this comment

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

Looks like I left a comment about the warnings in the overall comment instead of a specific one.

My inclination is to allow either lower or upper case without any deprecation warnings as both are valid. Do you have any concerns with just allowing either?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would like to encourage people to use the upper case to follow standard practice in Unix env variables. If we don't put that in the readme, we don't say anything in the code to promote the use of the uppercase I don't see how people will move to that variable name in upper case.

Copy link
Member

Choose a reason for hiding this comment

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

That seems reasonable, let's keep the deprecation notice. I do plan to merge your README change after I do a release with this change as well.

Copy link
Member

@csmarchbanks csmarchbanks 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 reasoning on the deprecation notice. I did a bit of testing and found one concern.

if 'prometheus_multiproc_dir' in os.environ:
if 'prometheus_multiproc_dir' in os.environ and 'PROMETHEUS_MULTIPROC_DIR' not in os.environ:
os.environ['PROMETHEUS_MULTIPROC_DIR'] = os.environ['prometheus_multiproc_dir']
warnings.warn("You should declare the env variable in upper case PROMETHEUS_MULTIPROC_DIR'", DeprecationWarning)
Copy link
Member

Choose a reason for hiding this comment

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

That seems reasonable, let's keep the deprecation notice. I do plan to merge your README change after I do a release with this change as well.

In case people use directly `MultiProcessValue`, the deprecation
warning will pop up.

Added another warning if both are defined.

Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
thanks to @csmarchbanks

Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
Copy link
Member

@csmarchbanks csmarchbanks left a comment

Choose a reason for hiding this comment

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

Nice work, I noticed a couple extra characters in the warnings, and came across one edge case in testing. Curious on your thoughts there, if it would be too complex I think the current behavior is fine.

def __init__(self, typ, metric_name, name, labelnames, labelvalues, multiprocess_mode='', **kwargs):
self._params = typ, metric_name, name, labelnames, labelvalues, multiprocess_mode
# This deprecation warning can go away in a few releases when removing the compatibility
if 'prometheus_multiproc_dir' in os.environ and 'PROMETHEUS_MULTIPROC_DIR' in os.environ:
Copy link
Member

Choose a reason for hiding this comment

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

If I instantiate multiple metrics, I end up getting both warnings because this clause is triggered on the second metric after the capital environment variable is set. Is there a good way to not get two warnings in that case? Here is a quick example:

from prometheus_client import generate_latest, CollectorRegistry, multiprocess, Gauge

registry = CollectorRegistry()
multiprocess.MultiProcessCollector(registry)

Gauge('metric_1', 'First metric', registry=registry)
Gauge('metric_2', 'Second metric', registry=registry)

Since they are just warnings, not a big deal, but it is a bit confusing.

One option would be to always warn if the lowercase is set, then only replace if the capitalized version is not set? Users with both set would only get the You should declare the env variable in upper case PROMETHEUS_MULTIPROC_DIR in that case.

Copy link
Contributor Author

@marcaurele marcaurele Mar 2, 2021

Choose a reason for hiding this comment

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

Yes, correct. I'd rather display the warning for the ones whom only defined the variable in lowercase. I'll the corresponding lines.

Copy link
Member

Choose a reason for hiding this comment

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

👍 Sounds good, let me know once that is complete and I will test again.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Have a look. I also change the message on the deprecation warning as it did not sound so much as one. I think the wording is much better now. Don't hesitate if you have any other proposal to do.

Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
It does not trigger a deprecation warning anymore.

Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
Remove the warning when both are used and rephrase the message to be
more deprecation aware.

Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
Copy link
Member

@csmarchbanks csmarchbanks left a comment

Choose a reason for hiding this comment

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

The new messaging looks good to me. I don't know how I missed it in my previous tests but there are a few places in prometheus_client/multiprocess.py where prometheus_multiproc_dir is still used. Specifically, when creating a MultiProcessCollector, and during mark_process_dead. Those will need to be updated too. Sorry about missing that earlier and needing extra revisions!

It looks like the tests are passing only because self.tempdir is passed in as a path rather than the default of None. It might be worth having a test case for the None scenario as well.

Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
Signed-off-by: Marc-Aurèle Brothier <m@brothier.org>
@marcaurele
Copy link
Contributor Author

@csmarchbanks you can do your tests again. Let me know if there's anything else that needs to be changed.

Copy link
Member

@csmarchbanks csmarchbanks left a comment

Choose a reason for hiding this comment

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

Awesome, I ran through my tests again and this is looking good. Thanks for all the work!

@csmarchbanks csmarchbanks merged commit f22d38f into prometheus:master Apr 2, 2021
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.

2 participants