mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yan Xu (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MESOS-3535) Expose info about the container image associated each container through an HTTP endpoint.
Date Mon, 12 Oct 2015 18:20:05 GMT

     [ 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)

Mime
View raw message