Re: [VOTE] Release Apache Apache OpenWhisk Client Js (v3.20.0, rc2)
+1 I could observe all the checklists passed. computing sha512 for openwhisk-client-js-3.20.0-sources.tar.gz SHA512: openwhisk-client-js-3.20.0-sources.tar.gz: 5FEF999E 532BD0C1 6C8BC0A1 F5232C93 964A30CF F14B2D82 1C8A2E1D 1106339C E2457918 C9873B3B 26FB4711 4FBA6F1C 8C8A62A8 3D50592C F9617EA5 54827EBA validating sha512... passed verifying asc... passed (signed-by: James Thomas ) verifing notice... passed verifying absence of DISCLAIMER.txt passed verifying license... passed verifying sources have proper headers... passed scanning for executable files... passed scanning for non-text files... passed scanning for archives... passed scanning for packages... passed Best regards Dominic 2019년 8월 19일 (월) 오후 8:32, James Thomas 님이 작성: > Hi, > > This is a call to vote on releasing version 3.20.0 release candidate > rc2 of the following project module with artifacts built from the Git > repositories and commit IDs listed below. > > * Apache OpenWhisk Client Js: 88ce0e2 > https://github.com/apache/openwhisk-client-js/commits/88ce0e2 > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz.asc > > https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz.sha512 > > This release is comprised of source code distribution only. > > You can use this UNIX script to download the release and verify the > checklist below: > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh > ' > > Usage: > curl -s " > https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh > ;" > -o rcverify.sh > chmod +x rcverify.sh > ./rcverify.sh openwhisk-client-js 'OpenWhisk Client Js' 3.20.0 rc2 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Release verification checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] Source code artifacts have correct names matching the current > release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers as specified by OpenWhisk project > policy [1]. > [ ] No compiled archives bundled in source archive. > > This majority vote is open for at least 72 hours. > > > [1] > https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md > > -- > Regards, > James Thomas >
Re: [Contribution] wskdebug
FYI, a little status update: we are going through the internal legal process for a grant to ASF. Both contributors have signed the ICLA (check) but there might be a few more steps necessary that will take a few days. We will update the IP clearance document once we reach that. Thanks, Alex From: David P Grove Sent: Tuesday, August 13, 2019 14:56 To: dev@openwhisk.apache.org Cc: Jesse MacFadyen ; Fil Maj ; Moritz Raho ; Shazron Abdullah ; Simon Mac Donald Subject: RE: [Contribution] wskdebug Alexander Klimetschek wrote on 08/13/2019 05:06:54 PM: > > thanks. The IP clearance page says "The receiving PMC is responsible > for doing the work." but I am happy to help if there is anything I can do. > Hi. Sorry, I could have done a better job of telling you what I needed you to do. The quoted text really means "the Incubator PMC is _not_responsible for doing any of the work." We still need the people making the donation to do some work as they are the ones who know the history of the code and have the legal standing to donate it. I created a draft IP clearance record at [1]. I can drive the mechanics of the Apache process, but I need your help with (a) a brief description of the code base (b) submitting the appropriate software grant (based on the set of contributors to wskdebug) and (c) completing the sections of the "Copyright" and "Verify distribution rights" of the IP clearance form. --dave [1] https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/openwhisk-wskdebug.xml
Re: Passing TransactionId as part of action invocation
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: Passing TransactionId as part of action invocation
Per my earlier suggestion, if we make the transaction id part of the activation id, and store the set of key/values associated with the transaction id in an external service (redis or couchdb) to be accessed (r/w) on-demand, then I believe the implementation can become completely transparent to "v1" / "legacy" code. However, this solution seems less performant, because of the need to access a 3rd-party service. -- Erez From: Chetan Mehrotra To: dev@openwhisk.apache.org Date: 19/08/2019 18:37 Subject:[EXTERNAL] Re: Passing TransactionId as part of action invocation > 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: Passing TransactionId as part of action invocation
> 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: Passing TransactionId as part of action invocation
> 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: Passing TransactionId as part of action invocation
> What if we make annotations a dictionary?
I would have preferred that as current structure makes it harder to
process them. However changing them now would cause compatibility
issue with various tooling out there which may be interpreting the
annotation per current design
Chetan Mehrotra
On Mon, Aug 19, 2019 at 6:59 AM Rodric Rabbah wrote:
>
> What if we make annotations a dictionary?
>
> -r
>
> On Aug 19, 2019, at 9:54 AM, Chetan Mehrotra
> wrote:
>
> >> I second the idea of recording the request/transaction id as part of the
> >> activation record. We don’t currently do that, but we do have a caused-by
> >> annotation for composite activations. I suggest another annotation which
> >> is the transaction id.
> >
> > There are few other cases where I felt a need to record some "meta"
> > ids in activation
> >
> > 1. While integrating with Lambda or other such compute stack I would
> > like to save the responseId from the backend system in activation so
> > as to enable fetching logs later based on the responseId from previous
> > call.
> > 2. In Mesos or k8s setup one may want to record the Mesos taskId, k8s
> > podId for correlating with some system logs later
> >
> > Should we consider it as yet another annotation or add new sub
> > document `meta` and make it a property there?
> >
> > If we make it an annotation then it becomes tricky to index this
> > property in db due to the document structure. For couchdb you can do
> > it by extracting the key when generating the view but for other db's
> > we typically have to add a computed field at time of persistence.
> >
> > Another option would be to introduce a new sub structure say `meta`
> > where we store such ids as flat keys
> >
> > "meta" : {
> >"transactionId" : "xxx",
> >"podId" : "ow_xxx"
> >}
> >
> > Such an structure would be easier to index compared to one based on
> > annotations
> >
> > Chetan Mehrotra
> >
> >{
> >"activationId": "e40c9340aea340f58c9340aea320f5e9",
> >"annotations": [
> >{
> >"key": "causedBy",
> >"value": "sequence"
> >},
> >{
> >"key": "kind",
> >"value": "nodejs:10"
> >},
> >{
> >"key": "timeout",
> >"value": false
> >},
> >{
> >"key": "limits",
> >"value": {
> >"concurrency": 200,
> >"logs": 10,
> >"memory": 256,
> >"timeout": 6
> >}
> >}
> >],
> >"cause": "f3380aaeca7d4791b80aaeca7d5791f6",
> >"duration": 5015,
> >"end": 1562344247086,
> >"entityType": "activation",
> >"response": { ... },
> >"start": 1562344242071,
> >
> >}
> >
> >> On Mon, Aug 19, 2019 at 5:34 AM Rodric Rabbah wrote:
> >>
> >> I second the idea of recording the request/transaction id as part of the
> >> activation record. We don’t currently do that, but we do have a caused-by
> >> annotation for composite activations. I suggest another annotation which
> >> is the transaction id.
> >>
> >> Chetan’s pr is straightforward and I think achieves the goal of linking
> >> parents to children for external tracing.
> >>
> >> -r
> >>
> >>> On Aug 19, 2019, at 5:02 AM, Erez Hadad wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> My two cents: recall my "shared context" presentation about using a
> >>> semi-transparent execution context that is shared across multiple
> >>> consequent invocations. Similar to the transaction id being discussed.
> >>> https://cwiki.apache.org/confluence/download/attachments/74689638/Shared%20Context%20in%20OpenWhisk%20Invocations.pptx?api=v2
> >>>
> >>> Specifically, you may want to consider the implementation options in slide
> >>> 11:
> >>> 1. One particular option of interest is to embed the shared context id ( =
> >>> transaction id) in the activation id. When the new activation id is
> >>> generated, the transaction id can be taken from the caller's activation id
> >>> and embedded in the new activation id. This way the activation id remains
> >>> unique per invocation but the transaction id can be extracted from it if
> >>> needed, manually or via a client library (e.g., extending the OW js
> >>> library). Kind of a minimal change.
> >>> 2. Another possibly valuable option is to have the transaction id used as
> >>> a key for retrieving data (e.g., key/value) from a 3rd-party fast service,
> >>> such as redis. This can be left open for the user of the transaction id or
> >>> provide a reference implementation in the client library. Such data can
> >>> also be pre-fetched before the invocation starts (e.g., from CouchDB /
> >>> Redis), but again, at the cost of a higher code change.
> >>>
> >>> Regards,
> >>> -- Erez
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> From: Rodric Rabbah
> >>> To:
Re: Passing TransactionId as part of action invocation
What if we make annotations a dictionary?
-r
On Aug 19, 2019, at 9:54 AM, Chetan Mehrotra wrote:
>> I second the idea of recording the request/transaction id as part of the
>> activation record. We don’t currently do that, but we do have a caused-by
>> annotation for composite activations. I suggest another annotation which is
>> the transaction id.
>
> There are few other cases where I felt a need to record some "meta"
> ids in activation
>
> 1. While integrating with Lambda or other such compute stack I would
> like to save the responseId from the backend system in activation so
> as to enable fetching logs later based on the responseId from previous
> call.
> 2. In Mesos or k8s setup one may want to record the Mesos taskId, k8s
> podId for correlating with some system logs later
>
> Should we consider it as yet another annotation or add new sub
> document `meta` and make it a property there?
>
> If we make it an annotation then it becomes tricky to index this
> property in db due to the document structure. For couchdb you can do
> it by extracting the key when generating the view but for other db's
> we typically have to add a computed field at time of persistence.
>
> Another option would be to introduce a new sub structure say `meta`
> where we store such ids as flat keys
>
> "meta" : {
>"transactionId" : "xxx",
>"podId" : "ow_xxx"
>}
>
> Such an structure would be easier to index compared to one based on
> annotations
>
> Chetan Mehrotra
>
>{
>"activationId": "e40c9340aea340f58c9340aea320f5e9",
>"annotations": [
>{
>"key": "causedBy",
>"value": "sequence"
>},
>{
>"key": "kind",
>"value": "nodejs:10"
>},
>{
>"key": "timeout",
>"value": false
>},
>{
>"key": "limits",
>"value": {
>"concurrency": 200,
>"logs": 10,
>"memory": 256,
>"timeout": 6
>}
>}
>],
>"cause": "f3380aaeca7d4791b80aaeca7d5791f6",
>"duration": 5015,
>"end": 1562344247086,
>"entityType": "activation",
>"response": { ... },
>"start": 1562344242071,
>
>}
>
>> On Mon, Aug 19, 2019 at 5:34 AM Rodric Rabbah wrote:
>>
>> I second the idea of recording the request/transaction id as part of the
>> activation record. We don’t currently do that, but we do have a caused-by
>> annotation for composite activations. I suggest another annotation which is
>> the transaction id.
>>
>> Chetan’s pr is straightforward and I think achieves the goal of linking
>> parents to children for external tracing.
>>
>> -r
>>
>>> On Aug 19, 2019, at 5:02 AM, Erez Hadad wrote:
>>>
>>> Hi folks,
>>>
>>> My two cents: recall my "shared context" presentation about using a
>>> semi-transparent execution context that is shared across multiple
>>> consequent invocations. Similar to the transaction id being discussed.
>>> https://cwiki.apache.org/confluence/download/attachments/74689638/Shared%20Context%20in%20OpenWhisk%20Invocations.pptx?api=v2
>>>
>>> Specifically, you may want to consider the implementation options in slide
>>> 11:
>>> 1. One particular option of interest is to embed the shared context id ( =
>>> transaction id) in the activation id. When the new activation id is
>>> generated, the transaction id can be taken from the caller's activation id
>>> and embedded in the new activation id. This way the activation id remains
>>> unique per invocation but the transaction id can be extracted from it if
>>> needed, manually or via a client library (e.g., extending the OW js
>>> library). Kind of a minimal change.
>>> 2. Another possibly valuable option is to have the transaction id used as
>>> a key for retrieving data (e.g., key/value) from a 3rd-party fast service,
>>> such as redis. This can be left open for the user of the transaction id or
>>> provide a reference implementation in the client library. Such data can
>>> also be pre-fetched before the invocation starts (e.g., from CouchDB /
>>> Redis), but again, at the cost of a higher code change.
>>>
>>> Regards,
>>> -- Erez
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: Rodric Rabbah
>>> To: dev@openwhisk.apache.org
>>> Cc: tyson.nor...@gmail.com
>>> Date: 17/08/2019 03:36
>>> Subject:[EXTERNAL] Re: Passing TransactionId as part of action
>>> invocation
>>>
>>>
>>>
>>> Of course if the transaction id is the same as the activation id (of the
>>> composite action) the solutions are comparable.
>>>
>>> The downside of using transaction id is that we have no APIs to query by
>>> it today, and it?s not recorded in the activation metadata. So while it?s
>>> useful for external tracing (no objections to doing it), I think from an
>>>
Re: Passing TransactionId as part of action invocation
> I second the idea of recording the request/transaction id as part of the
> activation record. We don’t currently do that, but we do have a caused-by
> annotation for composite activations. I suggest another annotation which is
> the transaction id.
There are few other cases where I felt a need to record some "meta"
ids in activation
1. While integrating with Lambda or other such compute stack I would
like to save the responseId from the backend system in activation so
as to enable fetching logs later based on the responseId from previous
call.
2. In Mesos or k8s setup one may want to record the Mesos taskId, k8s
podId for correlating with some system logs later
Should we consider it as yet another annotation or add new sub
document `meta` and make it a property there?
If we make it an annotation then it becomes tricky to index this
property in db due to the document structure. For couchdb you can do
it by extracting the key when generating the view but for other db's
we typically have to add a computed field at time of persistence.
Another option would be to introduce a new sub structure say `meta`
where we store such ids as flat keys
"meta" : {
"transactionId" : "xxx",
"podId" : "ow_xxx"
}
Such an structure would be easier to index compared to one based on annotations
Chetan Mehrotra
{
"activationId": "e40c9340aea340f58c9340aea320f5e9",
"annotations": [
{
"key": "causedBy",
"value": "sequence"
},
{
"key": "kind",
"value": "nodejs:10"
},
{
"key": "timeout",
"value": false
},
{
"key": "limits",
"value": {
"concurrency": 200,
"logs": 10,
"memory": 256,
"timeout": 6
}
}
],
"cause": "f3380aaeca7d4791b80aaeca7d5791f6",
"duration": 5015,
"end": 1562344247086,
"entityType": "activation",
"response": { ... },
"start": 1562344242071,
}
On Mon, Aug 19, 2019 at 5:34 AM Rodric Rabbah wrote:
>
> I second the idea of recording the request/transaction id as part of the
> activation record. We don’t currently do that, but we do have a caused-by
> annotation for composite activations. I suggest another annotation which is
> the transaction id.
>
> Chetan’s pr is straightforward and I think achieves the goal of linking
> parents to children for external tracing.
>
> -r
>
> > On Aug 19, 2019, at 5:02 AM, Erez Hadad wrote:
> >
> > Hi folks,
> >
> > My two cents: recall my "shared context" presentation about using a
> > semi-transparent execution context that is shared across multiple
> > consequent invocations. Similar to the transaction id being discussed.
> > https://cwiki.apache.org/confluence/download/attachments/74689638/Shared%20Context%20in%20OpenWhisk%20Invocations.pptx?api=v2
> >
> > Specifically, you may want to consider the implementation options in slide
> > 11:
> > 1. One particular option of interest is to embed the shared context id ( =
> > transaction id) in the activation id. When the new activation id is
> > generated, the transaction id can be taken from the caller's activation id
> > and embedded in the new activation id. This way the activation id remains
> > unique per invocation but the transaction id can be extracted from it if
> > needed, manually or via a client library (e.g., extending the OW js
> > library). Kind of a minimal change.
> > 2. Another possibly valuable option is to have the transaction id used as
> > a key for retrieving data (e.g., key/value) from a 3rd-party fast service,
> > such as redis. This can be left open for the user of the transaction id or
> > provide a reference implementation in the client library. Such data can
> > also be pre-fetched before the invocation starts (e.g., from CouchDB /
> > Redis), but again, at the cost of a higher code change.
> >
> > Regards,
> > -- Erez
> >
> >
> >
> >
> >
> >
> > From: Rodric Rabbah
> > To: dev@openwhisk.apache.org
> > Cc: tyson.nor...@gmail.com
> > Date: 17/08/2019 03:36
> > Subject:[EXTERNAL] Re: Passing TransactionId as part of action
> > invocation
> >
> >
> >
> > Of course if the transaction id is the same as the activation id (of the
> > composite action) the solutions are comparable.
> >
> > The downside of using transaction id is that we have no APIs to query by
> > it today, and it?s not recorded in the activation metadata. So while it?s
> > useful for external tracing (no objections to doing it), I think from an
> > openwhisk API point of view we still have a gap.
> >
> > -r
> >
> > On Aug 16, 2019, at 4:58 PM, Chetan Mehrotra
> > wrote:
> >
> >>> I think if OW SDK, and sequences/compositions, propagate X-Request-Id
> >>> header (using the existing
Re: Passing TransactionId as part of action invocation
I second the idea of recording the request/transaction id as part of the activation record. We don’t currently do that, but we do have a caused-by annotation for composite activations. I suggest another annotation which is the transaction id. Chetan’s pr is straightforward and I think achieves the goal of linking parents to children for external tracing. -r > On Aug 19, 2019, at 5:02 AM, Erez Hadad wrote: > > Hi folks, > > My two cents: recall my "shared context" presentation about using a > semi-transparent execution context that is shared across multiple > consequent invocations. Similar to the transaction id being discussed. > https://cwiki.apache.org/confluence/download/attachments/74689638/Shared%20Context%20in%20OpenWhisk%20Invocations.pptx?api=v2 > > Specifically, you may want to consider the implementation options in slide > 11: > 1. One particular option of interest is to embed the shared context id ( = > transaction id) in the activation id. When the new activation id is > generated, the transaction id can be taken from the caller's activation id > and embedded in the new activation id. This way the activation id remains > unique per invocation but the transaction id can be extracted from it if > needed, manually or via a client library (e.g., extending the OW js > library). Kind of a minimal change. > 2. Another possibly valuable option is to have the transaction id used as > a key for retrieving data (e.g., key/value) from a 3rd-party fast service, > such as redis. This can be left open for the user of the transaction id or > provide a reference implementation in the client library. Such data can > also be pre-fetched before the invocation starts (e.g., from CouchDB / > Redis), but again, at the cost of a higher code change. > > Regards, > -- Erez > > > > > > > From: Rodric Rabbah > To: dev@openwhisk.apache.org > Cc: tyson.nor...@gmail.com > Date: 17/08/2019 03:36 > Subject:[EXTERNAL] Re: Passing TransactionId as part of action > invocation > > > > Of course if the transaction id is the same as the activation id (of the > composite action) the solutions are comparable. > > The downside of using transaction id is that we have no APIs to query by > it today, and it?s not recorded in the activation metadata. So while it?s > useful for external tracing (no objections to doing it), I think from an > openwhisk API point of view we still have a gap. > > -r > > On Aug 16, 2019, at 4:58 PM, Chetan Mehrotra > wrote: > >>> I think if OW SDK, and sequences/compositions, propagate X-Request-Id >>> header (using the existing transaction id/X-Request-Id), the parent is > not >>> needed? >> >> Thats what I counting on as we just need to correlate calls made for a >> given flow corelated with time to get a sequence of flow. >> >>> - expose the transaction id to runtime container >>> - propagate the transaction id in requests initiated from runtime >>> container/controller >> >> Makes sense. Would open a ticket capturing these changes then >> Chetan Mehrotra >> >>> On Fri, Aug 16, 2019 at 7:44 AM Tyson Norris > wrote: >>> >>> I think if OW SDK, and sequences/compositions, propagate X-Request-Id >>> header (using the existing transaction id/X-Request-Id), the parent is > not >>> needed? i.e. there may be 2 parts to this effort: >>> - expose the transaction id to runtime container >>> - propagate the transaction id in requests initiated from runtime >>> container/controller >>> >>> >>> On Thu, Aug 15, 2019 at 10:38 AM Rodric Rabbah > wrote: In general yes but I think generally do you need the transaction id or > the parent id for an activation? This issue is relevant - > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk_issues_3083=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Oo9B0p_tCCWIIum5GpjjqA=RVvqHH3EKTdA9cNFz3n2dPeXV_wFUOU01I5vxvAqt8Q=eZzttWaoeE0WFe_MndFO1O6K1wA9hZbc-BKbRZa6kDM= > > . I also recall in the early days of the composer, we wanted a way to > query parent/child activations but this requires new couch views and we > didn't pursue it. On Thu, Aug 15, 2019 at 1:20 PM Chetan Mehrotra > wrote: > Currently we pass the `activation_id` as part of `/run` call to any > action runtime [1]. Would it be fine to also pass the `TransactionId` > such that it can be accessed by action code? > > One usecase of this would be to enable tracing a sequence/composition > by linking all activations which are part of same transaction in > epsagon [2] > > Chetan Mehrotra > [1] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk_blob_master_docs_actions-2Dnew.md-23activation=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Oo9B0p_tCCWIIum5GpjjqA=RVvqHH3EKTdA9cNFz3n2dPeXV_wFUOU01I5vxvAqt8Q=-vjUf19hoPEdgOTjnbs7jjHFqsJhWIRJjQSQYIme8xw= > > > [2] >
[VOTE] Release Apache Apache OpenWhisk Client Js (v3.20.0, rc2)
Hi, This is a call to vote on releasing version 3.20.0 release candidate rc2 of the following project module with artifacts built from the Git repositories and commit IDs listed below. * Apache OpenWhisk Client Js: 88ce0e2 https://github.com/apache/openwhisk-client-js/commits/88ce0e2 https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz.asc https://dist.apache.org/repos/dist/dev/openwhisk/apache-openwhisk-3.20.0-rc2/openwhisk-client-js-3.20.0-sources.tar.gz.sha512 This release is comprised of source code distribution only. You can use this UNIX script to download the release and verify the checklist below: https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh' Usage: curl -s "https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;; -o rcverify.sh chmod +x rcverify.sh ./rcverify.sh openwhisk-client-js 'OpenWhisk Client Js' 3.20.0 rc2 Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... Release verification checklist for reference: [ ] Download links are valid. [ ] Checksums and PGP signatures are valid. [ ] Source code artifacts have correct names matching the current release. [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. [ ] All files have license headers as specified by OpenWhisk project policy [1]. [ ] No compiled archives bundled in source archive. This majority vote is open for at least 72 hours. [1] https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md -- Regards, James Thomas
Re: Speeding up a tekton build
I show also some numbers. This is the log of an action build running on a mac with 32 GB ./build.sh taskrun.tekton.dev/kwhisk-build-1566207093 created NAME READY STATUS RESTARTS AGE controller 2/2 Running 0 15m kaniko-load-cache-w7p9f 0/1 Completed 0 15m kwhisk-build-1566206965-pod-9e2c26 0/4 Completed 0 2m8s kwhisk-build-1566207093-pod-207db6 0/4 Pending 0 0s kwhisk-build-1566207093-pod-207db6 0/4 Init:0/30 1s kwhisk-build-1566207093-pod-207db6 0/4 Init:1/30 9s kwhisk-build-1566207093-pod-207db6 0/4 Init:2/30 10s kwhisk-build-1566207093-pod-207db6 0/4 PodInitializing 0 11s kwhisk-build-1566207093-pod-207db6 4/4 Running 0 13s kwhisk-build-1566207093-pod-207db6 4/4 Running 0 13s kwhisk-build-1566207093-pod-207db6 2/4 Running 0 16s kwhisk-build-1566207093-pod-207db6 1/4 Running 0 70s kwhisk-build-1566207093-pod-207db6 0/4 Completed 0 71s On a recent Mac with 32GB it takes 71 seconds. On a server with Linux and 64GB it takes 50s, on a Mac with 16gb it takes 10 minutes. I cannot think of making the build simpler. It is only one step build, that download data from a git repository and pushes a very thin layer on a docker registry. I cached the base image with kaniko. I am very seriously concerned about this situation. -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Michele Sciabarra To: dev@openwhisk.apache.org Subject: Speeding up a tekton build Date: Monday, August 19, 2019 6:59 AM Hello Whiskers, I created a tekton build using a modified version of the actionloop runtime. Code here: https://github.com/sciabarracom/openwhisk-knative/blob/master/installer/kwhisk/build-task.yml I tried also to setup a cache for Kaniko and preload the image: https://github.com/sciabarracom/openwhisk-knative/blob/master/installer/kwhisk/kaniko-cache.yaml However when I try to build the image it takes a lot, really a lot of time. Several minutes, often more than 10minutes. The build executed with docker takes just a few seconds . Anyone shares my experience with knative build speed? This is a serious problem because creating an image is essential to be able to use knative serving. -- Michele Sciabarra mich...@sciabarra.com
Re: Re: Passing TransactionId as part of action invocation
Hi folks, My two cents: recall my "shared context" presentation about using a semi-transparent execution context that is shared across multiple consequent invocations. Similar to the transaction id being discussed. https://cwiki.apache.org/confluence/download/attachments/74689638/Shared%20Context%20in%20OpenWhisk%20Invocations.pptx?api=v2 Specifically, you may want to consider the implementation options in slide 11: 1. One particular option of interest is to embed the shared context id ( = transaction id) in the activation id. When the new activation id is generated, the transaction id can be taken from the caller's activation id and embedded in the new activation id. This way the activation id remains unique per invocation but the transaction id can be extracted from it if needed, manually or via a client library (e.g., extending the OW js library). Kind of a minimal change. 2. Another possibly valuable option is to have the transaction id used as a key for retrieving data (e.g., key/value) from a 3rd-party fast service, such as redis. This can be left open for the user of the transaction id or provide a reference implementation in the client library. Such data can also be pre-fetched before the invocation starts (e.g., from CouchDB / Redis), but again, at the cost of a higher code change. Regards, -- Erez From: Rodric Rabbah To: dev@openwhisk.apache.org Cc: tyson.nor...@gmail.com Date: 17/08/2019 03:36 Subject:[EXTERNAL] Re: Passing TransactionId as part of action invocation Of course if the transaction id is the same as the activation id (of the composite action) the solutions are comparable. The downside of using transaction id is that we have no APIs to query by it today, and it?s not recorded in the activation metadata. So while it?s useful for external tracing (no objections to doing it), I think from an openwhisk API point of view we still have a gap. -r On Aug 16, 2019, at 4:58 PM, Chetan Mehrotra wrote: >> I think if OW SDK, and sequences/compositions, propagate X-Request-Id >> header (using the existing transaction id/X-Request-Id), the parent is not >> needed? > > Thats what I counting on as we just need to correlate calls made for a > given flow corelated with time to get a sequence of flow. > >> - expose the transaction id to runtime container >> - propagate the transaction id in requests initiated from runtime >> container/controller > > Makes sense. Would open a ticket capturing these changes then > Chetan Mehrotra > >> On Fri, Aug 16, 2019 at 7:44 AM Tyson Norris wrote: >> >> I think if OW SDK, and sequences/compositions, propagate X-Request-Id >> header (using the existing transaction id/X-Request-Id), the parent is not >> needed? i.e. there may be 2 parts to this effort: >> - expose the transaction id to runtime container >> - propagate the transaction id in requests initiated from runtime >> container/controller >> >> >> >>> On Thu, Aug 15, 2019 at 10:38 AM Rodric Rabbah wrote: >>> >>> In general yes but I think generally do you need the transaction id or the >>> parent id for an activation? >>> >>> This issue is relevant - https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk_issues_3083=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Oo9B0p_tCCWIIum5GpjjqA=RVvqHH3EKTdA9cNFz3n2dPeXV_wFUOU01I5vxvAqt8Q=eZzttWaoeE0WFe_MndFO1O6K1wA9hZbc-BKbRZa6kDM= . >>> I also recall in the early days of the composer, we wanted a way to query >>> parent/child activations but this requires new couch views and we didn't >>> pursue it. >>> >>> >>> >>> On Thu, Aug 15, 2019 at 1:20 PM Chetan Mehrotra >>> >>> wrote: >>> Currently we pass the `activation_id` as part of `/run` call to any action runtime [1]. Would it be fine to also pass the `TransactionId` such that it can be accessed by action code? One usecase of this would be to enable tracing a sequence/composition by linking all activations which are part of same transaction in epsagon [2] Chetan Mehrotra [1] >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk_blob_master_docs_actions-2Dnew.md-23activation=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Oo9B0p_tCCWIIum5GpjjqA=RVvqHH3EKTdA9cNFz3n2dPeXV_wFUOU01I5vxvAqt8Q=-vjUf19hoPEdgOTjnbs7jjHFqsJhWIRJjQSQYIme8xw= [2] >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__epsagon.com_blog_epsagon-2Dmakes-2Dtroubleshooting-2Dapache-2Dopenwhisk-2Da-2Dsnap_=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Oo9B0p_tCCWIIum5GpjjqA=RVvqHH3EKTdA9cNFz3n2dPeXV_wFUOU01I5vxvAqt8Q=IkGq6vR80pwlGlaXAkXHi_rV14IXnX0hc3smCWO8BM8= >>>
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=MnU2dHNiMjc0bTRoc29ydjBscW05Ym1jNmhfMjAxOTA5MDRUMTUwMDAwWiBhcGFjaGVvcGVud2hpc2tAbQ=apacheopenwhisk%40gmail.com=ALL
Re: init parameters
Missed that one. Would review it this week Chetan Mehrotra On Fri, Aug 16, 2019 at 5:39 PM Rodric Rabbah wrote: > > Is anyone up for reviewing this PR > https://github.com/apache/openwhisk/pull/4559 which adds the ability to > separate parameters into init time vs run time? > > It’s been open for a while with no feedback. > Previously discussed here [1] and implemented accordingly. > > -r > > [1] > https://lists.apache.org/thread.html/7e03e6fc965d972882f4c76e34b2e9aa28579a0c3004d63d546e2611@%3Cdev.openwhisk.apache.org%3E
