#190 deploy two versions on blockerbugs.stg
Opened 2 years ago by kparal. Modified 2 years ago

I'd like to have two deployments on blockerbugs.stg:
a) one instance which uses staging services from stg.fp.o (so partner-bugzilla, bodhi.stg, pagure.stg). This one would be fully functional, i.e. automatically creating and updating discussion tickets, allowing blocker proposals, etc.
b) one instance which uses production services from fp.o (so bugzilla, bodhi, pagure). It would be "read-only", i.e. discussion tickets wouldn't be automatically created/updated, blocker proposals wouldn't be allowed, etc.

Instance A would allow us to test new or existing functionality, it would be our playground for testing. Instance B would help us verify that production data still display correctly (we could easily compare it to the real production instance). It would also answer the frequent question "should the stg instance run on stg data or prod data?" - the answer would be "let's have both" :-)

Of course the instances would run on a different URL, e.g. "qa.stg.fedoraproject.org/blockerbugs/" and "qa.stg.fedoraproject.org/blockerbugs-prod/".

In this ticket I'd like to identify the roadblocks which prevent this from happening. I currently thought of the following:
1. Is it possible to run the same application twice through WSGI? Of course on different URL paths.
2. Currently the app is hardcoded to read /etc/blockerbugs/settings.py. If we want to have two instances, they need to have a different config. We can provide a cmdline option/envvar to specify the config location. What is the best way to provide this to a WSGI app?
Note: Problems 1+2 might a non-issue, if we move blockerbugs to openshift, because running two completely separate instances might be very simple in there? Just a guess.
3. The config should be perhaps extended with READ_ONLY=True/False, that would make sure that even if we configure production URLs to the staging instance, a "write" operation is never attempted. It is not completely necessary at the moment, I think, but it could allow us e.g. listening to discussion ticket changes (and displaying their votes), but not updating them. Also this can be a way to disallow a blocker proposal (which we can't disallow any other way, at the moment, it seems).

What else I'm missing? Any other roadblocks, or implementation suggestions? Thanks.

@frantisekz @lbrabec @jskladan


Issue tagged with: next

2 years ago

Login to comment on this ticket.

Metadata
Boards 1
Next tasks Status: Ideas