Michele,
I like the idea to make the ActionLoop based runtimes to be runnable on Knative.
My thoughts on this:
- I second Markus concern to implement the invocation API onto Knative instead
of just using Knative service syntax.
- I would have concerns to make it dependent on Gloo which is kind o
t 2:07 PM Martin Henke wrote:
>> ...As Knative Build seems be on a dead end...
>
> Wow, already? That stuff seems to be competing with JavaScript
> frameworks in terms of short lifetimes these days ;-)
>
> -Bertrand
> On 20. May 2019, at 14:55, Michele Sciabarra wrote:
>
>> Michele,
>
>> I like the idea to make the ActionLoop based runtimes to be runnable on
>> Knative.
>>
>> My thoughts on this:
>> - I second Markus concern to implement the invocation API onto Knative
>> instead of just using Knative
; 1. *wsk action create* actually doing all the pieces necessary to run a
> piece of code on Knative.
> 2. *wsk action invoke* doing some HTTP call under the hood to "invoke" that
> action. The action should be reachable via a sensible URL. If we really
> want to keep th
Rodrics latest updates to the nodeJs runtime uncovered that some of our NodeJs
test actions are using variables in the global scope (by omitting the let or
var keywords). The related tests are now failing in the Travis build.
I opened https://github.com/apache/incubator-openwhisk/pull/4514 to fi
is by restoring the behavior as noted in #136. I did add a test
> in the latter inspired by the code that broke in the former.
>
> -r
>
>> On Tue, Jun 18, 2019 at 11:49 AM Martin Henke wrote:
>>
>> Rodrics latest updates to the nodeJs runtime uncovered that some of o
Rodric,
IBM Cloud Functions hasn’t implemented OAuth, but JWT based bearer token based
authentication based on the IBM Cloud IAM system.
The first problem we encountered was that our bearer token did not provide a
namespace related context
(which is only configured in the IAM system). The only
voke" that>
> action. The action should be reachable via a sensible URL. If we really>
> want to keep the API surface (as I said, I'm dubious here) we can also do>
> that via ingress level abstractions (like VirtualService).>
>
> Cheers,>
> Markus>
ers either by env. vars. or
> function arguments allowing both compat. with 12-factor app approach, as
> well as attempting to encourage a functional programming model where you
> should ideally be unaware of any system environment.
>
> Kind regards,
> Matt
>
>
>
>
Strongly + 1 to put core changes behind feature flags so that they can be
rolled out (and removed if necessary )
in a controlled way.
Tests should be running successfully for having the feature flag enabled or
disabled.
In the near past it took a considerable amount of my time to adapt test case
Dominic,
I would very much like to have this change introduced in a backward compatible
fashion.
In Detail:
The default permissions should either keep the same behaviour as with the
current code
or better be configurable via Ansible in a way that he system behaves the same
as before.
If you
Michele,
Two thoughts:
1) For writing a controller in Knative I recommend to choose Go instead of
Rust (even when I like Rust more).
With Go you can leverage the fantastic Operator SDK from Redhat which makes
writing controllers fairly
simple (I had my first one up and running in under an hour
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 ?
Rodric, Chetan, Carlos,
after checking our (IBM Functions) production logs we see minor usage of the
projection feature
(.text and .json).
That means that we (IBM Functions) need to notify these customers to make them
adapt their action code
and/or URLs to the removed feature.
I would like
Rodric, Carlos,
I am fine too with the cut of date on December 1st. This will allow us to
deprecate this feature in a coordinated way.
Thanks for your help,
Martin
> Am 31.08.2019 um 15:29 schrieb Carlos Santana :
>
>
> I was never a fan of projections, very clever trick but the idea that an
Rodric,
thank you for taking on this dangling task.
Since we saw some severe performance impacts when we tried to move OW to other
Java 8 JDK versions
before, we would like to run the final change through our performance tests.
Therefore I would like to ask for a short deferral until midth of
Do you or others plan to contribute any of the
> performance testing that you're doing/will do to the project - and what
> would it take to facilitate this so that we are also increasing the project
> velocity?
>
> -r
>
>> On Sat, Dec 21, 2019 at 5:08 AM Martin Henke
vironment details/how it’s different from
> the Jenkins job Vincent set up at one point for the project - so that any
> testing important to the project can be done in apache land.
>
> -r
>
>> On Dec 22, 2019, at 9:35 AM, Martin Henke wrote:
>>
>> Rodric,
>>
Rodric,
I forgot to mention. When we find a degradation (and I honestly do not hope to
see one) and we find the reason, we will of course share the information needed
to setup tests in the Apache environment to catch those.
Regards,
Martin
> Am 22.12.2019 um 20:29 schrieb Martin He
un in Jenkins if
> anything you’re doing differently so that the project can replicate and
> automate it where necessary. >
>
> -r>
>
> > On Dec 22, 2019, at 2:34 PM, Martin Henke wrote:>
> > >
> > Rodric,>
> > >
> > I forgot to menti
uuid - do you know that's implicated or a guess?
>
> -r
>
>> On Tue, Jan 28, 2020 at 8:05 AM Martin Henke wrote:
>>
>> Folks,
>>
>> as indicated, we performed performance tests of the OpenJDK upgrade PR
>> https://github.com/apache/openwhisk/pul
Hi,
free Travis usage will be ending for open source projects end of the year.
See:
https://mailchi.mp/3d439eeb1098/travis-ciorg-is-moving-to-travis-cicom
https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
Open source projects will migrated to trial accounts in travis-ci.com with some
Dave,
that sounds like we do not have the problem I was anticipating when reading the
news.
Thank you for taking care.
Regards,.
Martin
> On 29. Nov 2020, at 18:03, David P Grove wrote:
>
>
>
>
> Carlos Santana wrote on 11/20/2020 10:23:37 AM:
>>
>> Our current usage of Travis for OpenWh
My name is Martin Henke.
I have joined the Cloud Functions team of IBM a short while ago.
Before joining this team I have worked in several Cloud related products
and project in IBM.
I am looking forward to contribute to the Apache OpenWhisk project and
to work with the amazing people on this
My name is Martin Henke.
I have joined the Cloud Functions team of IBM a short while ago.
Before joining this team I have worked in several Cloud related products
and project in IBM.
I am looking forward to contribute to the Apache OpenWhisk project and
to work with the amazing people on this
Tyson,
thank you for your comments.
Since Vadim is away today I will try to answer.
I fully agree that we should keep the logging back-end discussion
separate. Therefore I am with you to tackle this in a first PR that
changes the logging implementation to Logback (with the console appender
co
Hi,
we have showed in recent dev calls that the amount of logs the
controllers and invoker write out to the log files does harm the
performance under high load severely.
To reduce that burden we introduced the new metric infrastructure based
on Kamon
which is already delivered (but switched
Hello,
this is a kind reminder for our bi-weekly Tech Interchange Meeting tomorrow.
The proposed agenda up to now is:
- Introduction of new attendees
- Asking around for notable changes/updates
- Updates on the graduation / release mgmt. process for OpenWhisk by Vincent S
Hou [20 min]
- Shardin
This is another kind reminder for our bi-weekly Tech Interchange Meeting today.
The (updated) agenda up to now is:
- Introduction of new attendees
- Asking around for notable changes/updates
- Updates on the graduation / release mgmt. process for OpenWhisk by Vincent S
Hou [20 min]
- License hea
Hi,
as some of you might have noticed with my last commit so please take this mail
as a heads-up.
I am on the road to introduce extensibility for the authentication and
entitlement in Openwhisk.
The changes are motivated by the need to integrate Openwhisk tighter into
an existing (but unfortuna
Andy,
sorry for answering late. I was some days out and then dragged into other work.
Let me try to explain the things we want to do with our IAM integration.
After having the needed extension points available (as explained in my last
mail) we plan to implement an authentication
directive that
Hi Vinuri,
good to see that IAM integration seems to be a feature that is also needed by
other parties.
As announced on this list yesterday I am also working on integrating Openwhisk
into an existing IAM system.
Please see my last reply on the " Extending Authentication and Entitlement -
Heads
Andy,
I just opened the pull request for the entitlement SPI
(Please see: https://github.com/apache/incubator-openwhisk/pull/3822)
As you can see it implements the existing EntitlementProvider interface as SPI
without changing it. I think it would be still easy to adapt it according to
your
pr
33 matches
Mail list logo
