-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FDP in the latest (develop) docker image cannot start #581
Comments
@mirzov Thanks for the detailed report. I'm trying to pick up some of the slack while familiarizing myself with the FDP codebase, so let's see if we can figure this out. On my system the mvn spring-boot:run -Dspring-boot.run.profiles=development (with postgres in a docker container) Tests also pass, so it looks like this case slipped through the cracks of the test suite. Looking more closely, the FAIRDataPoint/src/main/java/org/fairdatapoint/config/RepositoryMigrationConfig.java Lines 37 to 38 in d0ca93f
Sure enough, the error can be reproduced on a local system, running the FDP from source, by activating the mvn spring-boot:run -Dspring-boot.run.profiles=production At least this indicates that the issue is not limited to the Docker image. While I'm looking for a solution or workaround, perhaps @MarekSuchanek could tell us whether this part is still under development? |
Just for reference: FAIRDataPoint/.github/workflows/build.yml Line 173 in d0ca93f
FAIRDataPoint/Dockerfile.build Line 42 in d0ca93f
|
It turns out the public interface RdfMigrationRepository extends MongoRepository<RdfMigration, String> {
} |
Hi Dennis, Nice that there is someone working on the codebase now! I later found that just deleting the file with RdfMigrationRepository class did not prevent the project from building, and the server could start then. However, after packaging and "dockerizing" it, attempts to use the resulting container together with matching Postgres and latest published FDP client were not successful (login with the default credentials was rejected, front page was showing 404 message from a REST call). |
By removing the config file, the server will indeed start. However, this causes the rdf migration steps to be skipped, so the triple store will not be populated with initial data.
Setting up the postgres db, FDP, and FDP client, with the proper ports, I can get the login to work (user data are stored in postgres).
I suppose the status 404 (
Apparently, the The first priority would then be to adapt the In addition, if we look at the production rdf migrations for the develop branch, it looks like those have not been fully adapted to postgres yet. Compare, e.g. with the production migrations for v1.17.2. It would be great if @MarekSuchanek could shed some light on this. |
@mirzov Although I'm working on the current issue, the For this reason it is probably safer to stick to one of the supported releases for now. |
@MarekSuchanek following up on your recent (out of band) communication with @luizbonino, I'm trying to run the current However, I'm running into this issue again (#581):
Specifically, afaik, spring-rdf-migration still depends on mongodb. The migration runner is annotated for FAIRDataPoint/src/main/java/org/fairdatapoint/config/RepositoryMigrationConfig.java Line 37 in 6b04fb8
Probably I'm doing something wrong here. How did you work around this? Note This issue is not covered by the test suite, because all tests pass without problems when I use the Update:Turns out it does work with the more details hereBecause there is no explicit mention of mongo anywhere in the develop codebase, I (erroneously) assumed the exceptions below were due to spring-rdf-migration's use of mongodb (transitive dependency). Still I wonder why spring thinks it needs to enable the mongo healthcheck even if the
|
As far as I can see, there are two things that need to be done to get this to work in
@MarekSuchanek Do you agree? Could you elaborate on the required content of the migration files? |
FYI, spring-rdf-migration does the following:
Note The actual migrations operate on the triple store (RDF), but the list of applied migrations is kept in mongodb. |
@MarekSuchanek In the Line 49 in 6b04fb8
Line 37 in 6b04fb8
and the same in |
@MarekSuchanek and @luizbonino Now I'm wondering (again): Wouldn't it make sense to store the rdf migration history in the triple store itself, instead of in mongodb/postgresql? In the current implementation, suppose you drop your mongodb (or postgres) but keep your triple store, then you would no longer be able to recover (at least not easily), because you've lost your triple store migration history. |
@mirzov If you're still interested, you could try running the latest Here's an example compose file (for local testing only), which can be run using e.g. |
The plan was (maybe still is) to have a way to seed data from files on startup both to triple store and DB so you can more easily adjust what will appear in the FDP and customize Docker images by replacing such files. This is also the reason to remove the old migrations that were placing there default data and then fixing stuff in them (#581 (comment)). Not sure if then the RDF migrations are needed otherwise... maybe it would make more sense in the future to manage somehow migrations when metadata schemas / resource definitions change 🤷♂ but there might be some use case to keep RDF migrations even so. Finally, if it would be somehow possible to keep migration information directly in triple store... that might be probably the best way. Is there already someone doing something like that or would you need to come up with own triples structure to capture it? |
What components are related to the issue?
Other (specify in text)
Which FDP are you using?
My local instance
Version
What happened?
Trying to get the latest development docker image working, prepared the following docker-compose setup:
https://github.com/ICOS-Carbon-Portal/meta/tree/28c90bcd2e7a417302b559f125758d6a5c98ac79/src/main/docker/fdp
FDP server startup failed, the logs complain about lack of Spring Bean definition for type
org.fairdatateam.rdf.migration.database.RdfMigrationRepository
. The culprit seems to be this method argument.In addition, the fdp docker log contains many messages about Spring Data MongoDB. Should it not have been removed when moving to Postgres? The output from
docker logs fdp
is included.Relevant log output
click to see full logs
The text was updated successfully, but these errors were encountered: