-
Notifications
You must be signed in to change notification settings - Fork 7
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
bump magpie and twitcher to 3.2.1 #102
Conversation
@tlvu @fmigneault This PR replaces bump_twitcher_to_magpie-3.1.0 -> master, with a cleaner diff. |
Thanks for the cleaner diff ! Much appreciated. @fmigneault will move part of #99 (comment) here, then we can test everything together. And let me do this merge myself once I also test an upgrade on my perso server then our staging server. The pipeline only test fresh new install, but in production it's actually an upgrade with existing Magpie DB. This is a fairly big change so I'd like to be more cautious. |
secure config for thredds
@matprov can you also enable @fmigneault new |
@tlvu It's now enabled and will be applied in future instance creation. Will need to be remove as soon as we don't need it, in test instances. |
I deployed this PR on my dev server with In the logs I see
Looks like the config is not applied properly. |
@tlvu FYI edit |
@matprov is it possible for the DACCS-iac pipeline to save docker logs of all the containers to the job before killing the server? Then to save those files to the Jenkins job you can do something like https://github.com/Ouranosinc/PAVICS-e2e-workflow-tests/blob/5d5a9aa2251386378406efb5b414b3aa6db0b37e/Jenkinsfile#L80-L81 |
@tlvu Yes absolutely, there might be a way to forward the instance's logs to jenkins artifacts. I will look at this soon, thanks. |
@tlvu FYI docker-compose logs are now stored as jenkins artifacts. |
@fmigneault Thanks for the fix. Since you know it best, can you add it? Since CRIM owns Twitcher/Magpie, I prefer to let you guys deal with any config changes required for the update. I can help final testing once you guys confirm the PR is good to go. You guys should make sure to test both fresh deployment and upgrade existing deployment. |
…ce type to permission config
Would this also have worked for the providers:
LocalThredds:
file_patterns:
# note: make sure to employ quotes and double escapes to avoid parsing YAML error
- ".*\\.nc"
- ".*\\.gif"
- ".*\\.txt"
metadata_type:
prefixes:
- null # note: special YAML value evaluated as `no-prefix`, use quotes if literal value is needed
- "catalog\\.\\w+" # note: special case for `THREDDS` top-level directory (root) accessed for `BROWSE`
- "\\*\\.gif"
- "\\*\\.txt"
- ncml
- (...)
data_type:
prefixes:
- "\\*\\.gif"
- "\\*\\.txt"
- fileServer
- (...) |
We will have to try it out. It could work, but due to the prefix handling, I am not 100% sure. Maybe will require top-level resources named like the .gif and .txt files. |
@tlvu |
@fmigneault By the way, does this Twitcher/Magpie upgrade will also include bird-house/twitcher#98 ? |
We can include it while we are at it. |
@fmigneault Oh it's not already in this PR? Then would it be possible to just have the Twitcher fix separately so it can be quickly merged? |
@tlvu merged Ouranosinc/Magpie#377 but I'm not planing to build another tag until Ouranosinc/Magpie#373 is complete |
Thanks @fmigneault It's not 100% clear to me the inter dependencies between the 2 Magpie PR above and the Twitcher performance fix. I simply prefer to have only the Twitcher performance fix alone without all the new features in Magpie. Is that possible so the Twitcher performance fix can go-live quickly? |
@tlvu |
@fmigneault Why? We are only bumping Twitcher, not Magpie so no Magpie behavior change so why would Thredds tests fail? |
@fmigneault We currently have also a very old twitcher If that is simple, can you then just submit a separate PR so we get the Twitcher perf fix in prod without having to wait for this big Magpie upgrade? |
What I mean is that running the old Magpie, THREDDS will remain fully open. The PAVICS-end2end test that is added to validate If what you desire is only to backport Twitcher 0.5.4, to match Magpie What I propose is to run
instead of
|
For the record here, tested @fmigneault proposed backport of Twitcher perf fix, no improvements at all, see comment bird-house/twitcher#97 (comment) |
@tlvu However, running the test environment without the Would it be possible that |
@fmigneault Could you take a look since you wrote |
Found out We should be much more strict to not merge if pipeline do not pass in the future. |
@tlvu This is due to the fact that PR commits done by Francis weren't picked up by the pipeline automatically, therefore not updating build status and not underlining potential issues. New PR commits are now supposed to trigger the pipeline (known issue). |
@fmigneault I never said anything about #99 breaking @matprov found out #99 breaks this branch so you should take a look. And maybe get used to use the pipeline for testing because #99 was not tested when it was merged. |
@tlvu The "breaking merge" is intended, and it was known that it would break because Magpie priority permission is not completed. There is no plan to merge this new version of Magpie (before added "breaking merge"), as it doesn't bring anything "new" by itself. |
@fmigneault I can close this PR (since replaced by PR #107) and delete this branch as well? |
wait what??? merge into master??? Aren't you supposed to just close the PR? |
@fmigneault Can you make a new PR to undo this accidental merge? |
@fmigneault you are merging everything, well the other PR #107 already include this one so there was no need to merge this one anyways. |
magpie
to 3.2.0twitcher
to magpie-3.2.0