Sven, all,
That's a good call-out.
In consequence to that: how about we discuss larger changes with
a) a test script that simulates the types of load under discussion (and at the
same time makes it clear which types of load are ignored for now) and
b) a declaration of the KPIs one seeks to
This is one of the situations where having some sort of proposal
process can help align the various people and technical considerations
a bit easier than mailing lists and PRs. There are numerous other
communities with similar proposal processes (e.g., SIPs for Scala,
KIPs for Kafka, JEPs and JSRs
Hello Dominic and other discussion participants,
we are in the great situation that Dominic (style95) volunteers to create
and verify an alternative OpenWhisk architecture that may solve some of
the problems that adopters of OpenWhisk may observe when running
production systems with high
Ooh, I love feature flags. I don’t know enough details to say whether an
incremental refactoring like that would work here, but it’s usually a
better idea than a full rewrite.
On Thu, Jul 18, 2019 at 08:07, Rodric Rabbah wrote:
> We should put together a roadmap that shows the evolution and all
We should put together a roadmap that shows the evolution and all presents a
coherent view of all the moving parts.
-r
> On Jul 18, 2019, at 8:52 AM, Markus Thömmes wrote:
>
> Hi,
>
> this sounds a lot like the "OpenWhisk 2.0" discussion we had in an older
> thread where I proposed an
> It must not break any existing downstream system as well as the upstream
> pipelines. So all implementations should be disabled by default along with
> proper
> switches.
Agreed. There is a feature flag class that Chetan introduced when I introduced
a breaking change (sorry) a few months
Hi,
this sounds a lot like the "OpenWhisk 2.0" discussion we had in an older
thread where I proposed an architectural overhaul. See this thread for
context:
https://lists.apache.org/thread.html/d19306dd976138a153f48d32c5a55f2853e4b8ff405fc46f7260e905@%3Cdev.openwhisk.apache.org%3E
There have
Recently I discussed the direction and a safe way to add a new component
with Sven Lange-Last.
Let me share the discussion results.
More feedbacks and critique are welcomed.
Since the implementation includes a breaking architectural change, it comes
with a risk.
It must not break any existing
