-
Notifications
You must be signed in to change notification settings - Fork 8
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
Explain why custom URIs should be preferred over multiple image repos #49
Conversation
Signed-off-by: Jon Oster <jon.oster@here.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm. As you said in #4 this does not explain why multiple image repos would be used, but as this is discouraged I think that it's alright to leave it as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable to me, as long as the metadata from the Image Repository is trustworthy.
I would ask just to clarify that this has nothing to do with the Director Repository, just the idea of using multiple Image Repositories to accommodate literally different servers for images.
LGTM, but our style guide is to capitalize "Image repository" and "Director repository". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tweaked a few sentences for clarity.
@tkfu --There are a few small wording suggestions that need to be resolved. Can we get this done? |
Co-authored-by: Lois Anne DeLong <lad278@nyu.edu>
This relates to the discussion of #4. This PR just adds some guidance on how to deal with the situation where you have multiple existing repositories, by recommending using a single image repo to serve all the metadata while offering up download locations either via API/HTTP redirects or via custom targets metadata.
Signed-off-by: Jon Oster jon.oster@here.com