@Kevin, thanks for writing it down in detail. It sounds good that a more
concrete
schema is designed to generally solve similar auth problem.
Just have two potential issues inlined below:
On Tue, Mar 15, 2016 at 5:39 PM, Kevin Klues <klue...@gmail.com> 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
>
Will it be too expensive to update all agents every time a new framework
joins (handling consensus problem as well)?
> file in their sandbox that follows the same schema.
>
Does that mean the file in sandbox should be exposed to each other?
> On Tue, Mar 15, 2016 at 5:25 PM, Jie Yu <yujie....@gmail.com> 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 <klue...@gmail.com> 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 <yujie....@gmail.com> 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 <
> >> avin...@mesosphere.io
> >> >
> >> > wrote:
> >> >
> >> >> On Tue, Mar 15, 2016 at 11:43 AM, Vinod Kone <vinodk...@apache.org>
> >> wrote:
> >> >>
> >> >> > moved core@ to *bcc*
> >> >> >
> >> >> > On Tue, Mar 15, 2016 at 11:18 AM, Avinash Sridharan <
> >> >> avin...@mesosphere.io
> >> >> > > 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
>
