openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Allen <>
Subject Re: Signalling production-state of an action
Date Sat, 02 Sep 2017 18:41:26 GMT

In general, I'm in favour of the idea of setting properties rather than any sort of convention
as it's far more flexible.



> On 2 Sep 2017, at 19:19, Michael Marth <> wrote:
> Hi Carlos,
> Thanks for the feedback.
> “_” as a separator was just an example, could be anything else as well.
> But IIUC your comment
> “Like a boolean that the user wants a certain namespace to be treated as  "test/debug"”
> you hint at an idea I like better: letting users apply properties to namespaces. (not
just by naming convention, but by storing these properties in the DB).
> Did I get that right?
> On 01/09/17 19:43, "Carlos Santana" <> wrote:
>    We (IBM) in our in production environment today might have some hard
>    constraint to support this.
>    And we already took the liberty to use `_` in the namespace to mean
>    something else.
>    For example in our case the namespace is composed of user global account
>    information, in our case we leverage CloudFoundry system or Organization
>    and Space.
>    Where NameSpace = $Organization + "_" + $Space
>    So we already have in production users with namespaces with "_" in their
>    production namespaces.
>    If using the value of the namespace is an option then if namespace ends
>    with `_*test` but we need to check if we have users using a namespace like
>    this today I think that would be somewhat difficult.
>    In our case use would do something like `carlos_app1` and
>    `carlos_app1test`, we will tell folks to create a new space that ends with
>    `test`
>    Other options:
>    Something on the specific entity (like a action annotation).
>    We could add something to the subjects DB, and the controller can tag
>    something to the activation when sending to kafka for the invoker.
>    Like a boolean that the user wants a certain namespace to be treated as
>    "test/debug"
>    I was thinking a secondary OW API Key, but this brakes down for Web Actions
>    as they are public
>    No concrete feedback but worth the discussion, just wanted to give feedback
>    on the convention of using `_`
>    --Carlos Santana
>    On Thu, Aug 31, 2017 at 7:42 AM Michael Marth <>
>    wrote:
>> Hi,
>> in yesterday’s tech exchange Rodric mentioned that OW does not „know“ if
>> an action is in production or still in development stage.
>> The context of that comment was that we could consider to treat the
>> activation log collection separately (depending on the in-production-state).
>> In our OW deployment we have discussed a somewhat related topic:
>> How would our users move their actions from a development state to a
>> production state. Consider the user’s application to consider of a couple
>> of actions. Once the actions actually are deployed in production, then how
>> would the users edit and test new versions of these actions and deploy the
>> new versions into production.
>> (note: this is a separate topic from the production state and CI/CD
>> pipeline of the OW system itself)
>> The concept we came up with is based on a namespace convention:
>> If a user is provisioned with the namespace e.g. “mynamespace” then that
>> user can create additional arbitrary namespaces separated by an underscore,
>> e.g. mynamespace_dev, mynamespace_mytest123, etc. We would treat everything
>> with an underscore as non-production.
>> In case you wonder why we actually care: Knowing which actions are in
>> production and which ones are in development allows us to make decisions on
>> how the activation logs are collected and displayed, on alerting, on the
>> events/feeds we pipe into these actions etc.
>> I wanted to present our thoughts here to get feedback on:
>> Are there better approaches we could look into?
>> Is there an interest for a mechanism in OW itself to represent production
>> state (or simple adoption of the convention described above)?
>> Michael

Development thoughts at
Daily Jotter for macOS at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message