I actually think the way DockerContainerizer currently does it is reasonable and allows each container to talk to a potentially different registry using unique credentials. Given the multitude of AuthN schemes, it is probably better to leave the problem of fetching CommandInfo.URIs that need AuthN to fetcher modules.
On Tue, Mar 15, 2016 at 5:39 PM, Kevin Klues <[email protected]> wrote: > Yeah, option 2. > > I was trying to expand on Avinash's suggestion and make it a bit more > concrete in terms of what was being proposed. Needing to reload the > agent just to update the list of credentials it accepts seems > undesirable though. > > Maybe we could have a way to start the agent with a default config (by > iterating on the schema from my previous email), but allow newly > launched frameworks to somehow update the config on the fly through a > file in their sandbox that follows the same schema. > > On Tue, Mar 15, 2016 at 5:25 PM, Jie Yu <[email protected]> wrote: > > Kevin, are you suggesting option 2 and having a config file like the > above? > > > > I think another downside of a per-agent config is that it's hard to > > maintain this. What if a new framework joins and has a new credential for > > the docker images. Do we need to restart the agent to reload the config? > > > > - Jie > > > > On Tue, Mar 15, 2016 at 1:25 PM, Kevin Klues <[email protected]> wrote: > > > >> Can we be a bit more concrete here and try to build up a schema for > this. > >> Maybe something like: > >> > >> { > >> [ > >> { > >> "service" : "docker", > >> "registries" : > >> [ > >> "uri" : "<uri>", > >> "default_credentials" : > >> { > >> "type" : "<type>", > >> "credential" : > >> { > >> // Custom based on type... > >> } > >> }, > >> "image_credentials" : > >> [ > >> { > >> "image_name" : "<image_name>", > >> "type" : "<type>", > >> "credential" : > >> { > >> // Custom based on type... > >> }, > >> }, > >> ... > >> ], > >> ... > >> ] > >> ... > >> }, > >> ... > >> ] > >> } > >> > >> > >> On Tue, Mar 15, 2016 at 12:57 PM, Jie Yu <[email protected]> wrote: > >> >> > >> >> Yeah I was thinking having the JSON as a dictionary with keys being > the > >> >> registry URI (appc/docker) and the values being credentials (which > will > >> be > >> >> a dictionary as well I guess). > >> > > >> > > >> > Using registry URI as the key is problematic. Think about the public > >> docker > >> > hub. Different frameworks might want to use different credentials to > >> access > >> > their docker images. > >> > > >> > - Jie > >> > > >> > On Tue, Mar 15, 2016 at 11:52 AM, Avinash Sridharan < > >> [email protected] > >> > > >> > wrote: > >> > > >> >> On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone <[email protected]> > >> wrote: > >> >> > >> >> > moved core@ to *bcc* > >> >> > > >> >> > On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan < > >> >> [email protected] > >> >> > > wrote: > >> >> > > >> >> >> Why not follow option 2, but instead of passing the agent > >> credentials, > >> >> >> pass a location to the flag where credentials for the registry > can be > >> >> found > >> >> >> (in JSON)? The frameworks can set credentials (maybe registry > name or > >> >> URL > >> >> >> to the registry), and the credentials can be learnt from the JSON > >> >> config. > >> >> >> > >> >> > > >> >> > What if we need credentials for multiple-registries? Have a JSON > with > >> one > >> >> > credential per registry I guess? But if possible, I would love to > >> solve > >> >> > this more generally as possible; as Gilbert mentioned, this is not > a > >> >> > problem just for Docker images but any URIs that need AuthN. > >> >> > > >> >> Yeah I was thinking having the JSON as a dictionary with keys being > the > >> >> registry URI (appc/docker) and the values being credentials (which > will > >> be > >> >> a dictionary as well I guess). > >> >> > >> >> > >> >> -- > >> >> Avinash Sridharan, Mesosphere > >> >> +1 (323) 702 5245 > >> >> > >> > >> > >> > >> -- > >> ~Kevin > >> > > > > -- > ~Kevin >
