mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avinash Sridharan <avin...@mesosphere.io>
Subject Re: Adding a reload end-point to `network/cni` isolator
Date Thu, 08 Dec 2016 00:02:01 GMT
Thinking about the solution of treating the CNI config as an in-memory
cache and doing disk reads on failures I see two problems:
a) We won't be able to support modifications to CNI networks. Since
modification to existing networks won't generate a miss.
b) We won't be able to support deletion of CNI networks.

The two operations above will still need an agent restart.

On Wed, Dec 7, 2016 at 3:40 PM, Avinash Sridharan <avinash@mesosphere.io>
wrote:

>
>
> On Wed, Dec 7, 2016 at 3:31 PM, Avinash Sridharan <avinash@mesosphere.io>
> wrote:
>
>>
>>
>> On Wed, Dec 7, 2016 at 3:17 PM, Daniel Osborne <dan@tigera.io> 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 <avinash@mesosphere.io
>>> >
>>> 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
>



-- 
Avinash Sridharan, Mesosphere
+1 (323) 702 5245

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message