Hi Dominic, Am Mo., 27. Aug. 2018 um 07:41 Uhr schrieb Dominic Kim <[email protected] >:
> Hey Markus. > > Yes readable activation is a great idea as it would be useful for debugging > and some cases such as you mentioned(groupable activations.) > > BTW, are you suggesting to keep activation generation way in Nginx, and > allow controllers to have parent/child activations in order to avoid > duplicate IDs? > More precisely, controllers will generate ID only in case of triggers and > sequence actions. > So if we make parent/child relationship in controllers only, it won't be > duplicate because there is no such notion in activation generation in > Nginx. > Do I understand correctly? > Yes I think you got that right. Nginx would generate the activationId for the initial trigger fire for example. For each rule the controller invokes then, the controller can generate a child id for that invocation. If we can make that readable, we can easily correlate the parent with the child, giving us even more of a gain from this proposal. So from my PoV: Go for it! > > Thanks > Best regards > Dominic. > > > 2018년 8월 23일 (목) 오후 5:34, Markus Thömmes <[email protected]>님이 작성: > > > Hi Dominic, > > > > this is certainly a good thought and would simplify debugging production > > systems as well. > > > > A rough and dirty idea for the uniqueness issue you mentioned: > > What if we just append a suffix for each of the child ids (essentially > they > > are in a parent/child relationship). A simple example: > > > > Sequence action invoke, Router generated id: abc-def (used as > TransactionId > > and ActivationId) > > Invocation of the first action: abc-def-1 > > Invocation of the second action: abc-def-2 > > ... > > > > The suffix doesn't necessarily need to be a number, but especially in the > > case of sequences, that could greatly help observability and > understanding > > what's going on. It'd also help operators, because the respective > requests > > would be groupable (logwise) by the respective "BaseActivationId" > (abc-def > > in the example). As the ActivationId no longer needs to be a UUID anyway, > > we can do whatever we want to do with it. > > > > If we use numbers, we need to ensure consistent generation of these of > > course. I think though, both Triggers and Sequence invocations will only > be > > handled locally by one Controller, so it can hand out the numbers > > guaranteeing they don't overlap. > > > > What do you think? > > > > Cheers, > > Markus > > > > Am Do., 23. Aug. 2018 um 05:39 Uhr schrieb Dominic Kim < > > [email protected] > > >: > > > > > Dear whiskers. > > > > > > This is to discuss to whether we will allow using TransactionID as > > > ActivationID. > > > Some of discussion history is here: > > > https://github.com/apache/incubator-openwhisk/pull/3671 > > > > > > As that PR is merged, now ActivationID is included in response headers. > > > > > > Currently, TransactionID is being generated in Nginx with this change: > > > https://github.com/apache/incubator-openwhisk/pull/3199 > > > > > > Then, one question that Rabbah raised comes up. > > > Why do we have similar two IDs in headers? (x-request-id, > > > x-openwhisk-activation-id) > > > Couldn't it be possible to use just one ID for both the cases? > > > > > > Basic idea is just to use TransactionID(x-request-id) as a > ActivationID. > > > But there are still few concerns that Christian described here: > > > > > > > > > https://github.com/apache/incubator-openwhisk/pull/3671#issuecomment-392002543 > > > > > > And the main issue is the uniqueness of ActivationID. > > > If we allow using TransactionID as ActivationID, ActivationID could be > > > generated in two different places(Nginx, controller) as a controller > also > > > needs to generate activation id in case of triggers and sequence > actions > > > invocation. > > > > > > I want to kick off the discussion and listen to a good idea from many > > > whiskers. > > > > > > > > > Thanks > > > Regards > > > Dominic. > > > > > >
