Closed
Bug 1251744
Opened 10 years ago
Closed 10 years ago
Remove old dependencies from Sumo virtualenvs
Categories
(Infrastructure & Operations Graveyard :: WebOps: Other, task)
Infrastructure & Operations Graveyard
WebOps: Other
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mythmon, Assigned: cliang)
References
Details
(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/2624] )
Sumo doesn't clear out our virtualenvs each deploy, because we have made mistakes.
Because of this, we have a couple stale packages. Please remove them from all sumo virtualenvs (if they exist)
* jingo
* South
These are both no longer in use, and haven't been for a while, so there is no risk of breaking the site. I expect neither of these to exist on -dev and both to exist on -stage and -prod. If this isn't the case, please let me know.
| Assignee | ||
Updated•10 years ago
|
Assignee: server-ops-webops → cliang
| Assignee | ||
Comment 1•10 years ago
|
||
@mythmon: I've made changes to the -dev and -stage SUMO environments. Once you've confirmed that everything is working, we should schedule a time to do the -prod cutover. =)
* -dev
I found that jingo was installed and removed it.[1] When I deployed the changes, I did see that there were errors in the deploy for static assets. [2]
* -stage
jingo, jingo-minify, and South were installed. I removed jingo and South (as specified).[3] Let me know if I should remove jingo-minify as well.
[1] Removal:
$ source /data/support-dev/src/support-dev.allizom.org/kitsune/virtualenv/bin/activate
$ pip freeze | grep jingo
jingo==0.8.1
$ sudo pip uninstall jingo
Uninstalling jingo:
/data/support-dev/src/support-dev.allizom.org/kitsune/virtualenv/lib/python2.7/site-packages/jingo-0.8.1-py2.7.egg-info
/data/support-dev/src/support-dev.allizom.org/kitsune/virtualenv/lib/python2.7/site-packages/jingo/__init__.py
/data/support-dev/src/support-dev.allizom.org/kitsune/virtualenv/lib/python2.7/site-packages/jingo/helpers.py
/data/support-dev/src/support-dev.allizom.org/kitsune/virtualenv/lib/python2.7/site-packages/jingo/monkey.py
Proceed (y/n)? y
Successfully uninstalled jingo
$ virtualenv-2.7 --relocatable /data/support-dev/src/support-dev.allizom.org/kitsune/virtualenv
[...]
$ pip freeze | grep jingo
[2] 2016-02-29 08:24:42] [support1.dev.webapp.phx1.mozilla.com] finished: /data/bin/update-www.sh support-dev.allizom.org (5.094s)
[support1.dev.webapp.phx1.mozilla.com] err: rsync: send_files failed to open "/support-dev.allizom.org/kitsune/static/community/less/community-new.css" (in support-dev): Permission denied (13)
[support1.dev.webapp.phx1.mozilla.com] err: rsync: send_files failed to open "/support-dev.allizom.org/kitsune/static/community/less/community.css" (in support-dev): Permission denied (13)
[support1.dev.webapp.phx1.mozilla.com] err: rsync: send_files failed to open "/support-dev.allizom.org/kitsune/static/community/less/select.css" (in support-dev): Permission denied (13)
[support1.dev.webapp.phx1.mozilla.com] err: rsync: send_files failed to open "/support-dev.allizom.org/kitsune/static/questions/less/questions.aaq.react.css" (in support-dev): Permission denied (13)
[support1.dev.webapp.phx1.mozilla.com] err: rsync: send_files failed to open "/support-dev.allizom.org/kitsune/static/sumo/less/badges.css" (in support-dev): Permission denied (13)
[support1.dev.webapp.phx1.mozilla.com] err: rsync: send_files failed to open "/support-dev.allizom.org/kitsune/static/sumo/less/customercare.css" (in support-dev): Permission denied (13)
[support1.dev.webapp.phx1.mozilla.com] err: rsync: send_files failed to open "/support-dev.allizom.org/kitsune/static/sumo/less/forums.css" (in support-dev): Permission denied (13)
[support1.dev.webapp.phx1.mozilla.com] err: rsync: send_files failed to open "/support-dev.allizom.org/kitsune/static/sumo/less/gallery.css" (in support-dev): Permission denied (13)
[support1.dev.webapp.phx1.mozilla.com] err: rsync: send_files failed to open "/support-dev.allizom.org/kitsune/static/sumo/less/home.css" (in support-dev): Permission denied (13)
[3]
$ pip freeze | grep jingo
jingo==0.8.1
jingo-minify==0.6.0
$ sudo pip uninstall jingo
[...]
$ pip freeze | grep South
South==1.0.2
$ sudo pip uninstall South
Uninstalling South:
/data/support-stage/src/support.allizom.org/kitsune/virtualenv/lib/python2.7/site-packages/South-1.0.2-py2.7.egg-info
/data/support-stage/src/support.allizom.org/kitsune/virtualenv/lib/python2.7/site-packages/south/__init__.py
/data/support-stage/src/support.allizom.org/kitsune/virtualenv/lib/python2.7/site-packages/south/__init__.pyc
[...]
/data/support-stage/src/support.allizom.org/kitsune/virtualenv/lib/python2.7/site-packages/south/v2.py
/data/support-stage/src/support.allizom.org/kitsune/virtualenv/lib/python2.7/site-packages/south/v2.pyc
Proceed (y/n)? y
Successfully uninstalled South
$ virtualenv-2.7 --relocatable /data/support-stage/src/support.allizom.org/kitsune/virtualenv
[...]
| Reporter | ||
Comment 2•10 years ago
|
||
Thanks, and thanks for double checking. It turns out that I was a bit overzealous with that list. We still have some vestigial dependencies on Jingo. I'm putting that back by running our deploy scripts on -dev and -stage. I noticed errors in my cronmail about Jingo being missing.
jingo-minify, on the other hand, is definitely a stale requirement that we can remove.
So the list of stale dependencies to remove is now only: South, jingo-minify.
I think the permission denied errors you saw are something unrelated to this. I saw them in a deploy log the other day, thought I'm not sure what could cause them.
| Assignee | ||
Comment 3•10 years ago
|
||
jingo-minify removed from SUMO-stage.
| Reporter | ||
Comment 4•10 years ago
|
||
I think Sumo-stage is fine with this. Can we move on to Prod?
| Assignee | ||
Comment 5•10 years ago
|
||
Dependencies removed on -prod. When I deployed this change, we ran into a bit of a hiccup since there was a previous deploy attempt that had aborted due to the presence of the South libraries. This required a second full deploy to fix.
After this, there were occasional AttributeErrors being thrown. This appears to be similar to the issue outlined in https://code.djangoproject.com/ticket/25964 and the fix mentioned there (clearing the memcache caches) appears to have worked for us as well.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•