Re: Simplifying configuring OpenWhisk Components (#3984)

2018-08-23 Thread Chetan Mehrotra
I believe the uri feature is now under "fetch" [1] and makes use of Mesos Fetcher [2]. This should mostly work for our usecase with below caveats 1. Where to host - Most likely S3 with IAM based secure access 2. Corelate running service config with one in S3 - In k8s case if there is a change in C

Re: Simplifying configuring OpenWhisk Components (#3984)

2018-08-23 Thread Tyson Norris
Hi Chetan - As mentioned in the linked DCOS issue, using a marathon "uri" for config files (fetched before container is started) is an option - is there any reason that won't work for us? Files will end up in /mnt/mesos/sandbox in the container, not sure if that path matters (we can copy the fi

Re: Simplifying configuring OpenWhisk Components (#3984)

2018-08-23 Thread Chetan Mehrotra
> How will this impact other deployment tools, like Docker Compose? I'm aware that your change keeps the old path working, but do we envision to drop that at some point? Docker compose can also make use of config mount to make config file available. As to dropping support for current transformatio

Re: Simplifying configuring OpenWhisk Components (#3984)

2018-08-23 Thread Markus Thömmes
Hi Chetan, Am Do., 23. Aug. 2018 um 10:28 Uhr schrieb Chetan Mehrotra < chetan.mehro...@gmail.com>: > > Is it possible to layer configurations with this? For example: If I > create > a `database.conf` and a `controller.conf`, is there a way to mount these in > a way that they are both read and me

Re: Simplifying configuring OpenWhisk Components (#3984)

2018-08-23 Thread Chetan Mehrotra
> Is it possible to layer configurations with this? For example: If I create a `database.conf` and a `controller.conf`, is there a way to mount these in a way that they are both read and merged by the specific component? This should be possible as of now also. If file mount option is used [1] then

Re: Simplifying configuring OpenWhisk Components (#3984)

2018-08-23 Thread Markus Thömmes
Hi Chetan, good idea! A bit of background on why it is how it is: When I implemented the approach we're having today, the basic thought was to be able to detect on a quite granular level what changes are needed to which components, even when they share values. For example: In the Kubernetes case,