Skip to content
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

retarget from publish.dandiarchive.org to api.dandiarchive.org #185

Closed
mgrauer opened this issue Aug 11, 2020 · 2 comments
Closed

retarget from publish.dandiarchive.org to api.dandiarchive.org #185

mgrauer opened this issue Aug 11, 2020 · 2 comments

Comments

@mgrauer
Copy link
Contributor

mgrauer commented Aug 11, 2020

@yarikoptic had asked in a meeting earlier today if we could shift publish.dandiarchive.org to api.dandiarchive.org, and after some discussion, we won't be able to make that move in the next week, so it can't be done near term to align with the CLI release of 0.6.0.

I'm logging this issue in CLI for longer term tracking, but also as a way of communicating the answer to that earlier question--I'm not sure if an issue is the best way to communicate this, but at least it will reach you and save the need for the future.

@satra
Copy link
Member

satra commented Aug 11, 2020

@mgrauer - perhaps create an issue in the archive and could some list what the bottlenecks would be? it seems that some of this is simply mechanistic in terms of terraform or other setup. i can't image the code changes to be anything but a sed replace. but it would be good to know the timeline.

i suspect we will be asking the same question soon after the schema is updated as well so that our asset download links and other urls point to api rather than publish.

@yarikoptic
Copy link
Member

Thank you @mgrauer for the update.

When dandi/redirector#21 gets merged and support for it added to dandi-cli to close #184, nothing would need to be done on dandi-cli side for any possible future rename of this kind -- it would need to be done in redirector's serve.py for hardcoded value (around https://github.com/dandi/redirector/pull/21/files#diff-5bcee4c3a345db1941bf852ac7ecba6aR15) and just by any deployment (test or whatnot) in its specification. I am not sure if it is worth tracking here for this reason, so I will close this issue since nothing to be done on client side IMHO.

In the longer run we need to workout "deployment" configuration which probably would be fed into redirector and any relevant component (avoiding any possible hard-coding which now might be present). Client should be informed about any relevant service endpoints by the deployment it would be talking to, and that is what aforementioned issues are trying to achieve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants