deconst/client

Progress Indication and Memory storage error

Closed this issue · 2 comments

j12y commented

I'm still simply getting my feet wet with the deconst client so this isn't urgent -- but it might be helpful to include some log details in the UI so that it is easier to know what is going on or where to look.

I wanted to start from a known working state so was using docs-developer-blog. I have been able to get it to successfully open once, but after running into #28 and #36 it seems I'm stuck in a perpetual preparing state.

$ docker ps -a
CONTAINER ID        IMAGE                                    COMMAND                  CREATED             STATUS                      PORTS                     NAMES
ace075042477        quay.io/deconst/preparer-asset:latest    "/usr/src/app/script/"   18 minutes ago      Exited (0) 17 minutes ago                             preparer-control-0
03d9da448536        quay.io/deconst/preparer-jekyll:latest   "ruby -I/usr/src/app/"   18 minutes ago      Exited (0) 17 minutes ago                             preparer-content-0
359106a8526e        quay.io/deconst/presenter:latest         "/usr/src/app/script/"   18 minutes ago      Up 18 minutes               0.0.0.0:32769->8080/tcp   presenter-0
ec12b22f46b7        quay.io/deconst/content-service:latest   "npm start"              19 minutes ago      Up 19 minutes               0.0.0.0:32768->8080/tcp   content-0

Maybe the UI missed an update message?

$ docker logs presenter-0

> presenter@1.0.0 start /usr/src/app
> node app.js

2015-10-27T16:39:17.827Z - debug: Reading rewrites from /var/control-repo/config/rewrites.json
2015-10-27T16:39:17.835Z - info: Presenter listening at http://:::8080
$ docker logs -t -f content-0
...
2015-10-27T16:39:36.331841837Z { action: 'contentstore',
2015-10-27T16:39:36.331861368Z   statusCode: 204,
2015-10-27T16:39:36.331877198Z   apikeyName: 'administrator',
2015-10-27T16:39:36.331895695Z   contentID: 'https://github.com/rackerlabs/docs-developer-blog/blog/page34',
2015-10-27T16:39:36.331912461Z   totalReqDuration: 1,
2015-10-27T16:39:36.332172629Z   message: 'Content storage successful.' }

I found that the site was in fact up, so it does just seem like the UI is out of sync.

$ docker port presenter-0
8080/tcp -> 0.0.0.0:32769
$ curl http://192.168.99.100:32769
...

Hmm.

I'm still simply getting my feet wet with the deconst client so this isn't urgent -- but it might be helpful to include some log details in the UI so that it is easier to know what is going on or where to look.

As it happens I've already got deconst/deconst-docs#153 to build some UI around collecting logs. By the way, I also do have a bunch of issues on the deconst/deconst-docs repo -- I forgot to disable issues on this repository before a bunch of people started using it anyway, so I just try to remember to look in both places for client issues. Look for the client label to see some other known bugs and development plans.

As for the UI being out of sync: check the docker logs for preparer-content-0; that's the process that actually runs Jekyll and submits content where it's supposed to go. You can also click "submit" manually in the UI to force it to reprepare everything to the content store, although I would like to know why it didn't make it in the first time.

Being in a perpetual "preparing" state usually means that the preparer (for your content repo) or grunt (for the control repo) is creating some file that isn't in the .gitignore. I fixed a bug like that a few days ago in rackerlabs/nexus-control#218; is there a chance that's what you're seeing? If it is, a git pull in nexus-control should deal with that.

Also I probably won't be super responsive this week because I have a bunch of ops work to handle; keep the issues rolling in and I'll have a queue of things to look at once I'm back to client fixes.

j12y commented

Aha, that might have been it. I did a pull on nexus-control and loaded and is ready much quicker now.

I'll close this in favor of #153 and if I find anything else can add issues over there. Thanks Ash!