15:02:21 <rakhmerov> #startmeeting Mistral 15:02:21 <openstack> Meeting started Mon Nov 20 15:02:21 2017 UTC and is due to finish in 60 minutes. The chair is rakhmerov. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:25 <openstack> The meeting name has been set to 'mistral' 15:02:45 <d0ugal> Hey 15:02:55 <rakhmerov> d0ugal: hi :) 15:03:14 <rakhmerov> so, you and me :) 15:03:19 <rakhmerov> such a big crowd 15:03:23 <d0ugal> haha, indeed 15:03:25 <rakhmerov> :) 15:03:27 <d0ugal> Maybe some others will join 15:03:33 <rakhmerov> yep, let's wait 15:04:05 <rakhmerov> d0ugal: in the meantime, what's about that releasing issue? 15:04:08 <rakhmerov> pypi etc. 15:04:14 <rakhmerov> is it now solved? 15:04:22 <d0ugal> Good question. I'll check. 15:04:24 <rakhmerov> :) 15:04:31 <d0ugal> Yes, it is resolved 15:04:34 <d0ugal> 5.2.0 was released 15:04:35 <rakhmerov> but what's the latest update on that? 15:04:39 <rakhmerov> ooh, that's great 15:04:47 <d0ugal> and it is on PyPI 15:04:48 <rakhmerov> so we just keep publishing to pypi, right? 15:04:52 <d0ugal> Yeah 15:04:56 <rakhmerov> awesome, ok 15:04:59 <rakhmerov> solved ) 15:05:16 <d0ugal> Doug Hellmann explained it to me - there was a refactor that happened and it broke us 15:05:25 <rakhmerov> ooh, ok 15:05:31 <d0ugal> I think they caught most projects but missed ours, probably because we hadn't released for a while. 15:05:49 <rakhmerov> I see 15:06:14 <d0ugal> I think we need to try and release stable branches more often - there were about 30 commits that hadn't been released. 15:06:31 <rakhmerov> d0ugal: so now we've gone through our internal releasing hell and I'll be able to work on Mistral normally 15:06:38 <rakhmerov> but will go on vacation first 15:06:47 <d0ugal> :) 15:06:49 <rakhmerov> d0ugal: ok, I agree 15:06:51 <rakhmerov> btw 15:07:07 <rakhmerov> #action rakhmerov: make sure d0ugal is registered as the release liaison 15:07:10 <d0ugal> https://github.com/openstack/mistral/compare/5.1.0...5.2.0 15:07:14 <rakhmerov> yep 15:07:15 <d0ugal> ^ it was quite a large release. 15:07:30 <d0ugal> 2 months patches 15:07:34 <rakhmerov> yep 15:07:53 <rakhmerov> so, seems like no more people ) 15:08:09 <rakhmerov> bobh had a couple of topics actually, maybe he's already working on that 15:08:19 <bobh> o/ 15:08:30 <rakhmerov> ooh, hi Bob ) 15:08:47 <bobh> sorry - couldn't remember if the time changed or not 15:08:52 <rakhmerov> bobh: would you like to discuss anything? 15:09:02 <rakhmerov> no, the meeting time is still the same 15:09:08 <bobh> I'm working on the blueprint for the dynamic concurrency evaluation 15:09:20 <d0ugal> the time hasn't changed, but many of us have changed with DST. 15:09:38 <rakhmerov> bobh: yep, I looked at your email and it seemed pretty straightforward to me but maybe there are some pitfalls? 15:09:48 <bobh> will be interesting to see if the update to env() can be pushed to the task_ex? 15:10:05 <bobh> or does it have access to the wf_ex params that get updated 15:10:05 <bobh> ? 15:10:06 <rakhmerov> hah.. 15:10:23 <rakhmerov> well, let me think.. 15:10:34 <rakhmerov> I guess I didn't realize it in the first place.. 15:10:47 <rakhmerov> so, you want to change env() dynamically? 15:10:56 <rakhmerov> for a specific task? 15:10:59 <bobh> yes - using workflow-update to change the params 15:11:13 <bobh> I'd like to modify a value in env() that would control the concurrency 15:11:14 <rakhmerov> workflow-update? 15:11:18 <bobh> sorry 15:11:18 <rakhmerov> not sure I understand 15:11:20 <bobh> execution-update 15:11:30 <rakhmerov> yeah.. 15:11:40 <rakhmerov> but how are you going to use execution-update? 15:12:07 <rakhmerov> as far as I understand, we just have a task with 'with-items' that iterates over some items 15:12:12 <bobh> update the values passed to params which would include an env: dict which is referenced from the task 15:12:17 <bobh> right 15:12:25 <rakhmerov> yes, but 15:12:33 <bobh> concurrency is an expression like '{{ env().concurrency }}' 15:12:41 <rakhmerov> 'env' in params and params is a property of execution object 15:12:45 <rakhmerov> not a task execution 15:12:48 <bobh> right 15:12:52 <rakhmerov> I mean workflow execution 15:13:01 <rakhmerov> so it's a single object per all task executions 15:13:08 <rakhmerov> :) 15:13:14 <rakhmerov> so then what's the plan? :) 15:13:23 <bobh> so while I can access it to define the concurrency I wasn't sure the task would have access to the updated values at runtime 15:13:31 <bobh> dynamically 15:13:42 <bobh> I'll need to dig into it some more 15:13:53 <rakhmerov> aaah, I see 15:14:12 <bobh> essentially I'm looking for a way to dynamicaly "throttle" the concurrency 15:14:15 <rakhmerov> so you don't plan to have a separate copy of params for each task execution, right? 15:14:25 <rakhmerov> you just want to literally update the same object? 15:14:31 <bobh> yes 15:14:40 <rakhmerov> yep, ok 15:14:59 <bobh> hadn't though about the case where there could be multiple with-items executing at the same time :-) 15:15:04 <rakhmerov> it just seems like then we need to make sure to have atomic updates of this object 15:15:08 <rakhmerov> which may not be that easy 15:15:25 <rakhmerov> yes, it's possible 15:15:42 <bobh> they would all get the same env() updates as they would today 15:15:50 <rakhmerov> yes 15:16:11 <bobh> which suits my usecase - for now 15:16:11 <rakhmerov> but if one thread/process updates this dict we need to make sure to lock it somehow 15:16:23 <bobh> the update would only come from the API 15:16:24 <rakhmerov> so that other threads don't make parallel changes 15:16:37 <rakhmerov> yes 15:16:44 <bobh> the task itself can't modify the env - it's immutable (I tried :-) ) 15:16:57 <rakhmerov> ooh, wait a sec.. 15:17:04 <rakhmerov> I think I didn't understand again 15:17:19 <rakhmerov> so you use case as I understand it: you have 'with-items' task(s) 15:17:35 <rakhmerov> and at some point you just update the env through the API, right? 15:17:41 <bobh> yes 15:17:44 <rakhmerov> and your task just needs to see an updated value? 15:17:48 <bobh> yes 15:17:55 <rakhmerov> ooh, then I'm pretty sure it should be OK 15:17:59 <bobh> well -the with-items concurrency check 15:18:01 <rakhmerov> we just need to test it 15:18:04 <bobh> ok 15:18:27 <rakhmerov> :) 15:18:28 <bobh> I was afraid there was a copy of the execution context/params inthe task ex 15:18:29 <rakhmerov> ok 15:18:33 <rakhmerov> no-no 15:18:36 <rakhmerov> it's one ojbect 15:18:37 <bobh> whew 15:18:41 <rakhmerov> yes 15:18:51 <bobh> cool - so I'll mock it up and test it 15:18:52 <rakhmerov> anything else? ) 15:18:56 <rakhmerov> yes, please 15:19:01 <bobh> I'd like to get some reviews on https://review.openstack.org/#/c/514317/ 15:19:15 <bobh> not critical but would be nice to have 15:19:32 <rakhmerov> ok 15:19:41 <bobh> I'll do the limit update in the client to fix that problem 15:19:49 <rakhmerov> #action rakhmerov, d0ugal: review https://review.openstack.org/#/c/514317/ 15:19:57 <rakhmerov> bobh: ok, yes 15:20:01 <rakhmerov> thanks a lot 15:20:02 <bobh> and get the task PR finished that I was working on 15:20:09 <rakhmerov> yep 15:20:21 <bobh> Hopefully Mike has some ideas on how to do the sorting of the results 15:20:29 <bobh> Not sure how to do two sorts :-) 15:20:32 <rakhmerov> yes, he'll reply 15:20:44 <rakhmerov> I guess he's on a day off today or something 15:20:48 <bobh> cool - I think that's all I have 15:20:51 <rakhmerov> I couldn't reach out to him too yet 15:20:55 <rakhmerov> ok 15:20:57 <bobh> I'm off this week too 15:21:01 <rakhmerov> ok 15:21:08 <rakhmerov> d0ugal: do you have anything? 15:21:20 <rakhmerov> seems like nobody else is coming so I'd suggest we make it short 15:21:56 <rakhmerov> ok, let's end the meeting then 15:22:03 <bobh> thanks! 15:22:09 <rakhmerov> I'm available as usually, if needed 15:22:24 <rakhmerov> thanks! 15:22:27 <rakhmerov> #endmeeting