Problems starting the ocs_example

[gasilvis]

Running on a win10 machine. docker-compose up -d leads to: ✘ Container ocs_example-configdb-1 Error 0.1s dependency failed to start: container ocs_example-configdb-1 is unhealthy

Looking at the container log I see: psycopg2.OperationalError: connection to server at "db" (172.21.0.5), port 5432 failed: FATAL: database "configdb" does not exist

• Has the db moved?
• Do I need to install postgres on my win10 computer?

Looking forward to exploring OCS Thx George

[gasilvis]

Any thoughts on what the problem is here? Thx George

[jnation3406]

Hey George, Sorry for not replying sooner! I'm the main maintainer of the OCS software but I wasn't signed up to receive notifications on issues so I just noticed your issue now.

This issue sounds like your repo is missing the create-multiple-postgresql-databases git submodule. It is described in the README file under the "Running the example section", but you should be able to add the submodule into your repo but running git submodule init followed by git submodule update from your cloned repo base directory. After that, docker-compose up -d should bring up a functional postgres container with a database table made for each service that needs it. Let me know if that doesn't resolve the issue.

[gasilvis]

Thanks for the note. Gave it another try following your instructions.

First with: C:\projects\astro\ObsCntlSys\ocs_example>docker-compose up [+] Running 6/0 ✔ Container ocs_example-minio1-1 Created 0.0s ✔ Container ocs_example-redis-1 Running 0.0s ✔ Container ocs_example-minio4-1 Created 0.0s ✔ Container ocs_example-minio3-1 Created 0.0s ✔ Container ocs_example-ocs_frontend-1 Running 0.0s ✔ Container ocs_example-minio2-1 Created 0.0s Attaching to adaptive_scheduler-1, configdb-1, db-1, downtime-1, dramatiq_task_scheduler-1, dramatiq_worker-1, minio1-1, minio2-1, minio3-1, minio4-1, nginx-1, observation-portal-1, ocs_frontend-1, redis-1, science_archive_client-1, sciencearchive, simbad2k, thumbnailservice db-1 | db-1 | PostgreSQL Database directory appears to contain a database; Skipping initialization db-1 | db-1 | 2024-02-20 18:24:47.780 UTC [1] FATAL: database files are incompatible with server db-1 | 2024-02-20 18:24:47.780 UTC [1] DETAIL: The data directory was initialized by PostgreSQL version 13, which is not compatible with this version 14.9 (Debian 14.9-1.pgdg110+1). db-1 | Which appears to indicate compatibility problem between the container linux and postgres This goes on to throw the above error about 20 times

I also tried: C:\projects\astro\ObsCntlSys\ocs_example>docker-compose up -d [+] Running 7/7 ✔ Container ocs_example-ocs_frontend-1 Running 0.0s ✔ Container ocs_example-minio2-1 Running 0.0s ✔ Container ocs_example-minio1-1 Running 0.0s ✔ Container ocs_example-minio3-1 Running 0.0s ✔ Container ocs_example-minio4-1 Running 0.0s ✔ Container ocs_example-redis-1 Running 0.0s ✘ Container ocs_example-db-1 Error 0.0s dependency failed to start: container ocs_example-db-1 is unhealthy

Which just says its broke.

Suggestions? thx George

[jnation3406]

I did recently update the postgresql version in the docker-compose file in the project, so it's possible if you had a database initialized prior to that and then pulled down the latest docker-compose, then it is now incompatible. I recommend starting fresh - so doing a docker-compose down --volumes before doing docker-compose up, which should delete your previously created docker volume for the database data. Let me know if that doesn't work for you and we can go from there.

[gasilvis]

Got it running! Thanks for the help. I gave up trying to run it from win10; I'm not sure the .sh to create the db's would work. I started over working from within WSL2, the windows subsystem for linux and it came together pretty quickly. Exploring the interface: pretty straight forward (I'm familiar with django)

Now I need to understand the larger context. I'm guessing a TOM could reach out to an OCS instance for details of what is available at a group of telescope installations. Is there another layer that actually drives the scopes, cameras and enclosures? Or is it stubbed out in the OCS?

[jnation3406]

Yes, a TOM can interface with an OCS instance - this includes things getting available telescopes/instruments and submitting requests and retrieving data. As you suggest, the OCS stands for the Observatory Control System, which is a layer above the TCS (Telescope Control System) which is the layer that would drive the scopes/cameras/enclosures. The Observation Portal communicates with a TCS via a number of APIs - so basically your TCS software would pull down the schedule of observations from the Observation Portal, and then it would update the Observation Portal on the status of an observation as it takes it, and then upload the data to the OCS archive (or whatever archive you are using). Please check out this document for more details on integrating the OCS with a TCS, and let me know if you have more questions!

[gasilvis]

Thank you! This is the piece I need to study. I'm one of the managers of the AAVSOnet which matches user requests with 9 telescopes around the world. We've developed an infrastructure to do this. My worry is extending this into the future: it's time to look into having a system that is scalable and has depth beyond the manpower we have to maintain our system. TOM/OCS/TCS looks like the model to examine. Thanks again for you work. George