Proposed change to expose an activation's containerId

[Matthew Hoffman <ri...@me.com.INVALID>]

Hello,

I am working to integrate OpenWhisk with an open source container debugging tool called CNTR. CNTR attaches containers given their containerID (like those provided by docker ps and those used internally by OpenWhisk). So, I would like to expose an activation’s corresponding containerID.

I have modified ContainerProxy.constructWhiskActivation to store the containerID and containerAddress as additional annotations in the activation result. This enables CNTR to attach the container of a previously invoked lambda by making a REST API call given an activationId.
Can I get feedback on my approach? Would it be possible for me to submit this as a merge request?

—
Matthew Hoffman
Undergraduate at the University of Texas at Austin

Re: Proposed change to expose an activation's containerId

[Chetan Mehrotra <ch...@gmail.com>]

Hi Matthew,

This would be useful addition. There has been earlier discussion
around this "Recording metadata related to activation" [1]. The idea
was to enable the Container Factory to record extra metadata like
containerId with the activation record and internally store it under
new "meta" field which can also be later indexed if needed. The
metadata can be private (start with '_' like '_podId') or public. The
public fields would then be surfaced as annotation for end users.

Chetan Mehrotra
[1] https://lists.apache.org/thread.html/2a3416279705aa6fc0fde124126f7a41c6f4655fd78a0af12e34c5aa%40%3Cdev.openwhisk.apache.org%3E

Chetan Mehrotra


On Sun, Dec 15, 2019 at 7:51 PM Rodric Rabbah <ro...@gmail.com> wrote:
>
> Thanks Matthew for sharing these details. What is the container address? Is
> that its host and ip address?
> Since annotations can be a JSON value, perhaps one annotation is enough
> with an object to encode the details you want nested in the annotation
> value.
> We might want a feature flag to attach this annotation (or only do it in
> certain deployments) since in a production setting this annotation will
> have little actionable value to end users.
>
> -r
>
> On Thu, Dec 12, 2019 at 11:54 AM Matthew Hoffman
> <ri...@me.com.invalid> wrote:
>
> > Hello,
> >
> > I am working to integrate OpenWhisk with an open source container
> > debugging tool called CNTR. CNTR attaches containers given their
> > containerID (like those provided by docker ps and those used internally by
> > OpenWhisk). So, I would like to expose an activation’s corresponding
> > containerID.
> >
> > I have modified ContainerProxy.constructWhiskActivation to store the
> > containerID and containerAddress as additional annotations in the
> > activation result. This enables CNTR to attach the container of a
> > previously invoked lambda by making a REST API call given an activationId.
> > Can I get feedback on my approach? Would it be possible for me to submit
> > this as a merge request?
> >
> > —
> > Matthew Hoffman
> > Undergraduate at the University of Texas at Austin

Re: Proposed change to expose an activation's containerId

[Rodric Rabbah <ro...@gmail.com>]

Thanks Matthew for sharing these details. What is the container address? Is
that its host and ip address?
Since annotations can be a JSON value, perhaps one annotation is enough
with an object to encode the details you want nested in the annotation
value.
We might want a feature flag to attach this annotation (or only do it in
certain deployments) since in a production setting this annotation will
have little actionable value to end users.

-r

On Thu, Dec 12, 2019 at 11:54 AM Matthew Hoffman
<ri...@me.com.invalid> wrote:

> Hello,
>
> I am working to integrate OpenWhisk with an open source container
> debugging tool called CNTR. CNTR attaches containers given their
> containerID (like those provided by docker ps and those used internally by
> OpenWhisk). So, I would like to expose an activation’s corresponding
> containerID.
>
> I have modified ContainerProxy.constructWhiskActivation to store the
> containerID and containerAddress as additional annotations in the
> activation result. This enables CNTR to attach the container of a
> previously invoked lambda by making a REST API call given an activationId.
> Can I get feedback on my approach? Would it be possible for me to submit
> this as a merge request?
>
> —
> Matthew Hoffman
> Undergraduate at the University of Texas at Austin