[
https://issues.apache.org/jira/browse/MESOS-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yan Xu updated MESOS-3535:
--------------------------
Description:
Currently no such information is exposed and it's difficult for the operator to
know the state of the cluster in terms of which images are used vs. which can
be cleaned up.
We have tickets for both Appc and Docker store to automatically GC old images
based on the cache size but before it's implemented, the operator needs this
information to decide what to clean up.
Plus, even after auto GC is implemented, images cannot be GCed when they are
still in use, so this will still be very useful.
The current thought is that this could be exposed as a {{monitor/status}}
endpoint and we can require each isolator and the containerizer to expose a
method akin to {{usage()}}.
Note that here this status is semantically different than resource statistics
(which fluctuates) and the user configuration (which is specified by the user
and can be ambiguous if the user doesn't care about preciseness or the specific
config at all), but rather this is the runtime info/state/status of the
container which is likely static for the lifecycle of the container.
For reference, OCI defines a similar "state" endpoint:
https://github.com/opencontainers/specs/blob/master/runtime.md
was:
Currently no such information is exposed and it's difficult for the operator to
know the state of the cluster in terms of which images are used vs. which can
be cleaned up.
We have tickets for both Appc and Docker store to automatically GC old images
based on the cache size but before it's implemented, operator needs this
information to decided what to clean up.
Even after auto GC is implemented, images cannot be GCed when they are still in
use, so this will still be very useful.
The current thought is that this could be exposed as a {{monitor/status}}
endpoint and we can require each isolator and the containerizer to expose a
method akin to {{usage()}}.
Note that here this status is semantically different than resource statistics
(which fluctuates) and the user configuration (which is specified by the user
and can be ambiguous if the user doesn't care about preciseness or the specific
config at all), but rather this is the runtime info/state/status of the
container which is likely static for the lifecycle of the container.
For reference, OCI defines a similar "state" endpoint:
https://github.com/opencontainers/specs/blob/master/runtime.md
> Expose info about the container image associated each container through an
> HTTP endpoint.
> -----------------------------------------------------------------------------------------
>
> Key: MESOS-3535
> URL: https://issues.apache.org/jira/browse/MESOS-3535
> Project: Mesos
> Issue Type: Task
> Reporter: Yan Xu
>
> Currently no such information is exposed and it's difficult for the operator
> to know the state of the cluster in terms of which images are used vs. which
> can be cleaned up.
> We have tickets for both Appc and Docker store to automatically GC old images
> based on the cache size but before it's implemented, the operator needs this
> information to decide what to clean up.
> Plus, even after auto GC is implemented, images cannot be GCed when they are
> still in use, so this will still be very useful.
> The current thought is that this could be exposed as a {{monitor/status}}
> endpoint and we can require each isolator and the containerizer to expose a
> method akin to {{usage()}}.
> Note that here this status is semantically different than resource statistics
> (which fluctuates) and the user configuration (which is specified by the user
> and can be ambiguous if the user doesn't care about preciseness or the
> specific config at all), but rather this is the runtime info/state/status of
> the container which is likely static for the lifecycle of the container.
> For reference, OCI defines a similar "state" endpoint:
> https://github.com/opencontainers/specs/blob/master/runtime.md
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
