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

Test urllib3 1.22 w/ ElasticSearch #481

Closed
jwhitlock opened this Issue Sep 14, 2017 · 1 comment

Comments

Projects
2 participants
@jwhitlock
Contributor

jwhitlock commented Sep 14, 2017

mozilla/kuma#4425 upgrades urllib3 to 1.22, which checks SSL connections against the OS certificate chain. Ensure that our worker and web containers continue to communicate w/ hosted ElasticSearch after this upgrade.

@jwhitlock jwhitlock created this issue from a note in MDN AWS Migration (Backlog) Sep 14, 2017

@jwhitlock jwhitlock added the MDN label Sep 14, 2017

@escattone escattone self-assigned this Sep 15, 2017

@escattone escattone moved this from Backlog to In Progress (Max 6) in MDN AWS Migration Sep 15, 2017

@escattone

This comment has been minimized.

Show comment
Hide comment
@escattone

escattone Sep 15, 2017

Member

Verified that the Kuma-based containers (web, api, celery workers, etc.) deployed to mdn-stage (https://mdn-mm.moz.works) are using urllib3 version 1.22:

rjohnson-25186:k8s rjohnson$ kc get pods -n mdn-stage
NAME                             READY     STATUS    RESTARTS   AGE
api-3013948324-fgbpl             1/1       Running   0          1h
celery-beat-1326174911-6f59l     1/1       Running   0          1h
celery-cam-811570164-z18hg       1/1       Running   0          1h
celery-worker-2947925456-6nvcd   1/1       Running   0          1h
kumascript-1576521443-6rbkt      1/1       Running   0          1h
mdn-admin-3097159426-3hbxz       1/1       Running   0          1d
mdn-anon                         1/1       Running   0          1d
web-288507684-d0wmj              1/1       Running   0          1h

rjohnson-25186:k8s rjohnson$ kc exec -n mdn-stage -it web-288507684-d0wmj bash
kuma@web-288507684-d0wmj:/app$ which python
/usr/bin/python
kuma@web-288507684-d0wmj:/app$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib3
>>> urllib3.__version__
'1.22'
>>> exit()

Then I logged in as an admin, created a new search index, and kicked-off a populate via the Celery workers, which successfully connected to the elasticsearch server (via SSL). Here's a curated sample from the celery-worker log showing four tasks received by the worker and then later completed:

[2017-09-15 10:41:58,198: INFO/MainProcess] Received task: kuma.search.tasks.prepare_index[fe60b170-945a-47e9-8ad0-f1a348767ca1]
[2017-09-15 10:41:58,636: INFO/MainProcess] Received task: kuma.wiki.tasks.index_documents[2e5c7703-3b0f-47b5-a3d1-b602164bf94e]
[2017-09-15 10:41:58,646: INFO/MainProcess] Received task: kuma.wiki.tasks.index_documents[147fb980-99ac-4ce8-b806-2e5a51820a0c]
[2017-09-15 10:41:58,658: INFO/MainProcess] Received task: kuma.wiki.tasks.index_documents[3e882aef-5686-422b-a4a5-3d5bdf333036]
...
[2017-09-15 10:41:58,942: INFO/MainProcess] Task kuma.search.tasks.prepare_index[fe60b170-945a-47e9-8ad0-f1a348767ca1] succeeded in 0.729561349988s: None
...
[2017-09-15 10:44:46,505: INFO/MainProcess] Task kuma.wiki.tasks.index_documents[147fb980-99ac-4ce8-b806-2e5a51820a0c] succeeded in 167.855174023s: None
[2017-09-15 10:44:47,072: INFO/MainProcess] Task kuma.wiki.tasks.index_documents[3e882aef-5686-422b-a4a5-3d5bdf333036] succeeded in 168.410411281s: None
...
[2017-09-15 10:44:52,127: INFO/MainProcess] Task kuma.wiki.tasks.index_documents[2e5c7703-3b0f-47b5-a3d1-b602164bf94e] succeeded in 173.48506865s: None

I also checked the Elasticsearch connection manually, using its ping() method:

Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from kuma.wiki.search import WikiDocumentType
>>> es = WikiDocumentType.get_connection()
>>> es.ping()
True

👍 Looks good. I think we can close this issue.

Member

escattone commented Sep 15, 2017

Verified that the Kuma-based containers (web, api, celery workers, etc.) deployed to mdn-stage (https://mdn-mm.moz.works) are using urllib3 version 1.22:

rjohnson-25186:k8s rjohnson$ kc get pods -n mdn-stage
NAME                             READY     STATUS    RESTARTS   AGE
api-3013948324-fgbpl             1/1       Running   0          1h
celery-beat-1326174911-6f59l     1/1       Running   0          1h
celery-cam-811570164-z18hg       1/1       Running   0          1h
celery-worker-2947925456-6nvcd   1/1       Running   0          1h
kumascript-1576521443-6rbkt      1/1       Running   0          1h
mdn-admin-3097159426-3hbxz       1/1       Running   0          1d
mdn-anon                         1/1       Running   0          1d
web-288507684-d0wmj              1/1       Running   0          1h

rjohnson-25186:k8s rjohnson$ kc exec -n mdn-stage -it web-288507684-d0wmj bash
kuma@web-288507684-d0wmj:/app$ which python
/usr/bin/python
kuma@web-288507684-d0wmj:/app$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib3
>>> urllib3.__version__
'1.22'
>>> exit()

Then I logged in as an admin, created a new search index, and kicked-off a populate via the Celery workers, which successfully connected to the elasticsearch server (via SSL). Here's a curated sample from the celery-worker log showing four tasks received by the worker and then later completed:

[2017-09-15 10:41:58,198: INFO/MainProcess] Received task: kuma.search.tasks.prepare_index[fe60b170-945a-47e9-8ad0-f1a348767ca1]
[2017-09-15 10:41:58,636: INFO/MainProcess] Received task: kuma.wiki.tasks.index_documents[2e5c7703-3b0f-47b5-a3d1-b602164bf94e]
[2017-09-15 10:41:58,646: INFO/MainProcess] Received task: kuma.wiki.tasks.index_documents[147fb980-99ac-4ce8-b806-2e5a51820a0c]
[2017-09-15 10:41:58,658: INFO/MainProcess] Received task: kuma.wiki.tasks.index_documents[3e882aef-5686-422b-a4a5-3d5bdf333036]
...
[2017-09-15 10:41:58,942: INFO/MainProcess] Task kuma.search.tasks.prepare_index[fe60b170-945a-47e9-8ad0-f1a348767ca1] succeeded in 0.729561349988s: None
...
[2017-09-15 10:44:46,505: INFO/MainProcess] Task kuma.wiki.tasks.index_documents[147fb980-99ac-4ce8-b806-2e5a51820a0c] succeeded in 167.855174023s: None
[2017-09-15 10:44:47,072: INFO/MainProcess] Task kuma.wiki.tasks.index_documents[3e882aef-5686-422b-a4a5-3d5bdf333036] succeeded in 168.410411281s: None
...
[2017-09-15 10:44:52,127: INFO/MainProcess] Task kuma.wiki.tasks.index_documents[2e5c7703-3b0f-47b5-a3d1-b602164bf94e] succeeded in 173.48506865s: None

I also checked the Elasticsearch connection manually, using its ping() method:

Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from kuma.wiki.search import WikiDocumentType
>>> es = WikiDocumentType.get_connection()
>>> es.ping()
True

👍 Looks good. I think we can close this issue.

@escattone escattone closed this Sep 15, 2017

@escattone escattone moved this from In Progress (Max 6) to Review in MDN AWS Migration Sep 15, 2017

@metadave metadave moved this from Review to Complete in MDN AWS Migration Sep 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment