No indication that preparation is complete?
Closed this issue · 7 comments
I'm sure this is just me using deconst client wrong but how do I tell when it is complete and what url to view from the UI?
I ran the following commands, hunted down the presenter's port and was able to bring it up. But the UI still says "preparing" with no indication that I was in fact all set.
~/.docker/machine/machines/deconst-client$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
dcd89f1b98bb quay.io/deconst/preparer-jekyll:latest "ruby -I/usr/src/app/" About a minute ago Exited (0) 36 seconds ago preparer-content-1
66c705c267a1 quay.io/deconst/preparer-asset:latest "/usr/src/app/script/" About a minute ago Up About a minute preparer-control-1
0147a39b1f82 quay.io/deconst/presenter:latest "/usr/src/app/script/" 2 minutes ago Up 2 minutes 0.0.0.0:32769->8080/tcp presenter-1
c0a32a07b246 quay.io/deconst/content-service:latest "npm start" 3 minutes ago Up 3 minutes 0.0.0.0:32768->8080/tcp content-1
~/.docker/machine/machines/deconst-client$ docker port 0147a39b1f82
8080/tcp -> 0.0.0.0:32769
~/.docker/machine/machines/deconst-client$ open http://$(docker-machine ip deconst-client):32769On a related note, it does pick up new changes and update the site. However the UI doesn't indicate this. As a workaround I watch for the jekyll preparer container to exit and then refresh the page.
@carolynvs Interesting! What's supposed to happen is that, as soon as both preparers complete for a new repository:
- The text on the UI will change to a link, that takes you directly to the rendered content.
- If the application is in the background, the dock icon will bounce once.
It sounds like the Docker event for the container completion is getting lost somehow... or I messed up the state transitions.
As a workaround I watch for the jekyll preparer container to exit and then refresh the page.
Just to verify, I'm assuming that the corresponding control preparer already exited, too? Sometimes the npm install in that one hangs for a good while.
Honestly the whole preparer state machine bit needs some heavy 🔧. It's a race condition in there that's causing the 409s you see occasionally, too.
It's not a big deal now that I know what to watch. I'll give it another go and post back with which ones exited and which were still hanging on.
Alrighty, just checked and no, the control preparer seems to be hung. I can browse the site but the preparer-control container hasn't exited yet. This doesn't appear to be a problem, I can still see my changes and try stuff out. But maybe that's why the UI still says "preparing..".
~$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c39644b1438f quay.io/deconst/preparer-jekyll:latest "ruby -I/usr/src/app/" 5 minutes ago Exited (0) 3 minutes ago preparer-content-0
a059a51f34a8 quay.io/deconst/preparer-asset:latest "/usr/src/app/script/" 5 minutes ago Up 5 minutes preparer-control-0
1450c03ac998 quay.io/deconst/presenter:latest "/usr/src/app/script/" 8 minutes ago Up 8 minutes 0.0.0.0:32769->8080/tcp presenter-0
0b5a869564ce quay.io/deconst/content-service:latest "npm start" 10 minutes ago Up 10 minutes 0.0.0.0:32768->8080/tcp content-0
~$ docker logs preparer-control-0
npm WARN package.json Dependency 'cheerio' exists in both dependencies and devDependencies, using 'cheerio@^0.19.0' from dependencies
Running "empty:less_vars" (empty) task
Emptying assets/src/css/less/deconst-variables.less
Emptying assets/getcarina.com/src/css/less/deconst-variables.less
Running "copy:build" (copy) task
Copied 35 files
Running "deconst_assets:assets" (deconst_assets) task
1 of 28 files uploaded.
2 of 28 files uploaded.
3 of 28 files uploaded.
4 of 28 files uploaded.
5 of 28 files uploaded.
6 of 28 files uploaded.
7 of 28 files uploaded.
8 of 28 files uploaded.
9 of 28 files uploaded.
10 of 28 files uploaded.
11 of 28 files uploaded.
12 of 28 files uploaded.
13 of 28 files uploaded.
14 of 28 files uploaded.
15 of 28 files uploaded.
16 of 28 files uploaded.
17 of 28 files uploaded.
18 of 28 files uploaded.
19 of 28 files uploaded.
20 of 28 files uploaded.
21 of 28 files uploaded.
22 of 28 files uploaded.
23 of 28 files uploaded.
24 of 28 files uploaded.
25 of 28 files uploaded.
26 of 28 files uploaded.
27 of 28 files uploaded.
28 of 28 files uploaded.
Running "deconst_assets:carina_assets" (deconst_assets) task
1 of 11 files uploaded.
2 of 11 files uploaded.
3 of 11 files uploaded.
4 of 11 files uploaded.
5 of 11 files uploaded.
6 of 11 files uploaded.
7 of 11 files uploaded.
8 of 11 files uploaded.
9 of 11 files uploaded.
10 of 11 files uploaded.
11 of 11 files uploaded.
Running "less:dev" (less) task
File assets/src/css/main.css created
File assets/getcarina.com/src/css/main.css created
Running "cssmin:build" (cssmin) task
>> 2 files created. 270.2 kB → 134.39 kB
Running "browserify:dev" (browserify) task
>> Bundle assets/src/js/bundle.js created.
Running "browserify:carina" (browserify) task
>> Bundle assets/getcarina.com/src/js/bundle.js created.
Running "uglify:build" (uglify) task
>> 2 files created.
Running "deconst_assets:css_js" (deconst_assets) task
1 of 2 files uploaded.
2 of 2 files uploaded.
In case anyone else runs into this, here is my workaround:
eval $(docker-machine env deconst-client)- (optional)
dvm use open http://$(docker-machine ip deconst-client):$(docker port presenter-0 | cut -d ":" -f2)
After switching to using a clone of the control repo per content repo, this problem has gone away.