Re: Passing TransactionId as part of action invocation

[Tyson Norris]

I think the point of transaction id in this case is to correlate multiple 
activations, similar to how a sequence works, but not relying on sequence as 
the mechanism for doing this. 

Today, if you launch many activations explicitly, e.g. using OW SDK in your 
nodejs action, they are not "related" to each other, and this would offer a way 
to work around that. Initially, just storing the transaction id, means that 
operators can create queries to stitch multiple activations that originated 
from the same request. It would also be possible to expose transaction id to 
users in the same way that activation id is using a first class API, maybe as 
part of the existing activation API, e.g. GET 
o/api/v1/namespaces/_/activations?tid=

Users can certainly use APIs wrong, but with decent documentation, I don't 
think this should dissuade us from providing the feature.

Thanks
Tyson

On 8/21/19, 8:16 AM, "Martin Henke"  wrote:

Chetan,

from an operational point of view I have some fear that we will confuse the 
user by making the transaction id visible as a second id besides the 
activation id. 
Some will certainly use it to fetch activation records and fail, which will 
lead to questions.
Any thoughts from your side ?

Regards,
Martin


> On 20. Aug 2019, at 12:32, Chetan Mehrotra  
wrote:
> 
> I created a separate thread to discuss how to store such metadata related
> to activation.
> 
> Current open PR #4586 only enables exposing the transactionId to env. It
> does not make any attempt to store the transactionId currently. Once we
> decide how such data should be stored then I can open PR for  the same
> 
> Chetan Mehrotra
> 
> 
> On Mon, Aug 19, 2019 at 8:47 AM Rodric Rabbah  wrote:
> 
>> Yes indeed. Your pr already open I think is fine as is.
>> 
>> -r
>> 
>> On Aug 19, 2019, at 11:36 AM, Chetan Mehrotra 
>> wrote:
>> 
 That’s true. Time for api/v2...
>>> 
>>> This is now becoming a rabbit hole! What option should we use without
>> going
>>> for v2?
>>> 
>>> 1. Introduce a new "meta" sub document
>>> 2. OR Change annotations to flat map while storing but transform that to
>>> array based structure while returning to client
>>> 
>>> Chetan Mehrotra
>>> 
>>> 
 On Mon, Aug 19, 2019 at 7:15 AM Rodric Rabbah  wrote:
 
 
> However changing them now would cause compatibility
> issue with various tooling out there which may be interpreting the
> annotation per current design
 
 That’s true. Time for api/v2... 😅
>> 

Re: Recording metadata related to activation

[Matt Rutkowski]

If we intend to add another top-level key to the data to make it more 
accessible for index/search, we should do so in a manner that is extensible for 
any number of IDs.  Index/search, as well as security and business audits, 
require identifiers exclusively and this, in my view, is different from general 
metadata which should be more descriptive and disposable.

The approach that I have seen work elsewhere I refer to as "tagging", that is 
"tagging" data (in this case activations) with domain-specific identifiers used 
to construct diff. views for diff. domains. 

A single key is assoc. with a list of any number of these domain specific 
identifiers each expressed as a URI where the URI components include a 
prefix/domain that identifies the domain wherein the ID is unique (and 
consequently how to interpret the ID), optional paths can be used to further 
describe the ID's unique space (resource or purpose) and end with the actual 
ID.  URIs, aside from being self-descriptive for interpretation, are desirable 
as they intrinsically avoid collisions and also do not require a key as the URI 
prefix/domain/path uniquely identify the domain/purpose of the identifier 
within the same string.

we could define any number if IDs that are recognized by the OW domain and 
event create a resrved prefix to keep them short, e.g., :

full: "//openwhisk.apache.org/transaction/"
prefixed: "ow:transaction-"

For example, let's say an activation handled credit card data, one could "tag" 
the record with a PCi indicator:

"//GRC20.gov/cloud/security/pci-dss/transaction/"

these could appear on an optional key such as:

{
   "tags":[
  "p1://d1/id1",
  "p2://d2/id2",
  ...
   ]
}

tags do not necessarily need to be for IDs alone... that is they can also help 
in aggregating search data; for example, we could "tag" all data that was 
assigned to a certain region or cluster using this method as well:

{
   "tags":[
  "//ibmcloud.com/icf/region/us-south/cluster/0fdeg1"
  "ow:cluster-kube-055b10f",
  "ow:trans-0555ffca456919",
  ...
   ]
}

of course, the array could be limited in size and downstream processors (search 
or otherwise) could easily "pick out" what tags they care about and discard 
ones they do not.

On 2019/08/20 10:30:19, Chetan Mehrotra  wrote: 
> Hi Team,
> 
> Branching the thread [1] to discuss how to record some metadata
> related to activation. Based on some of the usecases I see a need to
> record some more metadata related to activation. Some examples are
> 
> 1. transactionId - Record the transactionId for which the activation is part 
> of
> 2. pod name - Records the pod running the action container when using
> KubernetesContainerFactory
> 3. invocationId - Some id returned by underlying system when
> integrating with AWS Lambda or Azure Function
> 4. clusterId - If running multiple clusters for same system we would
> like to know which cluster handed the given execution
> 
> Some of these ids are determined as part of `ContainerResponse` itself
> and have to be made part of activation json such that later we can
> correlate the activation with other parts.
> 
> Now we need to determine how to store such id
> 
> Option 1 - New "meta" sub document
> ---
> 
> Introduce a new "meta" key in activation json under which we store such ids
> 
> "meta" : {
> "transactionId" : "xxx",
> "podId" : "ow_xxx"
> }
> 
> 
> Option 2 - Store them as annotations
> -
> 
> Instead of  introducing a new field we store them as annotations. Note
> we still make change in code to capture such data as part of
> `ContainerResponse` but just map it to annotations
> 
> One drawback of this approach is that current approach of annotations
> make it harder to index such fields easily. Having a flat structure
> like with "meta" field enables indexing such fields in db's other than
> Couch
> 
> Chetan Mehrotra
> [1]: 
> https://lists.apache.org/thread.html/f8b73a9ffb0d09a50aecfb54538da2e8365c54dcc3e26a78382ad7bd@%3Cdev.openwhisk.apache.org%3E
> 

Re: Passing TransactionId as part of action invocation

[Rodric Rabbah]

Note the transaction id is already user visible. It’s sent in the response 
headers. As long as we are clear and document that there’s no api for querying 
by this id at this time, the risk of confusion is low imo.

-r

> On Aug 21, 2019, at 11:16 AM, Martin Henke  wrote:
> 
> Chetan,
> 
> from an operational point of view I have some fear that we will confuse the 
> user by making the transaction id visible as a second id besides the 
> activation id. 
> Some will certainly use it to fetch activation records and fail, which will 
> lead to questions.
> Any thoughts from your side ?
> 
> Regards,
> Martin
> 
> 
>> On 20. Aug 2019, at 12:32, Chetan Mehrotra  wrote:
>> 
>> I created a separate thread to discuss how to store such metadata related
>> to activation.
>> 
>> Current open PR #4586 only enables exposing the transactionId to env. It
>> does not make any attempt to store the transactionId currently. Once we
>> decide how such data should be stored then I can open PR for  the same
>> 
>> Chetan Mehrotra
>> 
>> 
>>> On Mon, Aug 19, 2019 at 8:47 AM Rodric Rabbah  wrote:
>>> 
>>> Yes indeed. Your pr already open I think is fine as is.
>>> 
>>> -r
>>> 
>>> On Aug 19, 2019, at 11:36 AM, Chetan Mehrotra 
>>> wrote:
>>> 
> That’s true. Time for api/v2...
 
 This is now becoming a rabbit hole! What option should we use without
>>> going
 for v2?
 
 1. Introduce a new "meta" sub document
 2. OR Change annotations to flat map while storing but transform that to
 array based structure while returning to client
 
 Chetan Mehrotra
 
 
> On Mon, Aug 19, 2019 at 7:15 AM Rodric Rabbah  wrote:
> 
> 
>> However changing them now would cause compatibility
>> issue with various tooling out there which may be interpreting the
>> annotation per current design
> 
> That’s true. Time for api/v2... 😅
>>> 
> 

Re: Recording metadata related to activation

[Tyson Norris]

This part (exposing transaction id to action code) is provided via 
https://github.com/apache/openwhisk/pull/4586

I'm not sure what other meta may exist or planned that does not already follow 
this pattern, but I agree it should all be included where possible - cannot 
include the "duration", since that is only available after execution, but 
action config, like limits, may be useful to include here as well? 

For now, the data fields from ActivationMessage and ExecutableWhiskAction are 
explicitly extracted and provided to the runtime in an "environment" map - we 
could certainly change this to be more generic, like inferring map keys from 
all fields, or just sending json, but this is a bigger change to coordinate 
with runtimes, and gets into the question of whether /init and /run should have 
different signatures, I think.

I think a first step is to create separate meta dictionary on Activation 
(option 1) without changing the API (use annotations) or runtimes. We can 
iterate on invoker/runtime coordination to make passing this data more 
consistent, and change /init /run orchestration separately as needed. 

Thanks
Tyson

 
On 8/21/19, 3:05 AM, "Erez Hadad"  wrote:

On the same note, why not also expose this "meta" information to the 
action code *at runtime*? 
The current direction this discussion is going seems to be having the 
"meta" information only after the action completes, in an activation 
record (under new key or as annotations).

However, think of the following use-case: the "transaction id" can be 
useful for having multiple actions performing computation as part of a 
single transaction, and updating a DB. In such a case, the action code 
needs to know the transaction id so it can be passed to the DB service, 
marking the resulting update as part of the broader transaction. 
Similar cases can be made for other fields. 

Bottom line: I think this "meta" information needs to be more streamlined 
end-to-end, available to code during invocation and persisted post-factum 
in the activation record.

Regards,
-- Erez




From:   Dominic Kim 
To: dev@openwhisk.apache.org
Date:   21/08/2019 02:58
Subject:[EXTERNAL] Re: Recording metadata related to activation



That would be useful from the operator point of view.
One question is "would that information be exposed to users"?

I think the information which is exposed to users should be
platform-independent.
No matter which underlying platform/implementation is being used, users do
and should not need to know about the internal.
So that even if the operator changes their internals(K8s, native, cluster
federation, ...) there should be no difference in user experience.

One option can be storing them as parts of an activation for operators but
exclude them when returning them in response to the user request.
Though I am not sure whether this can be aligned with what you keep in 
your
mind.


Regarding the two structure options, I am inclined to use the existing
structure "annotations" as it does not introduce any schema change.
However, I also found it cumbersome to manipulate them in many cases.
I feel it would be great to change annotations to a dictionary at some
point.

Since I am not aware of the history, I am curious whether there is any
specific reason that annotations should be the current form.

Best regards
Dominic

2019년 8월 21일 (수) 오전 12:38, Matt Sicker 님이 작성:

> I mean, unless you're using these correlation ids in your business
> logic, I don't see the problem of storing them in the database. My own
> thoughts on using this feature would all be diagnostics-related. I'm
> not running any non-trivial functions, though.
>
> On Tue, 20 Aug 2019 at 05:30, Chetan Mehrotra 

> wrote:
> >
> > Hi Team,
> >
> > Branching the thread [1] to discuss how to record some metadata
> > related to activation. Based on some of the usecases I see a need to
> > record some more metadata related to activation. Some examples are
> >
> > 1. transactionId - Record the transactionId for which the activation 
is
> part of
> > 2. pod name - Records the pod running the action container when using
> > KubernetesContainerFactory
> > 3. invocationId - Some id returned by underlying system when
> > integrating with AWS Lambda or Azure Function
> > 4. clusterId - If running multiple clusters for same system we would
> > like to know which cluster handed the given execution
> >
> > Some of these ids are determined as part of `ContainerResponse` itself
> > and have to be made part of activation json such that later we can
> > correlate the activation with other parts.
> >
> > Now we need to determine

Re: Passing TransactionId as part of action invocation

[Martin Henke]

Chetan,

from an operational point of view I have some fear that we will confuse the 
user by making the transaction id visible as a second id besides the 
activation id. 
Some will certainly use it to fetch activation records and fail, which will 
lead to questions.
Any thoughts from your side ?

Regards,
Martin


> On 20. Aug 2019, at 12:32, Chetan Mehrotra  wrote:
> 
> I created a separate thread to discuss how to store such metadata related
> to activation.
> 
> Current open PR #4586 only enables exposing the transactionId to env. It
> does not make any attempt to store the transactionId currently. Once we
> decide how such data should be stored then I can open PR for  the same
> 
> Chetan Mehrotra
> 
> 
> On Mon, Aug 19, 2019 at 8:47 AM Rodric Rabbah  wrote:
> 
>> Yes indeed. Your pr already open I think is fine as is.
>> 
>> -r
>> 
>> On Aug 19, 2019, at 11:36 AM, Chetan Mehrotra 
>> wrote:
>> 
 That’s true. Time for api/v2...
>>> 
>>> This is now becoming a rabbit hole! What option should we use without
>> going
>>> for v2?
>>> 
>>> 1. Introduce a new "meta" sub document
>>> 2. OR Change annotations to flat map while storing but transform that to
>>> array based structure while returning to client
>>> 
>>> Chetan Mehrotra
>>> 
>>> 
 On Mon, Aug 19, 2019 at 7:15 AM Rodric Rabbah  wrote:
 
 
> However changing them now would cause compatibility
> issue with various tooling out there which may be interpreting the
> annotation per current design
 
 That’s true. Time for api/v2... 😅
>> 

OW Tech. Interchange Meeting - 21st Aug [Agenda Items]

[Neeraj Mangal]

Hi Team,

Please find the agenda for today's call.
No specific topics submitted so far.

Topics from the mailing list -


  1.  Recording metadata related to activation
  2.  The process to release apache/Openwhisk repo

PRs to review -

  1.  OpenWhisk User Events (selfxp) - 
https://github.com/apache/openwhisk/pull/4584
  2.  Pass transactionId to action container (chetanmeh) 
https://github.com/apache/openwhisk/pull/4586

For detailed information, please refer[1].


Thanks,
Neeraj

[1] https://github.com/neerajmangal/OWMeetings/blob/master/21stAug.md



From: Neeraj Mangal 
Sent: Monday, August 19, 2019 1:35 PM
To: dev@openwhisk.apache.org 
Subject: OW Tech. Interchange Meeting - 21st Aug [Call for Agenda Items]

Hi Team,

If you have any topics to share in the next tech interchange meeting on 
Wednesday 21st Aug[1], please send an email or ping me on slack before the 
meeting.

​Thanks,
Neeraj

[1]
Web Meeting: Tech Interchange (bi-weekly):
Day-Time: Wednesdays, 11AM EDT (Eastern US), 5PM CEST (Central Europe),
3PM GMT, 11PM (midnight)(Beijing)
Zoom: https://zoom.us/my/asfopenwhisk
Google Calendar (click entry to add):
https://calendar.google.com/event?action=TEMPLATE&tmeid=MnU2dHNiMjc0bTRoc29ydjBscW05Ym1jNmhfMjAxOTA5MDRUMTUwMDAwWiBhcGFjaGVvcGVud2hpc2tAbQ&tmsrc=apacheopenwhisk%40gmail.com&scp=ALL

[github-digest][2019-08-07-2019-08-21] Currently based on a in-work tooling

[Chetan Mehrotra]

# apache/openwhisk

## Issues

### Created:
* #4587 - S3AttachmentStoreMinioTests test cases run failed (ningyougang)
* #4585 - Pass TransactionId to action containers (chetanmeh)
* #4583 - Support for s390x (beth2016)
* #4580 - [Discussion] Action Versioning (style95)
* #4579 - Publish OpenWhisk artifacts to Maven (chetanmeh)

### Closed:
* #3401 - Consolidate action annotation constants (mdeuser)
* #4545 - update gradlew[.bat] with Apache license (rabbah)
* #4569 - Kubernetes Container Factory doesn't support extraArgs
environment variable (Logicon211)
* #3649 - where is goPrepare gradle task? (norricorp)

### Updated:
* #2924 - Add more instructions for autocomplete on mac
_get_comp_words_by_ref: command not found (csantanapr)

## Pull Requests

### Merged:
* #4582 - Action container log collection does not wait for
sentinel on developer error (sven-lange-last)
* #4571 - Api Gateway support in OpenWhisk Standalone mode (chetanmeh)
* #4581 - graduation: remove more incubator- references (dgrove-oss)
* #4567 - Update Gradle to 5.5 version (chetanmeh)
* #4578 - Remove configureOSSpecificOpts in standalone and move
the config options to standalone.conf (yihuaf)
* #4570 - KCF: propagate cf_ca_extraArgs_env_i into user
containers (dgrove-oss)

### Created:
* #4584 - OpenWhisk User Events (selfxp)
* #4586 - Pass transactionId to action container (chetanmeh)

### Updated:
* #4559 - Allow parameters to be designated as init time properties (rabbah)

# apache/openwhisk-apigateway

## Issues

### Closed:
* #340 - App ID retrieval of keys can throw Error 500 (mhamann)

### Updated:
* #307 - API Gateway removes Access-Control-Allow-Headers header (akrabat)
* #345 - container cannot resolve http://host.docker.internal (rabbah)
* #311 - Expose base path to the action (akrabat)
* #348 - Allow for large upstream response headers (mdeuser)
* #310 - x-forwarded-port makes little sense (akrabat)
* #325 - Support for invocations based on websocket messages (mhamann)

## Pull Requests

### Merged:
* #353 - OAuth fixes and improvements (mhamann)
* #352 - Remove 'incubat(ing, ion, or)' designation and disclaimer
(mrutkows)

# apache/openwhisk-catalog

## Pull Requests

### Merged:
* #307 - Remove 'incubat(ing, ion, or)' designation and disclaimer
(mrutkows)

# apache/openwhisk-cli

## Pull Requests

### Merged:
* #454 - Remove 'incubat(ing, ion, or)' designation and disclaimer
(mrutkows)

### Updated:
* #404 - corrected description of go build steps (matthiaskubik)

# apache/openwhisk-client-go

## Pull Requests

### Merged:
* #126 - WIP - Remove 'incubat(ing, ion, or)' designation and
disclaimer (mrutkows)

# apache/openwhisk-client-js

## Pull Requests

### Merged:
* #192 - kill last incubator reference (dgrove-oss)

# apache/openwhisk-composer

## Pull Requests

### Merged:
* #47 - use nightly tag to pull core openwhisk images from
dockerhub (dgrove-oss)

### Created:
* #49 - tlp: remove incubator references and disclaimer (dgrove-oss)

# apache/openwhisk-deploy-kube

## Issues

### Created:
* #508 - kubeadm-dind-cluster project archived / EOL (dgrove-oss)

### Closed:
* #503 - Updates for Docker Desktop 2.1.0.0 (dgrove-oss)

## Pull Requests

### Merged:
* #507 - Version bumps on tested Kubernetes versions (dgrove-oss)
* #506 - use extraEnvVars to set __OW_ALLOW_CONCURRENT (dgrove-oss)
* #505 - tlp: updates for github repo rename to remove incubator-
(dgrove-oss)

# apache/openwhisk-devtools

## Issues

### Created:
* #282 - Localization problem in Makefile (anbo-de)
* #280 - Restart controller/invoker by docker-compose tool does
not work  (lyuxiaosu)
* #279 - wskdeploy runtime specification does not work with
compose. (style95)

### Closed:
* #278 - There is no python2 image with nightly tag (style95)
* #250 - ERROR: for apigateway '"/bin/sh" 28: let: not
found' repeatedly cycles (VestigeJ)

## Pull Requests

### Merged:
* #283 - fixed localization problem #282 (anbo-de)
* #281 - sync knative java with udpates made to
openwhisk-runtime-java (mrutkows)

# apache/openwhisk-package-alarms

## Issues

### Created:
* #196 - [Suggestion] Add delays of a few seconds before firing
triggers (machenity)

## Pull Requests

### Merged:
* #197 - tlp: remove incubator references & disclaimer (dgrove-oss)

# apache/openwhisk-package-cloudant

## Pull Requests

### Merged:
* #213 - tlp: remove incubator references and disclaimer (dgrove-oss)

# apache/openwhisk-package-kafka

## Pull Requests

### Merged:
* #341 - Test resiliency updates (dubee)
* #349 - tlp: remove incubator references and disclaimer (dgrove-oss)

# apache/openwhisk-release

## Pull Requests

### Merged:
* #295 - add test for absence of DISCLAIMER.txt (dgrove-oss)

# apache/openwhisk-runtime-ballerina

## Pull Requests

### Created:
* #18 - tlp: remove incub

Re: Recording metadata related to activation

[Erez Hadad]

On the same note, why not also expose this "meta" information to the 
action code *at runtime*? 
The current direction this discussion is going seems to be having the 
"meta" information only after the action completes, in an activation 
record (under new key or as annotations).

However, think of the following use-case: the "transaction id" can be 
useful for having multiple actions performing computation as part of a 
single transaction, and updating a DB. In such a case, the action code 
needs to know the transaction id so it can be passed to the DB service, 
marking the resulting update as part of the broader transaction. 
Similar cases can be made for other fields. 

Bottom line: I think this "meta" information needs to be more streamlined 
end-to-end, available to code during invocation and persisted post-factum 
in the activation record.

Regards,
-- Erez




From:   Dominic Kim 
To: dev@openwhisk.apache.org
Date:   21/08/2019 02:58
Subject:[EXTERNAL] Re: Recording metadata related to activation



That would be useful from the operator point of view.
One question is "would that information be exposed to users"?

I think the information which is exposed to users should be
platform-independent.
No matter which underlying platform/implementation is being used, users do
and should not need to know about the internal.
So that even if the operator changes their internals(K8s, native, cluster
federation, ...) there should be no difference in user experience.

One option can be storing them as parts of an activation for operators but
exclude them when returning them in response to the user request.
Though I am not sure whether this can be aligned with what you keep in 
your
mind.


Regarding the two structure options, I am inclined to use the existing
structure "annotations" as it does not introduce any schema change.
However, I also found it cumbersome to manipulate them in many cases.
I feel it would be great to change annotations to a dictionary at some
point.

Since I am not aware of the history, I am curious whether there is any
specific reason that annotations should be the current form.

Best regards
Dominic

2019년 8월 21일 (수) 오전 12:38, Matt Sicker 님이 작성:

> I mean, unless you're using these correlation ids in your business
> logic, I don't see the problem of storing them in the database. My own
> thoughts on using this feature would all be diagnostics-related. I'm
> not running any non-trivial functions, though.
>
> On Tue, 20 Aug 2019 at 05:30, Chetan Mehrotra 

> wrote:
> >
> > Hi Team,
> >
> > Branching the thread [1] to discuss how to record some metadata
> > related to activation. Based on some of the usecases I see a need to
> > record some more metadata related to activation. Some examples are
> >
> > 1. transactionId - Record the transactionId for which the activation 
is
> part of
> > 2. pod name - Records the pod running the action container when using
> > KubernetesContainerFactory
> > 3. invocationId - Some id returned by underlying system when
> > integrating with AWS Lambda or Azure Function
> > 4. clusterId - If running multiple clusters for same system we would
> > like to know which cluster handed the given execution
> >
> > Some of these ids are determined as part of `ContainerResponse` itself
> > and have to be made part of activation json such that later we can
> > correlate the activation with other parts.
> >
> > Now we need to determine how to store such id
> >
> > Option 1 - New "meta" sub document
> > ---
> >
> > Introduce a new "meta" key in activation json under which we store 
such
> ids
> >
> > "meta" : {
> > "transactionId" : "xxx",
> > "podId" : "ow_xxx"
> > }
> >
> >
> > Option 2 - Store them as annotations
> > -
> >
> > Instead of  introducing a new field we store them as annotations. Note
> > we still make change in code to capture such data as part of
> > `ContainerResponse` but just map it to annotations
> >
> > One drawback of this approach is that current approach of annotations
> > make it harder to index such fields easily. Having a flat structure
> > like with "meta" field enables indexing such fields in db's other than
> > Couch
> >
> > Chetan Mehrotra
> > [1]:
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apache.org_thread.html_f8b73a9ffb0d09a50aecfb54538da2e8365c54dcc3e26a78382ad7bd-40-253Cdev.openwhisk.apache.org-253E&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Oo9B0p_tCCWIIum5GpjjqA&m=45iTZS1Qpqk36WKRpGn5AVuVekJOiQscMAmVG6gb-Ao&s=TkpxifEFrs94Fzs57UTthhI93j1M6QOyBvfqkyirmXg&e=
 

>
>
>
> --
> Matt Sicker 
>

[slack-digest] [2019-08-20] #general

[OpenWhisk Team Slack]

2019-08-20 01:19:03 UTC - Ning yougang: Hi, hello everyone
S3AttachmentStoreMinioTests relative test cases run failed on my build machine, 
but on other machines, the test cases run successfully. Does someone meet the 
strange problem?
Here is the detail info: 
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1566263943060500

2019-08-20 01:22:28 UTC - Ning yougang: Obviously，this problem has no relation 
with the codes, just have relation with our environment only,
I keep the issues here two days only, two days later, i will close it.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1566264148060700

2019-08-20 10:03:07 UTC - Pepi Paraskevoulakou: hello again ! i was wondering 
if you have any web article with implementation of machine learning trained 
models (in python) to make it as a dockerfile and push it in openwhisk as a 
function
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1566295387062300?thread_ts=1566295387.062300&cid=C3TPCAQG1

2019-08-20 11:36:44 UTC - James Thomas: 

https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1566301004062400?thread_ts=1566295387.062300&cid=C3TPCAQG1

2019-08-20 11:36:48 UTC - James Thomas: 

https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1566301008062700?thread_ts=1566295387.062300&cid=C3TPCAQG1

2019-08-20 11:36:59 UTC - James Thomas: 

https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1566301019063000?thread_ts=1566295387.062300&cid=C3TPCAQG1

2019-08-20 11:48:28 UTC - Pepi Paraskevoulakou: can i implement these in 
openwhisk installation with docker-compose?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1566301708063300?thread_ts=1566295387.062300&cid=C3TPCAQG1

2019-08-20 11:59:51 UTC - James Thomas: yes
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1566302391063500?thread_ts=1566295387.062300&cid=C3TPCAQG1

2019-08-20 21:21:41 UTC - Misha Iesiev: Hi everyone,
The links below suggest OW deployment configuration for IKS/Openshift to use 
kubernetes container factory



I tried to run docker container factory on Openshift myself and the invoker 
pods would never start properly.
Is there a known issue with docker container factory on these platforms? Or 
maybe I am missing some configuration to have it working?
Thanks!
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1566336101068200?thread_ts=1566336101.068200&cid=C3TPCAQG1