I need a database for release-monitoring.org's staging instance. The production release-monitoring.org runs its own postgres, but I think it'd be nice to stop that. Since the staging release-monitoring is new, I'd like it to start off on the right foot and use the normal postgres (unless there's a good reason not to). I'd like the database to not have BDR since anitya has not been written with BDR in mind.
Thanks!
The production release-monitoring.org runs its own postgres, but I think it'd be nice to stop that.
The reason for doing so was to keep release-monitoring.org somewhat independent from the rest of the Fedora infrastructure since it is not aimed only at Fedora. It is for the same reason that it is not running in phx2.
Ah. Well, the stage instance is running in Fedora's OpenShift, so I don't see any reason to not use the Fedora database. Besides, no one outside of Fedora is responsible for the deployment/maintenance of it. If that changes the database situation can be reconsidered, but I don't want to get into the business of running a database that I need to maintain on OpenShift.
Also, if the database could be set up with the latest prod dump, that'd be great.
FWIW I'm okay with this running in Fedora Infrastructure if it reduces overall work. Whether or not other people use it, it's important to Fedora. What can we do to move forward?
Metadata Update from @ralph: - Issue tagged with: request-for-resources
It is not clear what exactly is needed here. 1. Are you looking for a new separate postgres database (aka db-relmon?) how big would this need to be? 2. Are you looking to have this added to an existing db? 3. Are the concerns that pingou has about where this is to go addressed.
It is not clear what exactly is needed here. 1. Are you looking for a new separate postgres database (aka db-relmon?) how big would this need to be?
I don't want a separate postgres server, I just want https://infrastructure.fedoraproject.org/infra/db-dumps/anitya.dump.xz added to the existing staging postgres server.
Are the concerns that pingou has about where this is to go addressed.
@pingou do you have concerns, and if so, are they addressed?
I was reacting to the runs its own postgres, but I think it'd be nice to stop that. piece and providing some historical background.
runs its own postgres, but I think it'd be nice to stop that.
If you want to take this application in a different direction, it's now yours, so lead the way :)
ok. I have setup the db on db01.stg.
There are now stg variables similar to the prod ones:
anitya_stg_db_admin_user anitya_stg_db_admin_pass anitya_stg_db_user anitya_stg_db_pass anitya_stg_db_host anitya_stg_db_name
Let me know if that doesn't work out.
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Thanks! :confetti_ball:
https://stg.release-monitoring.org/
Login to comment on this ticket.