openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <tnor...@adobe.com.INVALID>
Subject Re: exporting activation arguments to the environment
Date Thu, 27 Jun 2019 00:21:21 GMT
For the incremental change I would suggest:
- include the action-configured params as args to init
- optionally: include an invoker flag to optionally remove action-configured params from being
sent to run (these would only be available by way of init setting env vars, or exposing some
other object)
- runtimes can be updated incrementally to support this flagged invoker behavior

I understand the point on amount of work, I'm just not wanting to sacrifice an awkward behavior
(different treatment for params in upper case) for sake of time. There are some accumulating
issues around init and run so I'm not sure it is worth making the problem worse before addressing
the other issues. I think its ok to change init to receive these params as a minimal change,
but obviously without additional changes either at invoker or in OW's convention for designing
functions (main sig, how to access init vars, context) there will be some incremental pain
as well. 

Still curious what others think.


´╗┐On 6/26/19, 11:27 AM, "Rodric Rabbah" <rodric@gmail.com> wrote:

    > Sorry, it still seems controversial to me, not sure how others feel?
    
    That's why we discuss on the dev list :D Thanks for the feedback so far.
    
    > can you confirm this is decided based on the case of the parameter name?
    
    Indeed, we need some rule to then partition the parameter list. Using the
    convention that the env var starts with a capital letter is one. Other
    conventions are plausible.
    
    > adding a '-e' flag that specifically does "set these environment
    variables"
    
    Sure - but this increases the complexity of implementation significantly
    for not a lot of gain. To add a -e, we'd need to modify the schema for
    actions. For example, we could add annotation for each parameter name to be
    treated as an environment variable using the existing annotations, and use
    these annotations as the criteria. We could create a new field in the
    actions object to hold the parameters (a schema change). We could annotate
    each parameter (also a schema change).
    
    Since a developer already controls the names of their parameters today,
    they have complete control over this partitioning.
    
    If we're open to schema changes, then we can explore a cleaner
    implementation but an incremental approach that at least makes the feature
    available incrementally would also make sense since making a schema change
    is a lot more invasive, coupled with a few changes needed at the invoker
    level plus all the runtimes.
    
    -r
    
    


Mime
View raw message