Justin Mclean wrote on 06/25/2019 04:37:37 PM:
>
> I see you marked the docker images as convenience binaries but they
> still seem to point to the latest code in the repos. Is this
> correct? Convenience binaries need to be based on released versions
> of the source code. [1] I'd suggest you
Dave and I conferred and we've agreed he's in a better position today to
chair the PMC. I'm happy to be in a able to learn from him in the inaugural
year, assuming a successful petition to graduate.
-r
On Tue, Jun 25, 2019 at 5:04 PM Matt Rutkowski
wrote:
>
> This PMC Chair nominations thread
Hi,
I see you marked the docker images as convenience binaries but they still seem
to point to the latest code in the repos. Is this correct? Convenience
binaries need to be based on released versions of the source code. [1] I'd
suggest you discuss this with your mentors.
Thanks,
Justin
1.
In an earlier email discussion [1] Tyson noted the previously
discussed idea of using a context object per activation in lieu of
environment variables which are currently exported by the
system/runtime per activation. This was previously discussed in [2]
and is necessary to separate
Context and Knative I view as orthogonal.
That is, for the context object, it is another way of encapsulating arguments.
It doesn’t export variable to the process environment.
You can provide an action with both environment variables, arguments to main,
and a context object. They are
I had to read this several times, but have some suggestions. I think when you
say "action's arguments", you mean action-configured params, e.g. `wsk action
create --param p1 v1`?
My preferences would be:
- we should split off "run" args into context and params - this is the
convention change
Hi Rodric,
Have many thoughts on this having just experienced them all when mapping our OW
"runtime contract" to Knative... but first would ask a couple of things based
on your historic knowledge...
M1) Do you have a specific use case which highlights the issue (i.e., caused
you to think on
This PMC Chair nominations thread is closed. Will reach out to both Dave and
Rodric, as both appeared to defer to each other, to see if either wants to step
back and perhaps we can reduce the need for a competitive VOTE (and have just
an affirmation VOTE as this may be asked for) and move
Just made a pass through all images under the "openwhisk" moniker on Docker Hub:
https://hub.docker.com/u/openwhisk/
assuring all have valid (short) descriptions and long descriptions that clearly
describe each belonging to our Apache project proper (adapting 2 examples from
other Apache
Using JWT with independently distributed keys for verifying authorization
info has worked best for overall performance in my experience so far (in
microservices generally; not tested with OW). Using that pattern minimizes
auth server contact thanks to cryptographic verification of the JWT. Also
That is incredible. Great work Chetan! I've been playing around with
it and have no issues so far...
Would love to starting using this in the CI/CD setups for some of the
repos I work on to massively improve the CI/CD delay in testing new
PRs.
On Tue, 25 Jun 2019 at 14:00, Rodric Rabbah wrote:
I tried this out - it is awesome... and fast!
-r
On Mon, Jun 24, 2019 at 6:08 AM Chetan Mehrotra
wrote:
> 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
>
I would like to talk and demonstrate the OpenWhisk Standalone Server mode
Chetan Mehrotra
On Tue, Jun 25, 2019 at 3:55 PM James Thomas wrote:
>
> Does anyone have anything for the meeting on Wednesday? I can add you
> to the agenda as I'm running the call. I know there's lots of exciting
>
Does anyone have anything for the meeting on Wednesday? I can add you
to the agenda as I'm running the call. I know there's lots of exciting
stuff going on from the mailing list so if anyone wants to share on
the call - let me know!
--
Regards,
James Thomas
jthomas commented on issue #7: Set up Travis to publish images to Docker Hub
URL:
https://github.com/apache/incubator-openwhisk-pluggable-provider/issues/7#issuecomment-505382910
The build process is broken
> For B1, we can scale out the service as controllers are scaled out, but it
> would be much complex to manually assign topics.
Yes thats what my concern was in B1. So would for now target B2
approach where we have a dedicated new topic and then have it consumed
by a new service. If it poses
16 matches
Mail list logo
