The project we are doing is part of a course in ANU and we are required to document it well by including in a Github any code that we use. I think it would work if we copied the config file and almond cloud path’s contents, put them in separate folders, then push that to a Github page.
Or would it be better, if we just link the original almond-cloud repository (since nothing here changes anyway), but push the changed config file to our Github?
I think you should discuss these issues with your TAs then, but do explain the situation and how the different files interact. Typically, you’ll want to be very clear what is your work, what is code that you adopted from us, and what is a generated file!
Cool, I think I’ll post again later after trying the fix you mentioned for the website. Thanks Giovanni
Hi Giovanni,
We redid the steps with the git clone and npm command as you suggested. Now the assets file is there but there is a different issue.
How should we fix this new problem?
This is either:
SERVER_ORIGIN should be the http address of our domain right? The one that can be accessed by us from the browser?
Where are the logs for the backend located? The output of the backend terminal while we tested it doesn’t show anything significant, as you can see below:
Is it supposed to be in this page in the website? It doesn’t seem to output anything:
SERVER_ORIGIN should be the URL to your domain that you use from the browser.
The logs of the backend are the terminal view that you’re showing here.
Honestly, everything looks in order here, including the connection from the frontend to the backend for the root user. I don’t know why the connection closes immediately.
I am afraid I don’t know what else to look into. If you want to add more debugging, you can try adding some console.log statements to the routes in almond-cloud/my_internal_api.js at master · stanford-oval/almond-cloud · GitHub and almond-cloud/my_conversation.js at master · stanford-oval/almond-cloud · GitHub. Try to figure out why the connection gets closed…
By any chance, could the problem be at conversation-bundle.js? I checked the version used in the normal Almond website and it seems to have some differences with the one in the github page/the one we are using. For example, below is the code in normal Almond on the left and the one in the github page on the right:
What did you compare it against? It should be identical to the one you find at dev.almond.stanford.edu
I compared the code from almond.stanford.edu (left) with the code found in github (right). What is dev.almond.stanford.edu? Is it different from the normal website, almond.stanford.edu?
I can’t seem to login using my normal account there.
dev.almond.stanford.edu is an instance of Almond 2.0 Alpha, while almond.stanford.edu runs Almond 1.8 (stable). It’s a separate instance so you will need to register a different account.
Is it the same or different with the one in Github? Should we look at Almond 1.8 or 2.0 for an example of a working system?
In GitHub you will find both versions (under appropriate tags and branches). Both versions should be working, as you can see from the deployed versions on our infrastructure.
We managed to get it working by running an npm lifecycle command to fix some dependencies issues. However, the logs in the console still don’t output anything, even though the Almond is now working (we used the dad jokes device to check):
dev.almond.stanford.edu website as well, my logs there also don’t show anything even after I tested using the same dad joke device.Is this a known issue with Almond 2.0?
Yes, the logs page does not work in our deployment of Almond 2.0.
In your deployment, it can work if you enable the sandbox, and build the sandbox with the systemd libraries. Otherwise, it will also not work.
Ok, we’ll see if we need that functionality or not after integrating the device later then.
Hi Giovanni,
We’ve tried to merge the working deployment with the pull request for the developer key functionality but it doesn’t seem to work. We changed both the thingpedia_developer_key and root_thingpedia_developer_key variables to my own developer key but the root user still has its own generated developer key. Do you have any suggestions on how to fix this?
We are using the newest branch for the Almond-cloud itself if that has any effects.
I believe the latest master of almond-cloud had that PR merged already. In any case, you need to reboostrap almond-cloud to apply that configuration change (almond-cloud bootstrap --force, which will wipe the database). Also, configuration the variables are uppercase.
We restarted the entire process from step 1 to redeploy the entire website. Does it matter that we didn’t use --force during the second bootstrap step? We assumed that a clean installation would do just fine.
If you don’t pass --force, and you run the boostrap command against an already initialized database, it will do nothing to avoid deleting data.
