Add generic_bird optional component #41
Conversation
See README.md for more details.
Bonus, this change also prevent the same value to be hardcoded multiple times at various locations. Optional components should probably not hook directly into `common.env` and `pavics-compose.sh`. Another refactoring for another day.
Default was SQLite in-memory and it does not clear completed async wps requests so we quickly run into the default 2 max concurrent wps requests ! Use a separate DB so this optional component do not leave traces when we disable it. This will also allow us to test new different version of Postgres DB if needed. Default version is latest Postgres, not the old version currently in used.
… Finch We can plug in other WPS docker images in this skeleton/generic component. All the elements that need to change are configurable (was just missing the FINCH2_INTERNAL_PORT). The HOSTNAME and HTTP_PORT env var are only for older birds so disabled them. Set WPS logging to a more suitable production logging level, can easily be changed later.
There was a problem hiding this comment.
I'm uncomfortable with this. I suppose it's ok as a temporary measure, but I don't like the idea of having multiple versions of birds without a clear purpose and framework.
We now have a secondary server for thredds and finch. Should we uniformize how we deal with this ? Ie thredds-test, finch-test, etc.
Should test servers inherit their config from their parent ?
How do these test servers differ from our staging environment ?
It's an optional generic component, if this looks confusing, we don't need to enable it.
It starts out as a Finch 2 but now its rather a generic skeleton to plugin any birds we need. I wish I had this when I was testing out the new Thunderbird from PCIC. At some point in the past, we had the idea of 2 simultaneous FlyingPigeon because the new one is so different we wanted to keep the old one around for a short while. This PR could have helped. So do not view this PR as Finch 2 anymore, view this PR as a mechanism to quickly deploy another bird, any bird, without having to change code.
No, this is a standalone bird.
Good question, same reason why we have Test Thredds: the staging and prod environment is not exactly identical, not same data on Thredds. This opens up many options, testing is just one of the possible usage. |
…s generic and not related to Finch
…ake clear is is generic and not related to Finch
tlvu
changed the title
|
Auto deployed to prod: |
Could be used as work-around for issue bird-house/finch#121 so we have a Finch dedicated for async request only.
This component is generic and configurable enough it could even accommodate any WPS. It has its own Postgres instance so we can use it later to experiment with different version of Postgres.
Test server: https://lvupavics-lvu.pagekite.me/twitcher/ows/proxy/finchasync, https://lvupavics-lvu.pagekite.me/canarie/node/service/status
See the
README.mdupdate for more info.Note the docker image, service name and port is customizable (my test server do not use the default service name).
It starts out as a Finch2 but now its rather a generic skeleton to plugin any birds we need. I wish I had this when I was testing out the new Thunderbird from PCIC.
At some point in the past, we had the idea of 2 simultaneous FlyingPigeon because the new one is so different we wanted to keep the old one around for a short while. This PR could have helped.
So do not view this PR as Finch 2 anymore, view this PR as a mechanism to quickly deploy another bird, any bird, without having to change code.
This opens up many options, testing is just one of the possible usage.