On Wed, Dec 7, 2016 at 3:31 PM, Avinash Sridharan <[email protected]> wrote:
> > > On Wed, Dec 7, 2016 at 3:17 PM, Daniel Osborne <[email protected]> wrote: > >> Chiming in since I raised an identical issue a few weeks back: >> https://issues.apache.org/jira/browse/MESOS-6567 >> >> The proposed endpoint solution sounds plausible. However I'd like to >> explore if it solves the use case I raised my issue for. I was trying to >> create a Mesos framework that adds new CNI networks. But [IIRC] the Agent >> API can't be reached from a Mesos Executor instance since the Agent could >> be listening on a non-default port, or on any of its IPs. The executor >> instance doesn't know that information, so after it installs the plugin, >> it >> won't know how to reach that new reload endpoint. >> > > Just trying to understand the problem you are alluding to here. The > executor needs to register with the agent in order to launch the container, > so it should have reachability to the agent, and hence the endpoint? > > >> - Is there a reliable way to reach the reload endpoint from a default >> executor instance? >> - Why not scan the config directory every time? Are you trying to avoid >> the >> speed hit from disk reads? >> > By scan the config directory every time, do you mean run a timer that will > periodically scan the config directory and keep updating the configs. This > is feasible. The only problem is that the point at which the operator write > the config and the point at which the network will be available for > container launch will not be deterministic. The behavior would be much > cleaner if we can make it deterministic. > Daniel, ignore this comment. I think you were referring to using the disc as a cache as Vinod had pointed out. I misread your suggestion. > Best, >> -Dan >> >> On Wed, Dec 7, 2016 at 3:01 PM, Avinash Sridharan <[email protected]> >> wrote: >> >> > @adam @vinod Starting to work on >> > https://issues.apache.org/jira/browse/MESOS-6679 . Need some inputs. >> > >> > >> > The goal is to allow the `network/cni` isolator to load CNI configs >> without >> > the need for agent restarts. Had a discussion with @jieyu and the >> solution >> > we came up with was for the `network/cni` isolator to expose an endpoint >> > called `reload`. The endpoint will accept `POST` requests (with an empty >> > body), which will trigger the `network/cni` isolator to reload the CNI >> > configs present in the `network_cni_config_dir`. On a successful >> `reload` >> > the `network/cni` isolator will respond with an empty HTTP response. >> Wanted >> > to run this by you guys to understand the implications on authn/authz >> and >> > if this is the right place (the `network/cni` isolator) to host this >> > endponit? >> > >> > -- >> > Avinash Sridharan, Mesosphere >> > +1 (323) 702 5245 >> > >> > > > > -- > Avinash Sridharan, Mesosphere > +1 (323) 702 5245 > -- Avinash Sridharan, Mesosphere +1 (323) 702 5245
