2019-12-02 07:17:10 UTC - Dominic Kim: Could you share the details?
2019-12-02 09:03:57 UTC - Roberto Diaz: I think that you are talking about 
conductor actions

If you are using python or JS you also have the possibility to use composer 
actions which is an abstraction over conductor actions

2019-12-02 10:26:29 UTC - giusdp: Hello, I modified the loadbalancer and used
```wskdev controller```
to build/deploy that component.
I then used the make quick-start with docker-compose tool to launch openwhisk, 
bu it's using the component exactly as it was before my change.
2019-12-02 10:27:19 UTC - giusdp: I also put some logging and went to check the 
tmp/openwhisk/controller/logs, to see if they were being printed, but they are 
not there. I'm not understanding what I should do to make it use my stuff
2019-12-02 10:54:41 UTC - Rodric Rabbah: Did you try: wskdev deploy 
2019-12-02 10:55:51 UTC - Rodric Rabbah: Instead make QuickStart which I think 
uses specifically tagged images. I will give it a try. Likely you need to tag 
the new images differently. 
2019-12-02 14:45:00 UTC - giusdp: How can I do that?
2019-12-02 14:47:22 UTC - Rodric Rabbah: `docker tag`
2019-12-02 14:54:37 UTC - giusdp: Thank you, I'll look into it
2019-12-02 16:19:40 UTC - Ali Tariq: @Dave Grove @chetanm, any insights about 
how do i get all the invokers in use?
2019-12-02 16:29:49 UTC - Dave Grove: the ingress type should not matter.   i 
would again drop the # of slots per invoker down to something quite a bit 
smaller and see if you can get the load to spread across multiple invokers.  
Try something tiny like 16 slots per invoker just to verify that the 
controller’s load balancer will actually spread your function across multiple 
2019-12-02 17:03:31 UTC - Ali Tariq: It did not help. I trimmed down to 16 
containers per invoker (4096m of `containerpool`) with 5 invoker replicas. Also 
reduced the workload to only 80 invocation requests but as you can see, the 
concurrency is being limited by the single invoker capacity! - looking at the 
pods & invoker-logs, only invoker-0 is being used to handle the requests!
2019-12-02 17:18:24 UTC - Dave Grove: should have asked this before.  What kind 
of action are you running?  This could be consistent with a “blackbox” (docker) 
action.  By default only 10% (or 1 if there are fewer than 10 invokers) of the 
invokers will be used to run blackbox actions.
2019-12-02 17:19:13 UTC - Dave Grove: controlled by 
2019-12-02 17:21:06 UTC - Ali Tariq: i have a simple python-runtime `--web 
true` action being invoked by http Api.
2019-12-02 17:23:59 UTC - Ali Tariq: ohh ... yes, i am using a custom 
docker-image with flag `--docker` to use libraries not supported by default.
2019-12-02 17:26:44 UTC - Dave Grove: ok.  that’s it then.   You can just 
change the value of whisk.loadbalancer.blackboxFraction in `values.yaml` and 
2019-12-02 17:27:16 UTC - Ali Tariq: Is there any reason why docker actions are 
treated differently? Also, should i just increase the value to 100% (is there 
any risk there?)?
2019-12-02 17:29:27 UTC - Dave Grove: there’s a school of thought that says one 
may want to segregate blackbox docker actions from managed actions because 
pulling the images can be slow and can evict the managed runtime images from 
the docker image cache on the worker node.
+1 : Ali Tariq
2019-12-02 17:30:50 UTC - Dave Grove: if you don’t care about that, the system 
will work just fine mixing blackbox and managed actions on the same invoker.  
just set the fractions to 100%
2019-12-02 17:38:23 UTC - Ali Tariq: Awesome! it's working as expected ... 
thank you for the help. I would like to add a `Scale-up` section in the 
kube-deploy documentation (<https://github.com/apache/openwhisk-deploy-kube>) 
... right after `verify you openwhisk deployment` section - to document simple 
scale-up &amp; possible issues one could encounter. Does that make sense? (if 
yes, i ll open a github issue!)
2019-12-02 17:38:48 UTC - Dave Grove: that would be great, thank you!

Reply via email to