Let me share a few ideas on them.
Regarding option B1, I think it can scale out better than option B2.
If I understood correctly, scaling out of the service will be highly
dependent on Kafka.
Since the number of consumers is limited to the number of partitions, the
number of service nodes will be
It might not be directly related to the agenda but one small thing to note
is the response time of the auth/authz server should be considered as well.
When I implemented LDAP integration, the LDAP server was too slow.
It took about 100ms ~ 1s to authenticate users.
Even though I took advantage of
In the current activation model, an action's arguments are always provided
to the action on "run", not "init".
Should we consider partitioning the argument list into two sets, the first
is exported as environment variables at "init" time, and the second become
the action's argument at "run" time?
jthomas merged pull request #8: Fixing scancode issues.
URL: https://github.com/apache/incubator-openwhisk-pluggable-provider/pull/8
This is an automated message from the Apache Git Service.
To respond to the message, please
oh, one thing worth mentioning: when testing on electron, on linux, i have
to use an http keep-alive http agent when talking to the standalone. this
has been a perennial problem with electron/linux versus openwhisk (i still
have no idea why); but the standalone jar made the problem considerably
it's been working well for our CI/CD tests. standalone openwhisk, combined
with microk8s, are a perfect combination for test pipelines against this
kind of infrastructure.
thanks!!
On Mon, Jun 24, 2019 at 6:08 AM Chetan Mehrotra
wrote:
> Hi Team,
>
> At this stage the OpenWhisk Standalone jar
Hi Team,
At this stage the OpenWhisk Standalone jar works fine. So would like
to get it tried out in real world and for that need some volunteers!
You can follow the steps at
https://github.com/chetanmeh/incubator-openwhisk/releases/tag/v0.10
and download the jar and try out a hello world or
Okie so we can then aim for adding an optional support for storing
activations via a separate service.
Currently we also send the activation result on respective controller
topic. With this change we would also be sending same activation
record on another topic. So we have another choice to make
