REVIEW 3

[JayjeetAtGithub]

Questions and comments

• Popper employs workflow engines as one of the ways to address reproducibility; is there consideration for how logging and tracing might also be applied by Popper? How about working from a stable initial state? Could you show how Popper obviates the need for more documentation of the workflows?
• I: To be truly compelling in the argument that the essential features of a wide range of container and orchestration runtimes are supported by Popper, wouldn't it be necessary to document that span and catalog the ways in which Popper already does or could easily cover all of those cases? The evidence offered for that appears anecdotal but not systematic.
• Is Docker really still the (dominant) de facto container runtime? Agreed that it used to be
• Security and rootlessnes are other key sources of differencea among container runtimes
• The goal of Popper goes beyond defining tasks; it also covers their sequencing and tracking, right?
• II.D.3: What evidence is there that Popper's facilities can comprehensively support caching and layering?
• II.D.4: What pod support does Popper provide?
• II: What features does it offer for virtualized contexts?

Nits:

• I: numerous existing research
• III.1 Popper aids .. in writing, testing, debugging…
• III.3 popper -> Popper
• IV: asides -> besides
• IV: specify A few
• Reference 55: THE mnist --> The MNIST

[ivotron]

one way we can address these comments:

• logging and tracing. In general, popper can do as much as the underlying container engine (and its associated ecosystem) can do. Specifically:

  • logging. popper could provide an abstract mechanism for allowing users to specify where to store logs (and their formats). It currently uses the stdout logger by default (and logs to files on request). This could be extended to support other logging alternative (e.g. logging drivers in the case of docker).
  • tracing. Simliarly to the above, popper could abstract all the plethora of options for tracing containers (e.g. using dtrace)

• the point on listing all the capabilities that container engines and orchestrators provide, and then adding checkmarks on how popper addresses them is very interesting. Not sure if we'll have enough time to do it though before the CRC (10/09)

• point on popper doing more than defining task is true. We can extend the description when we introduce what it does and include launching and tracking their completion

• regarding caching and layering: this is done by the underlying engine. And is also related to add "support for abstracting image builders" in future work section #44

• regarding virtualized contexts. It does as much as the underlying engine. For example, if using kata, then a container will run inside a VM. We can also say that it can run docker within vagrant. For this latter one, we'll need to bring it back since that was removed (or we can add it in the future work section).

[JayjeetAtGithub]

@ivotron Where should I talk about the logging and tracing, caching and layer (maybe in the Resource Manager and Container Engine API section), and the virtualized context? We can describe that popper is just an abstraction over containers and can do as much as containers can do and describe these points. But i am wondering where it would be appropriate to talk about these.

[ivotron]

I think that would fit in the future work section. We can create a bulleted list to give more structure to that section