#amara

Task complete: demo:amara,gh-855 proxy_user:janeted create_demo:url_prefix=

ehazlett: why do we serve static media from S3? Is it just performance, or is it also bandwidth cost or other reasons?

The reason I ask is that transcript viewer ticket... It's very hard to reproduce what happens on production in a dev environment

I would love to change things to just use a regular django url/view and set the cache headers so it's cached for a long time

seems like that would be fine performance as long as the proxy in front of the app servers cached it

all: heading out to take the kids to swimming, should be back online in about 2.5 hrs.

ehazlett: you here?

bendk: yeah

I had a question above

about static media and S3?

ah sorry didn't get notified

bendk: so a couple reasons -- first it's supposed to be better for serving (s3 is distributed)

bendk: second so we don't have to worry about each app instance making sure the media is correct

instead of one copy we would have 10-16

so I really want a system where we can replicate it as much as possible in development/testing

the current system has basically 2 modes: serve everything from the source JS, or serve compiled/combined/minified media from S3

right

I'd like to replace it with one where there are 3 modes:

serve the compiled media from the local server, using regular django urlconf/views (we would normally use this to test)

serve each individual un-minified javascript file (use this for debugging things)

serve from S3 (it would be easier to avoid this, but if S3 has enough benefits, then I can implement this one)

well you can compile the media locally as well

ehazlett: yeah, so if we did that by default for testing/dev work then things would be better. The issue is that it takes forever to compile the media

yeah so i'm not sure what we can do

the motivation for this is the transcript viewer ticket. For that one things work if you serve them one at a time, but they break when it goes through compile media

ehazlett: I can implement something

if you want it compiled that's it -- unless we rip out how we compile media -- but that scares me

no problem

so then it's probably the compilation right?

ehazlett: yes

which doesn't surprise me

that thing is a beast

somehow it's optimizing in a way that changes the behavior

i wonder if we just changed the optimization mode

currently we use "ADVANCED_OPTMIZATIONS"

gah sp

okay, I think it's basically a development task, I was just hoping to skip the S3 part to make things easier for me

but if S3 is needed, then it's needed. It's not that hard to work with that

ehazlett: tried that

it was actually very weird. I would change the compilation mode and then compilation would fail

what?

but then I realized what was happening was that every other compilation would fail

not really sure what's going on there

man that sucks

yeah

the compilation would change the conf.js file, so maybe that was it, I'm not really sure

so actually thinking about this a little

i'm wondering exactly how bad it would be to use something like django-compressor or something

we replace media on each deploy anyway

yeah, django-compressor would be great

but what about S3?

it should work

bendk: yeah "remote storages"

yeah and looks like two settings - COMPRESS_URL and COMPRESS_STORAGE

hmm

ehazlett: okay, I'd be happy to use that

bendk: ok so it would be a little more work -- but i think it's better

there's one other feature that our compile_media uses that may be tricky with django-compressor, the bootloader code. That's what the transcript viewer uses to load a script after the page has been loaded

I would love to switch to something standard

bendk: ah

bendk: +1 me too

for these exact reasons -- something's getting lost in compilation and we have no idea

it's happened before but arthur would usually dig to find it

okay, I'll just fix the trascriptviewer with the current system, but this will hopefully be a project we can switch soon

t

bendk agree 100%

ehazlett: I tried to spin up a demo instance for gh-855, but it looks like something when wrong

When I attach to it, I see NameError: name 'INSTALLATION' is not defined

ehazlett: ahh, I think this is the issue

s3://amara/settings/gh-855/server_local_settings.py -> server_local_settings.py  [1 of 1]                                                                       ERROR: S3 error: 404 (Not Found):

when calling config_env

ehazlett: These changes seem very safe to me, I just went ahead and merged to staging

can you deploy that?

all: deploying staging

https://github.com/pculture/unisubs/issues/850 sounds like a db manual fix

all: lunch

is there a way to force the display of the idle message when subtitling?

trying to fix the issue where the seconds are not shown on the modal

all: back btw

forgot

bendkdid you get the server_local_settings.py issue fixed?

ehazlett: nope, how should I do that for demo instances?

Project unisubs-staging build #2098: STILL FAILING in 6 hr 5 min: http://dev.universalsubtitles.org:8888/job/unis...

* ben: Added way to test the embedder

* ben: Fix embedder media compilation.

* ben: One more fix for the transcript viewer demo

bendk: so you are using the containers for the demo?

ehazlett: yes, I wanted to

it's not that important now since staging should have the changes

bendk: just remember they will use the same database

bendk: in the future, just add the AWS_ACCESS_ID and AWS_SECRET_KEY (and REVISION and SETTINGS_REVISION if needed)

you can use the existing staging instance for those

bendk: i will create a wiki doc in the amara-docs repo tonight

okay, that's great

bendk: (i started a while back but it fell to the side)

janeted: ehazlett: just pushed a bunch of changes to the docker-dev stuff

you should be able to read the README to figure out what's up

the main thing is now there's just one command startup.py

it creates the images if needed, initializes the database, and starts the services