Friday, 2017-03-10

*** catintheroof has quit IRC00:29
*** catintheroof has joined #openstack-mistral00:30
*** catintheroof has quit IRC00:30
*** rbrady has quit IRC00:30
*** jamielennox is now known as jamielennox|away00:36
*** jamielennox|away is now known as jamielennox00:37
*** catintheroof has joined #openstack-mistral00:42
*** zhurong has joined #openstack-mistral00:56
*** gongysh has joined #openstack-mistral02:16
*** catintheroof has quit IRC03:57
*** catintheroof has joined #openstack-mistral03:58
*** catintheroof has quit IRC03:59
openstackgerritMerged openstack/mistral-specs master: Force the docs to be built with Python 2  https://review.openstack.org/44346805:24
openstackgerritMerged openstack/mistral-specs master: Add AUTHORS to the .gitignore  https://review.openstack.org/44346705:24
*** jaosorior has joined #openstack-mistral06:09
*** shardy has joined #openstack-mistral07:58
*** jaosorior is now known as jaosorior_breakf08:33
*** fultonj has joined #openstack-mistral08:41
*** jaosorior_breakf is now known as jaosorior08:48
*** fultonj has quit IRC08:49
*** amoralej|off is now known as amoralej08:51
*** jpich has joined #openstack-mistral08:54
*** zhurong has quit IRC10:10
*** gongysh has quit IRC10:26
rakhmerovd0ugal: hi, did you see my comment in https://review.openstack.org/#/c/443477/ ?10:29
d0ugalrakhmerov: oh, cool - I hadn't seen yours10:29
*** openstackgerrit has quit IRC10:33
rakhmerovnp :)10:33
*** openstackgerrit has joined #openstack-mistral10:33
openstackgerritMerged openstack/mistral-specs master: Add Pike specs into index  https://review.openstack.org/44108910:33
rakhmerovddeja, d0ugal, breton: I've just read your conversation. 1) Like breton said it's pretty easy to DOS any non- real-time system if there's such a goal in mind 2) Is it really a strict requirement to have seconds precision? Based on #1 I have serious doubts that available existing billing systems support seconds precision10:37
rakhmerov3) Such a system can use Mistral exclusively (w/o any concurrent activities)10:37
rakhmerovif #3 is possible then precision will be close to seconds10:38
d0ugalthanks!10:40
rakhmerovjust my humble opinion )10:53
* rakhmerov is hoping that core reviewers will look at his patches soon ;)10:54
ddejarakhmerov: I can take my time todays evening and have fun reviewing patches ;)11:13
rakhmerovok, thanks!11:14
rakhmerovkong: here?11:27
openstackgerritMerged openstack/mistral master: Deleting the expired execution with batch size  https://review.openstack.org/42462111:31
*** gongysh has joined #openstack-mistral11:41
d0ugalrakhmerov: hey, is there a way to have on-error called for each item in with-items?11:45
rakhmerovd0ugal: no, on- clauses work based on task result which can be a collection of action results11:46
d0ugalright11:46
rakhmerovso it's a task level, not action level11:46
shardyhttp://paste.openstack.org/show/602238/11:47
rakhmerovcurrently there's nothing available11:47
shardyhey rakhmerov, d0ugal - the use case is I want to fail if an object is missing in swift11:47
shardyand it'd be super-helpful to tell the user which one :)11:47
rakhmerovlet me see11:47
rakhmerovhi shardy11:47
shardyhey rakhmerov, and thanks for the help! :)11:48
rakhmerovnp :)11:48
d0ugalIt would be nice if the task result was {"succeeded": [output, output, ...], "failed": [...]}11:49
rakhmerovso11:49
d0ugalI'm not sure what the task output looks like now actually11:49
rakhmerovI'm not sure 100% if it's going to work in case if the whole task fails but essentially a task always has a result accessible as <% task(task_name).result %> which in case of "with-items" returns a collection of corresponding action results11:51
rakhmerovso you can run YAQL/Jinja against this collection and select only those that failed11:51
d0ugalshardy: ^11:51
rakhmerovthat's how I would do it11:51
shardyrakhmerov: Ok, I can probably work around it with yaql, I was just wondering if there was a cleaner way11:51
shardythanks :)11:51
d0ugalit does sound like something we could improve11:52
rakhmerovanother option: if you need to react immediately upon an action failure you can create a small subworkflow calling swift action11:52
d0ugalyeah, I almost suggested that approach11:52
rakhmerovfrom a task, and this task's on-error will have a handler11:52
rakhmerovyep11:53
shardyAny examples of that?  I'm not quite clear how that would work11:53
rakhmerovd0ugal: however, I'm not really sure if task().result will return a task result correctly in case of task failure, we need to see if this is even covered. If it doesn't work that's a bug11:53
rakhmerovshardy: you mean the second option?11:54
d0ugalshardy: example incoming, but I think it is messier :)11:54
rakhmerovok )11:54
shardyrakhmerov: yes the subworkflow suggestion isn't clear to me atm11:55
d0ugalshardy: http://paste.openstack.org/show/602243/11:55
rakhmerovook, d0ugal you said you're coming up with an example, right?11:55
rakhmerovok )11:55
d0ugalrakhmerov: do you mean this?11:55
d0ugalhttp://paste.openstack.org/show/602243/11:55
rakhmerovyep, exactly11:55
d0ugalshardy: The advantage is that the on-errir is called when the head_object fails - otherwise on-error is called at the end of all the with-items11:56
shardyd0ugal: aha!11:56
shardyI get it now, thanks! :)11:56
rakhmerovso basically we just converted actions into tasks so that we can apply individual handlers11:56
shardythat will do what I want I think11:56
d0ugalbut you have the complexity of having two workflows :) the sub-workflow could do a zaqar.queue_post11:56
shardyd0ugal: if I do it that way, will the with-items stop when check_swift fails, or keep going so we have to handle potentially multiple error messages from zaqar?11:57
shardythe docs suggest with-items iterates all items regardless of failure?11:57
d0ugalshardy: yeah, it will keep going11:58
rakhmerovthe only thing that's missing in the example is workflow actual parameters, should be "workflow: check_swift container=... path=..."11:58
rakhmerovd0ugal, shardy: I need to clarify this11:58
d0ugalrakhmerov: oh yeah11:58
d0ugalshardy: I would probably go with the YAQL approach.11:59
shardya stop_on_error option would be cool11:59
d0ugal+111:59
shardythen you just grab the last task output from the list11:59
rakhmerovwith-tems itself will fail upon the first failure but 1) keep in mind that with-items actions can be running in parallel 2) we can design a subworkflow in a way that it doesn't fail even if swift action fails so that the enclosing with-items continues normally12:00
shardyrakhmerov: can the run in parallel even without specifying concurrency?12:00
rakhmerovby default is all parallel12:00
rakhmerovas far as I remember12:00
rakhmerovlet me check...12:01
shardyI was thinking the stop on error thing would only work for the non-concurrent case (or, at least the list lookup would only work in that case)12:01
shardyI thought I had to specify concurrency: $n12:01
bretonrakhmerov: meh, i just dropped seconds precision12:02
rakhmerovshardy: yes, by default it schedules them all immediately12:02
rakhmerovif you want to limit parallelism you need to define concurrency explicitly12:03
rakhmerovbreton: ok :)12:03
rakhmerovneed to step away..12:03
shardyrakhmerov: ack, thanks for clarifying12:04
d0ugalrakhmerov: is there a default overall concurrency? i.e. number of actions/workflows running at the same time.12:09
d0ugalrakhmerov: all I can see is an rpc thread pool of 10012:09
d0ugaloh and an executor_thread_pool_size12:09
d0ugalI guess that is it :)12:10
rakhmerovd0ugal: yes, I think this is the only thing limiting a number of simultaneous actions12:15
rakhmerovbut engine by default schedules them all at once12:15
rakhmerovif "concurrency" is not set12:16
d0ugalrakhmerov: yup, makes sense12:16
rakhmerovbtw, not sure what our doc says about it )12:16
d0ugalrakhmerov: we have a couple of with-items in tripleo that I realise could be quite large - so I am wondering how many will actually run at the same time :)12:16
d0ugaland it sounds like it might be 10012:17
rakhmerovwell, yeah, "at the same time" is tricky thing actually12:17
d0ugalheh12:17
rakhmerov"close to the same time" I guess )12:17
d0ugaltrue12:17
rakhmerovd0ugal: yeah, our doc doesn't tell anything about default concurrency12:17
rakhmerovhttps://bugs.launchpad.net/mistral/+bug/167180312:19
openstackLaunchpad bug 1671803 in Mistral "with-items default concurrency is not explained in docs" [Medium,Confirmed]12:19
*** jkilpatr has joined #openstack-mistral12:21
openstackgerritSteven Hardy proposed openstack/mistral master: Add head_object action mapping for swift  https://review.openstack.org/44426112:21
*** shardy is now known as shardy_lunch12:26
*** catintheroof has joined #openstack-mistral12:34
*** rbrady has joined #openstack-mistral13:09
*** rbrady has quit IRC13:09
*** rbrady has joined #openstack-mistral13:09
*** gongysh has quit IRC13:32
*** shardy_lunch is now known as shardy13:33
shardyd0ugal: hey can you see where I'm going wrong here? http://paste.openstack.org/show/602266/14:17
d0ugallooking14:17
shardywherever I publish the task output I seem to get nothing14:17
shardyI'm probably doing something stupid but I can't see what :)14:18
d0ugalshardy: I'll try running it and see14:19
shardyd0ugal: ack, thanks - I locally applied the head_object patch, do I need to do anything more than sudo mistral-db-manage populate and restart the services?14:19
d0ugalno, that should do it14:20
shardyit seems to be working as I got an error due to a typo in the action arguments14:20
d0ugaloh, interesting.14:20
shardy(fixed in the version in the paste)14:20
*** amoralej is now known as amoralej|lunch14:21
*** rbrady has quit IRC14:23
d0ugalshardy: the result of the workflow is the result of the final tasks14:27
d0ugalshardy: so in your case that is always task_fail14:27
shardyd0ugal: aha, so I have to publish there, and not in the task which fails?14:28
d0ugalYeah, if you want that to be the workflow result14:28
d0ugalthe output is still there tho' - you can get it with "mistral task-list" and "mistral task-get-result ID"14:28
shardyd0ugal: ah, I see - I misunderstood and thought the execution-output showed the final context with all the published things14:29
shardylet me try, thanks for the help!14:29
d0ugalshardy: and you can see the individual action calls with mistral action-execution-list - which is quite handy, I can see one passes and fails :)14:29
shardywoohoo, that's what I was aiming for :)14:29
shardyd0ugal: Ok I see the task output, which is what I want to access in the workflow, but I'm still doing something wrong:14:34
shardyhttp://paste.openstack.org/show/602268/14:34
shardyhttps://docs.openstack.org/developer/mistral/main_features.html#processing-collections-with-items14:35
shardythat says  the task result (accessible in workflow context as <% $.task_name %>) will be a list14:35
shardybut it appears in the failure path, swift_verify_output: <% $.verify_environment_path_exists %>) fails14:35
* shardy tries not using publish14:36
d0ugalshardy: sorry, in a call - will be with you shortly14:37
shardyd0ugal: no worries14:37
*** rbrady has joined #openstack-mistral14:39
*** rbrady has quit IRC14:39
*** rbrady has joined #openstack-mistral14:39
shardyd0ugal: nvm, I think I've got it now14:50
shardythanks for the help14:50
d0ugalshardy: cool :)14:50
d0ugalnp14:50
openstackgerritMerged openstack/mistral master: Add head_object action mapping for swift  https://review.openstack.org/44426114:58
*** catintheroof has quit IRC15:00
*** catintheroof has joined #openstack-mistral15:01
*** thrash is now known as thrash|vet15:12
*** chlong_ has joined #openstack-mistral15:15
*** shardy has quit IRC15:17
*** jaosorior has quit IRC15:24
*** toure|gone is now known as toue15:25
*** toue is now known as toure15:25
*** amoralej|lunch is now known as amoralej15:39
*** chlong_ has quit IRC16:19
*** thrash|vet is now known as thrash16:28
*** jaosorior has joined #openstack-mistral16:34
*** jaosorior has quit IRC16:42
*** catintheroof has quit IRC17:07
*** catintheroof has joined #openstack-mistral17:08
*** jpich has quit IRC17:16
*** vishwanathj has quit IRC17:37
*** vishwanathj has joined #openstack-mistral17:37
*** jkilpatr has quit IRC18:03
*** jkilpatr has joined #openstack-mistral18:06
*** jkilpatr has quit IRC19:33
*** jkilpatr has joined #openstack-mistral19:36
*** chlong_ has joined #openstack-mistral19:42
*** jkilpatr has quit IRC19:44
*** rbrady is now known as rbrady-afk19:48
*** jkilpatr has joined #openstack-mistral19:58
*** vishwanathj has quit IRC20:25
*** vishwanathj has joined #openstack-mistral20:26
*** amoralej is now known as amoralej|off20:44
*** jtomasek has quit IRC21:30
*** vishwanathj has quit IRC21:49
*** vishwanathj has joined #openstack-mistral21:50
*** chlong_ has quit IRC22:21
*** catintheroof has quit IRC22:23
*** Kevin_Zheng has quit IRC22:53
*** jkilpatr has quit IRC23:34

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!