You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current trace based prefetch happens at build time that requires running a dummy container using the image, adding an accelerated layer and push to a new image. This approach makes using it difficult in the following ways:
It changed the semantic of an image to an application. Now instead of many applications using a single image, each application needs to use their own image. The application-level image is quite intrusive to the runtime, e.g.g we need to ask different teams to update their workload to use different images that was actually the same targzip image and it seems unconventional in the container ecosystem.
It is difficult to have an accurate trace built during the build time. In large organizations, the runtime environment can be quite complex (many dependencies on database, cloud resources, internal service, different networking, firewalls), it's super hard and costly to have such environment in the build time (which only has Docker etc. but no K8s or any other dependencies).
My thinking of the trace is at application level instead of at image level, it's better to be maintained by the workload/application owners instead of as part of an image. They decide when to record/replay. The interface could be:
To record:
At runtime, the application owner puts a lock file or some other means (e.g. a new binary overlaybd-record {image}) to start recording, the input contains the trace filename
Overlaybd starts to record the traces for the image once received such signal
Stopping recording the trace could be time or signal based, the output will be an trace file
Application owner collects and store the trace file
To replay
Application owner simply put the trace file to a configured location or call a binary overlaybd-replay {image} etc
I'm totally open to suggestion and discussion, I think the trace based prefetch is a super awesome feature and would love to adopt/contribute to make it even better/easier for adoption, thanks!
Current trace based prefetch happens at build time that requires running a dummy container using the image, adding an accelerated layer and push to a new image. This approach makes using it difficult in the following ways:
My thinking of the trace is at application level instead of at image level, it's better to be maintained by the workload/application owners instead of as part of an image. They decide when to record/replay. The interface could be:
overlaybd-record {image}
) to start recording, the input contains the trace filenameoverlaybd-replay {image}
etcI'm totally open to suggestion and discussion, I think the trace based prefetch is a super awesome feature and would love to adopt/contribute to make it even better/easier for adoption, thanks!
cc @lihuiba @liulanzheng @BigVan
The text was updated successfully, but these errors were encountered: