The issue right now is that it can’t access its database (also why you can’t see the service page in the left bar). The wizard apparently doesn’t handle that error state nicely. We’ll add a fix for that soon - it should display a clear error message.
That log has alot more info than the last one… Must be moving in the right direction
According to those logs, everything is online and ready. You could try closing and re-opening your browser so it really refreshes the page (and isn’t still using the error version).
Alternatively, you could go to https://192.168.1.104/spark-one/api/doc to verify you can access the backend correctly.
So I closed the browser and re-opened it. It still is having the issues.
Here is the screenshot of the link you sent:
There is an invalid link in the bottom right corner that says this when I open it:
{“schemaValidationMessages”:[{“level”:“error”,“message”:“Can’t read from file https://192.168.1.104/spark-one/api/doc/swagger.json”}]}
Looks good, that means it’s just the datastore that’s being obtuse.
To force it to restart, you can run the following commands:
docker-compose stop datastore
docker-compose up -d
docker-compose logs --follow datastore
Press ctrl+C when it shows that message again, and then ctrl+f5 your browser.
Don’t worry about the schema validation error in that last page: it’s because we’re on a local network: 192.168.1.104 is not accessible from the internet.
That log was different this time:
pi@raspberrypi:~/brewblox $ docker-compose logs --follow datastore
Attaching to brewblox_datastore_1
datastore_1 | ****************************************************
datastore_1 | WARNING: CouchDB is running in Admin Party mode.
datastore_1 | This will allow anyone with access to the
datastore_1 | CouchDB port to access your database. In
datastore_1 | Docker’s default configuration, this is
datastore_1 | effectively any other container on the same
datastore_1 | system.
datastore_1 | Use “-e COUCHDB_USER=admin -e COUCHDB_PASSWORD=password”
datastore_1 | to set it in “docker run”.
datastore_1 | ****************************************************
datastore_1 | [os_mon] cpu supervisor port (cpu_sup): Erlang has closed
datastore_1 | [os_mon] memory supervisor port (memsup): Erlang has closed
datastore_1 | ****************************************************
datastore_1 | WARNING: CouchDB is running in Admin Party mode.
datastore_1 | This will allow anyone with access to the
datastore_1 | CouchDB port to access your database. In
datastore_1 | Docker’s default configuration, this is
datastore_1 | effectively any other container on the same
datastore_1 | system.
datastore_1 | Use “-e COUCHDB_USER=admin -e COUCHDB_PASSWORD=password”
datastore_1 | to set it in “docker run”.
datastore_1 | ****************************************************
The issue still persists
May need to become more drastic to force it to work:
Close the browser, and then run:
brewblox-ctl restart
brewblox-ctl http wait https://localhost/datastore
When the last command is done, try opening the browser again.
To clarify all this: it’s a known issue in the database we use, maybe caused by it writing some corrupted data earlier. We’re not 100% sure (and it’s not in the software we wrote), and when it happens it’s bloody annoying.
So heres what it did:
pi@raspberrypi:~/brewblox $ brewblox-ctl http wait https://localhost/datastore
Connecting https://localhost/datastore, attempt 1/60
Connecting https://localhost/datastore, attempt 2/60
Connecting https://localhost/datastore, attempt 3/60
Success!
I closed the browser, reopened it, and still nothing has changed…
Sorry this is happening, and I strongly appreciate the help with it.
Not sure it helps, but when I click on that datastore link this comes up:
{“couchdb”:“Welcome”,“version”:“2.3.1”,“git_sha”:“c298091a4”,“uuid”:“8e5a4e98341d878a03bf765894bf8908”,“features”:[“pluggable-storage-engines”,“scheduler”],“vendor”:{“name”:“The Apache Software Foundation”}}
This is getting weird: both the output from the http wait command, and the response from clicking on the link indicate that the datastore is working just fine. Maybe something else is going on?
Could you open your dev tab in the browser (f12), go to the network tab, check “disable cache” at the top, and then refresh the page?
If the issue then still persists, click somewhere in the list, and choose “save all as HAR”. You can send that file so I can take a look at exactly what’s going wrong in the browser.
Perhaps exporting the HAR would be a good idea before disabling cache so we can find the cause of the incorrect caching.
Issue persists. The file is too large to send…
You could try mailing it to me at steers.bob at gmail dot com.
Instead of just going to the IP address, whap happens if you append /ui ?
I’m not sure what that is…
Email is sent
Same thing unfortunately
And what if you use an incognito window to bypass any caching?