*** jkilpatr has joined #openstack-mistral | 00:07 | |
*** gongysh has joined #openstack-mistral | 00:45 | |
*** gongysh has quit IRC | 00:49 | |
*** catintheroof has joined #openstack-mistral | 01:04 | |
*** rbrady has quit IRC | 01:08 | |
*** jamielennox is now known as jamielennox|away | 01:16 | |
*** thrash is now known as thrash|g0ne | 01:37 | |
*** catintheroof has quit IRC | 02:01 | |
*** rbrady has joined #openstack-mistral | 02:05 | |
*** openstackgerrit has joined #openstack-mistral | 02:28 | |
openstackgerrit | Lingxian Kong proposed openstack/mistral master: Fix update workflow by admin https://review.openstack.org/437212 | 02:28 |
---|---|---|
*** gongysh has joined #openstack-mistral | 03:04 | |
*** gongysh has quit IRC | 03:16 | |
*** dnalezyt has quit IRC | 04:23 | |
*** ist has quit IRC | 04:36 | |
*** sharatss has joined #openstack-mistral | 04:45 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/mistral master: Updated from global requirements https://review.openstack.org/440058 | 05:14 |
openstackgerrit | Sharat Sharma proposed openstack/mistral-dashboard master: Add test for mistral-dashboard action_executions https://review.openstack.org/438280 | 05:20 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/python-mistralclient master: Updated from global requirements https://review.openstack.org/440099 | 05:21 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/mistral master: Updated from global requirements https://review.openstack.org/440058 | 05:29 |
*** Kevin_Zheng has quit IRC | 05:33 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/python-mistralclient master: Updated from global requirements https://review.openstack.org/440099 | 05:36 |
*** zhurong has joined #openstack-mistral | 06:46 | |
*** zhurong has quit IRC | 06:53 | |
rakhmerov | d0ugal: yes, I think "current context" is quite accurate. The thing is that in one expression $ can mean different things. For example, task().result.where($ != 0) | 07:02 |
rakhmerov | here $ will be pointing an element of task().result collection, not the root context | 07:03 |
*** ist has joined #openstack-mistral | 07:08 | |
d0ugal | oh yeah, good point. | 07:23 |
* d0ugal slowly wakes up | 07:25 | |
*** gongysh has joined #openstack-mistral | 07:41 | |
d0ugal | rakhmerov: are you able to explain the "flat" parameter to the tasks function? | 07:48 |
d0ugal | I'm reading the spec, the draft docs and the code and I still don't understand :( | 07:49 |
openstackgerrit | Rico Lin proposed openstack/mistral master: Update test requirement https://review.openstack.org/440177 | 07:53 |
openstackgerrit | Rico Lin proposed openstack/python-mistralclient master: Update test requirement https://review.openstack.org/440178 | 07:56 |
openstackgerrit | Rico Lin proposed openstack/mistral-dashboard master: Update test requirement https://review.openstack.org/440181 | 07:58 |
openstackgerrit | Rico Lin proposed openstack/mistral-specs master: Update test requirement https://review.openstack.org/440182 | 08:00 |
openstackgerrit | Rico Lin proposed openstack/mistral-lib master: Update test requirement https://review.openstack.org/440184 | 08:03 |
*** shardy has joined #openstack-mistral | 08:04 | |
mgershen | d0ugal: I will make a workflow that shows what it comes to solve and maybe it will help. | 08:22 |
d0ugal | mgershen: thanks :) | 08:22 |
* d0ugal is probably being stupid | 08:23 | |
*** sharatss has quit IRC | 08:28 | |
mgershen | d0ugal: basically the main idea of this is to have a way to find the reason for the failure when the workflow execution failed fast. This feature work for us about 99% of the time. | 08:28 |
d0ugal | mgershen: I see, so if the execution has the state ERROR it will return the tasks that are also in ERROR state? | 08:31 |
d0ugal | hmm, no I don't think that is correct | 08:33 |
*** sharatss has joined #openstack-mistral | 08:33 | |
d0ugal | oh, I should read the unit tests | 08:33 |
mgershen | d0ugal: not really, I'm working on the examples | 08:34 |
d0ugal | okay, I'll wait - thanks :-) | 08:34 |
*** jpich has joined #openstack-mistral | 08:37 | |
rakhmerov | d0ugal: I'll look at it in a few.. | 08:48 |
openstackgerrit | Merged openstack/mistral-lib master: Updated from global requirements https://review.openstack.org/440060 | 08:50 |
rakhmerov | d0ugal, mgershen: can you pls review/approve patches from Rico? Seems like they should fix pbr 2.0.0 problem for us | 08:50 |
rakhmerov | after they land we'll need to rebase Michal's patch about removing 'output' | 08:50 |
rakhmerov | d0ugal, mgershen: so on that "flat" parameter. Yeah, I'm also a little confused now when I read it. I understand "task executions of type action" but don't really understand about nested workflows | 08:53 |
openstackgerrit | Jeremy Liu proposed openstack/mistral master: Add idempotent_id decorator to tempest testcases https://review.openstack.org/440221 | 08:54 |
d0ugal | rakhmerov: I think I already reviewed it :) | 08:54 |
*** jaosorior has joined #openstack-mistral | 08:56 | |
d0ugal | rakhmerov: am I only allowed to +2 on master? | 08:57 |
d0ugal | rakhmerov: I can't +2 this https://review.openstack.org/#/c/438544/ | 08:57 |
* d0ugal will brb | 08:58 | |
rakhmerov | d0ugal: oh, yes, it's a different group in gerrit that manages stable branches | 09:02 |
rakhmerov | I'm not even sure I can add you to that group | 09:02 |
rakhmerov | and maybe it's better to be more conservative on stable branch maintenance and keep less people there for now | 09:03 |
rakhmerov | (it doesn't mean though in any way that I don't trust you) | 09:03 |
*** shardy has quit IRC | 09:04 | |
*** shardy has joined #openstack-mistral | 09:04 | |
d0ugal | okay, fair enough | 09:15 |
d0ugal | in TripleO at least, we don't have the distinction | 09:15 |
d0ugal | so I didn't know that happened on other projects | 09:15 |
rakhmerov | discussable | 09:19 |
d0ugal | I don't often see many stable patches, so it is fine :) | 09:20 |
rakhmerov | if you think we should change it, np, let's discuss our policy around it at a weekly meeting | 09:20 |
rakhmerov | we can change it, no problem | 09:20 |
rakhmerov | yeah, that's what I thought too (about stable patches) | 09:20 |
d0ugal | rakhmerov: by the way, do we have the review policy stated somewhere for Mistral? | 09:21 |
d0ugal | rakhmerov: In TripleO, in the specs repo we have a special "policy" category that allows people to document review policies and other things related to project management. I was considering suggesting we do the same | 09:22 |
d0ugal | https://github.com/openstack/tripleo-specs/tree/master/specs/policy | 09:22 |
rakhmerov | d0ugal: ooh, that's good. Let's do it, I agree | 09:31 |
rakhmerov | may be with some changes though (still need to read more carefully what you have for TripleO) | 09:31 |
d0ugal | rakhmerov: Yeah, I just want to copy the idea - not the contents | 09:33 |
d0ugal | some of it is very specific to tripleo or because of the size of tripleo | 09:33 |
rakhmerov | d0ugal: can you send a patch with a skeleton? | 09:36 |
d0ugal | yup! | 09:36 |
openstackgerrit | Merged openstack/mistral master: Update test requirement https://review.openstack.org/440177 | 09:50 |
mgershen | sorry for taking so long | 09:50 |
mgershen | look here please : http://share.pho.to/Ad65s | 09:50 |
rakhmerov | d0ugal, mgershen: look at https://review.openstack.org/#/c/440178/, https://review.openstack.org/#/c/440184/, https://review.openstack.org/#/c/440182/, https://review.openstack.org/#/c/440181/ | 09:57 |
mgershen | wow, I can approve things! :-D | 09:59 |
mgershen | not sure I should have though, cover gate failed | 09:59 |
rakhmerov | :)) | 10:00 |
ddeja | mgershen: do not do it, make rakhmerov fix coverage :P | 10:01 |
rakhmerov | mgershen: use your power bravely but wisely :) | 10:01 |
rakhmerov | ddeja: why me? :) | 10:01 |
openstackgerrit | Jeremy Liu proposed openstack/mistral master: Add idempotent_id decorator to tempest testcases https://review.openstack.org/440221 | 10:02 |
mgershen | I checked if I can take back my +workflow | 10:02 |
mgershen | not sure. haha. | 10:02 |
rakhmerov | mgershen: np, if it's too late just send another patch to fix coverage | 10:02 |
ddeja | rakhmerov: I assumed that it was about your patch | 10:03 |
mgershen | I'm talking about this review: https://review.openstack.org/#/c/440178 | 10:03 |
rakhmerov | I think we need to make coverage gate voting | 10:03 |
ddeja | mgershen: ACK | 10:03 |
rakhmerov | aah.. | 10:03 |
mgershen | 2017-03-02 07:59:35.661528 | ERROR: unknown environment 'cover' | 10:04 |
rakhmerov | mgershen: ooh, Michal, I think coverage gate failure here is expected. | 10:04 |
rakhmerov | yes, the gate is just not 100% configured yet | 10:04 |
rakhmerov | sharatss should be able to share details I think | 10:05 |
mgershen | rakhmerov: interesting | 10:05 |
rakhmerov | mgershen: so you can approve it, this failure is not related to the patch | 10:05 |
mgershen | ok, I want to see what happens next. gate is running now. | 10:06 |
sharatss | rakhmerov, coverage is failing in mistralclient | 10:06 |
rakhmerov | yes, that's right | 10:07 |
sharatss | rakhmerov, mgershen, so that patch can go | 10:07 |
d0ugal | rakhmerov: it would be good to make it voting, but I am suspicious of the coverage gate :) | 10:07 |
rakhmerov | we're talking about mistralclient now | 10:07 |
d0ugal | rakhmerov: I think it fails even if you decrease coverage by 1 line - do we want to be that strict? | 10:07 |
rakhmerov | d0ugal: why? what do you mean? | 10:07 |
rakhmerov | hm... | 10:07 |
rakhmerov | d0ugal: so you mean we should rather just paying attention wisely to what's going on with this gate than having to increase coverage artificially for changes not related to the tests etc.? | 10:09 |
mgershen | I just don't understand how it works. for example here https://review.openstack.org/#/c/438913/ I have no idea why it passed in PS4 and failed in PS5 that only *added* a test | 10:09 |
d0ugal | rakhmerov: Yeah, I guess - or can we make it fail if the (rounded) percentage drops? | 10:14 |
d0ugal | i.e. 80% -> 79% is bad, but I don't want to block a change that adds 100 lines of code and one of them isn't tested | 10:15 |
d0ugal | Maybe I just need to read and understand the coverage gate logic - I don't know how strict it is | 10:15 |
d0ugal | mgershen: the inconsistent results also make me suspicious :) | 10:15 |
ddeja | d0ugal: as far as I remember the coverage gate fails if code coverage drops by more then 4 lines | 10:16 |
d0ugal | Also, how can coverage drop for a requirements.txt change lol | 10:16 |
d0ugal | https://review.openstack.org/#/c/440178/ | 10:16 |
d0ugal | ddeja: ^ not in that one :) | 10:16 |
rakhmerov | :) | 10:17 |
ddeja | d0ugal: yeah, I know, just a generic 'how to' ;) | 10:17 |
d0ugal | oh, maybe the coverage gate just failed in that case... | 10:17 |
rakhmerov | d0ugal: yes, what you said makes sense | 10:17 |
rakhmerov | we need to know better possible consequences | 10:17 |
d0ugal | I think we should monitor it over the next week or so and see when it fails and passes - then we can tweak it until it seems correct and then it should be voting | 10:18 |
openstackgerrit | Merged openstack/mistral-specs master: Update test requirement https://review.openstack.org/440182 | 10:21 |
rakhmerov | ok | 10:21 |
openstackgerrit | Merged openstack/mistral-lib master: Update test requirement https://review.openstack.org/440184 | 10:22 |
openstackgerrit | Merged openstack/mistral-dashboard master: Update test requirement https://review.openstack.org/440181 | 10:23 |
mgershen | d0ugal: did you see the like for the 'flat' example? http://share.pho.to/Ad65s | 10:24 |
d0ugal | mgershen: whoops, sorry, I opened it in a tab and got distracted. Looking now. | 10:24 |
openstackgerrit | Sharat Sharma proposed openstack/python-mistralclient master: Add script for unit test coverage job https://review.openstack.org/417902 | 10:25 |
*** gongysh has quit IRC | 10:27 | |
d0ugal | mgershen: so does it mean it will return the first error furthest down the branch? | 10:28 |
d0ugal | (which is likely the root cause) | 10:28 |
mgershen | usually | 10:30 |
d0ugal | I think I am starting to understand but I'm not sure how to document it :) | 10:32 |
mgershen | another example (without writing a workflow for it): http://pasteboard.co/Ex2KAcgNW.png | 10:36 |
d0ugal | oh! | 10:37 |
d0ugal | so it is when the status of a task is different than the status of the action/workflow it calls? | 10:37 |
mgershen | yes | 10:37 |
d0ugal | right | 10:38 |
d0ugal | mgershen: and in your first example task4 fails because the publish in invalid but the workflow was successful? | 10:39 |
mgershen | it is useful mostly when you are also passing workflow_execution_id and state ERROR | 10:39 |
d0ugal | yup | 10:39 |
mgershen | d0ugal: you got it | 10:40 |
openstackgerrit | Dougal Matthews proposed openstack/mistral master: Remove output from list action executions API https://review.openstack.org/433831 | 10:40 |
d0ugal | ^ rebased that to get the requirements change. | 10:40 |
openstackgerrit | Sharat Sharma proposed openstack/mistral master: Add hacking for code style checks https://review.openstack.org/435395 | 10:41 |
mgershen | we found using expression to publish things is not that easy and unexperienced users really struggle with. | 10:41 |
openstackgerrit | Merged openstack/python-mistralclient master: Update test requirement https://review.openstack.org/440178 | 10:42 |
*** tuan__ has joined #openstack-mistral | 10:46 | |
mgershen | in the future it will be nice to add the option to filter by error caused by engine too, even if the the state of the nested workflow is the same. Today it doesn't really matter because if a sub workflow execution is in error we will not publish anything for the task. | 10:47 |
d0ugal | mgershen, rakhmerov - I had a go at explaining it here. How does it read? https://review.openstack.org/#/c/433096/5/doc/source/dsl/dsl_v2.rst | 10:51 |
tuan__ | Hi guys, since the fix of Istvan for removing wf_def from wf_exec still has some concerns | 10:52 |
tuan__ | i would like to ask you guys about the purpose of using wf_def_spec in wf_exec | 10:53 |
tuan__ | from very beginning, what is the idea behind using it | 10:53 |
mgershen | d0ugal: perfect, I love it! | 10:54 |
tuan__ | and why we do not get this information from db but create it as an attribute in wf_exec | 10:54 |
mgershen | d0ugal: a significant improvement to the original wording. | 10:54 |
d0ugal | tuan__: I think the spec is copied to the wf_execution so that if a workflow is updated any existing executions wont change in the middle of their execution - that would cause problems. | 10:55 |
d0ugal | tuan__: but rakhmerov can give you a better answer than me :) I am too new to understand any historical reasons. | 10:55 |
d0ugal | mgershen: great. | 10:55 |
tuan__ | so the reason that we would like to have a sync between workflow and work_exec | 10:57 |
tuan__ | but IMHO it does not make sense | 10:58 |
openstackgerrit | Sharat Sharma proposed openstack/mistral-dashboard master: Add test for mistral-dashboard action_executions https://review.openstack.org/438280 | 10:59 |
*** shardy has quit IRC | 11:00 | |
*** shardy has joined #openstack-mistral | 11:01 | |
tuan__ | as i see that wf_def_spec just only used inside start process | 11:01 |
tuan__ | stop, rerun, resume do not use it | 11:01 |
tuan__ | another thing is we declare wf_id, wf_name in wf_execution besides wf_def_spec | 11:03 |
tuan__ | it seems like a redundancy because if you would like to store information of wf_def | 11:04 |
tuan__ | either wf_id/wf_name or wf_def_spec is enough | 11:04 |
rakhmerov | tuan__: 10 mins.. | 11:05 |
mgershen | if you want to return things to the user about the execution in just 1 query, you need to save them too. | 11:06 |
tuan__ | mgershen: yeap, and i think wf_id is enough | 11:06 |
mgershen | user would like the wf_name as well... | 11:07 |
tuan__ | a copy of wf_def is not neccessary for this purpose, IMHO | 11:07 |
mgershen | IMO | 11:07 |
rakhmerov | d0ugal, mgershen: this makes sense to me now | 11:07 |
rakhmerov | I mean that doc thing.. | 11:07 |
mgershen | rakhmerov: happy to hear! | 11:07 |
rakhmerov | so yeah, it's basically to see only errors caused by tasks themselves | 11:08 |
rakhmerov | not workflows associated with them | 11:08 |
mgershen | rakhmerov d0ugal: worked a lot on the example, happy it helped. | 11:08 |
rakhmerov | yes, it did | 11:08 |
d0ugal | 1 | 11:13 |
d0ugal | +1* | 11:13 |
rakhmerov | tuan__: Dougal's answer is absolutely correct. Plus this 'spec' keeps a canonical form of workflow definition which is different from the actual YAML, it's needed for a number of things | 11:14 |
rakhmerov | e.g. it allows to have json repr for individual elements so we can restore specs for individual objects w/o having to parse the entire huge (in some cases) yaml again | 11:15 |
rakhmerov | tuan__: why did you say that Istvan patch is under concern? | 11:16 |
rakhmerov | not sure I understand | 11:16 |
rakhmerov | tuan__: regarding id, name etc. they are not in the spec | 11:17 |
rakhmerov | spec has a name but it may be different from the name in wf def | 11:17 |
rakhmerov | spec may have "my_wf" but full name could be "my_wb.my_wf" | 11:18 |
tuan__ | rakhmerov: Hi Renat, | 11:25 |
rakhmerov | hi | 11:25 |
rakhmerov | just responded to Istvan's patch | 11:26 |
tuan__ | yeap, that patch is okay for short term | 11:26 |
tuan__ | as Michelle also commented that | 11:26 |
tuan__ | we should think about the versioned wf_definition | 11:26 |
tuan__ | because when we update the wf_def meanwhile its execution is running | 11:27 |
rakhmerov | already thinking.. | 11:27 |
rakhmerov | so? | 11:27 |
tuan__ | as an operator i would like to run a new execution for the new updated wf_def | 11:27 |
tuan__ | and the new execution does not break the old one | 11:28 |
rakhmerov | with this patch you'll be able to do it | 11:28 |
rakhmerov | it will not after this patch | 11:28 |
rakhmerov | so co-existence of workflow executions based on different workflow versions is now possible | 11:29 |
rakhmerov | the only thing we are missing is just navigation through versions of the same workflow | 11:29 |
rakhmerov | but that's a different topic | 11:29 |
rakhmerov | it's in the plan for the next cycle (Pike) | 11:30 |
tuan__ | and when we show the workflow_executions that are created from different versions of wf_definition | 11:31 |
*** thrash|g0ne is now known as thrash | 11:31 | |
rakhmerov | yes | 11:31 |
tuan__ | they have the same name and id of wf_definition | 11:31 |
tuan__ | ? | 11:31 |
rakhmerov | yes | 11:31 |
openstackgerrit | Dougal Matthews proposed openstack/mistral-specs master: Add a policy section to the Mistral specs https://review.openstack.org/440362 | 11:31 |
openstackgerrit | Dougal Matthews proposed openstack/mistral-specs master: Added the Epediated Approvals policy for reviews https://review.openstack.org/440363 | 11:32 |
tuan__ | but the actual content of two version wf_def is different | 11:32 |
rakhmerov | correct | 11:32 |
tuan__ | hmm, okay, so it is the current behavior | 11:32 |
tuan__ | thanks renat | 11:32 |
tuan__ | and others too :D | 11:32 |
rakhmerov | np :) | 11:32 |
rakhmerov | tuan__: so, question | 11:33 |
tuan__ | yeap | 11:33 |
rakhmerov | then why do you think we need to delete workflow_id from wf_ex? | 11:33 |
tuan__ | well, it is related to the behavior of wf-exec | 11:34 |
rakhmerov | ? | 11:34 |
tuan__ | since when i show the content of wf-exec after deleting the wf-def | 11:34 |
tuan__ | i saw the deleted wf-id | 11:34 |
tuan__ | and name too | 11:34 |
rakhmerov | aaah | 11:34 |
tuan__ | i also want to understand | 11:34 |
*** jkilpatr has quit IRC | 11:34 | |
tuan__ | it is what we want to have | 11:34 |
tuan__ | to show the user or not | 11:35 |
rakhmerov | well, but as long as it's not a FK constraint in DB that is fine, no? It's basically just for information | 11:35 |
tuan__ | yeap | 11:35 |
rakhmerov | I don't see anything bad with having this info in wf_ex honestly | 11:35 |
rakhmerov | furthermore, this info can help when investigating/debugging issues | 11:35 |
tuan__ | well, it depends on what we want and based o nthe purpose | 11:36 |
tuan__ | for instance, in neutron when delete the subnet | 11:36 |
tuan__ | you will not see it in network | 11:36 |
tuan__ | but in this case, i just wanna ask it | 11:36 |
tuan__ | not against on it | 11:37 |
rakhmerov | neutron's nets and subnets is a completely different story, I would not compare it with our situations | 11:37 |
tuan__ | since this behavior is also implemented in Nova | 11:37 |
tuan__ | yeah | 11:37 |
rakhmerov | like I said, it's not really a strong relationship, it's rather informational | 11:37 |
rakhmerov | ok | 11:37 |
tuan__ | yeap | 11:37 |
tuan__ | clear | 11:37 |
tuan__ | :D | 11:37 |
rakhmerov | I think we're on the same page here | 11:37 |
tuan__ | thanks again | 11:37 |
rakhmerov | ok, I'll approve the patch | 11:37 |
tuan__ | yeah :) | 11:37 |
openstackgerrit | Sharat Sharma proposed openstack/mistral master: Add hacking for code style checks https://review.openstack.org/435395 | 11:40 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/mistral master: Updated from global requirements https://review.openstack.org/440058 | 11:46 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/mistral-dashboard master: Updated from global requirements https://review.openstack.org/440059 | 11:46 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/mistral-lib master: Updated from global requirements https://review.openstack.org/440383 | 11:46 |
tuan__ | rakhmerov: Otherwise, could you put your comment about my patch of the pagination of db | 11:47 |
tuan__ | the topic we have talked about before PTG | 11:47 |
rakhmerov | tuan__: you mean expiration policy working with batches? | 11:48 |
tuan__ | yeap | 11:48 |
*** jkilpatr has joined #openstack-mistral | 11:51 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/python-mistralclient master: Updated from global requirements https://review.openstack.org/440099 | 11:54 |
rakhmerov | tuan__: yes, I'll look at it | 11:57 |
*** jkilpatr has quit IRC | 11:58 | |
*** jkilpatr has joined #openstack-mistral | 12:12 | |
*** shardy is now known as shardy_lunch | 12:21 | |
openstackgerrit | Merged openstack/mistral master: Correction in workflow state change handling https://review.openstack.org/438913 | 12:25 |
*** catintheroof has joined #openstack-mistral | 12:56 | |
*** shardy_lunch is now known as shardy | 12:58 | |
*** sharatss has quit IRC | 13:16 | |
*** sharatss has joined #openstack-mistral | 13:16 | |
*** sharat has joined #openstack-mistral | 13:20 | |
*** sharatss has quit IRC | 13:20 | |
*** dprince has joined #openstack-mistral | 13:26 | |
*** sharat has quit IRC | 13:28 | |
d0ugal | rakhmerov: Hey, you got a moment? | 13:38 |
*** chlong_ has joined #openstack-mistral | 13:40 | |
*** rook has joined #openstack-mistral | 13:42 | |
rook | hey! so, doing some deployments with OOO and I see mistral always hitting about 50% of a CPU - is that normal? | 13:43 |
rook | There is zero deployments going on (one just wrapped up). but nothing is using mistral at the moment, but mistral-engine is doing _something_ | 13:43 |
d0ugal | rook: I've heard of similar reports, but never seen it myself. | 13:47 |
d0ugal | rook: Have you checked there are no Mistral executions running? mistral execution-list | 13:47 |
rook | I just kicked another deployment :) scaling things up | 13:48 |
rook | i can after it. | 13:48 |
d0ugal | rook: okay, thanks | 13:49 |
d0ugal | rook: it would also be useful to check mistral logs and see if anything is happening there | 13:50 |
*** breton has quit IRC | 14:07 | |
*** Kevin_Zheng_ has joined #openstack-mistral | 14:25 | |
*** breton has joined #openstack-mistral | 14:32 | |
*** tuan__ has quit IRC | 15:30 | |
openstackgerrit | Dougal Matthews proposed openstack/mistral master: Reduce the number of with-items and retried in the concurrency test https://review.openstack.org/440633 | 15:32 |
d0ugal | thrash: ^ more seconds | 15:33 |
d0ugal | or, less seconds really! | 15:33 |
thrash | d0ugal: fewer. :) | 15:34 |
d0ugal | um, that too | 15:34 |
thrash | d0ugal: sorry... Mom was an English teacher. :P | 15:34 |
*** tuan_ has joined #openstack-mistral | 15:35 | |
d0ugal | thrash: oh, then you should help out with the docs patches! | 15:35 |
thrash | d0ugal: Haha... Didn't mean that I am *that* good at it. | 15:35 |
thrash | d0ugal: I'm good with the rules. Not necessarily with the creation. | 15:36 |
thrash | If that makes any sense at all... | 15:36 |
d0ugal | thrash: yup | 15:36 |
d0ugal | thrash: we were discussing this for a while earlier. https://review.openstack.org/#/c/433096/ | 15:36 |
*** ist has quit IRC | 15:40 | |
*** rakhmerov has quit IRC | 15:43 | |
*** akuznetsova has quit IRC | 15:44 | |
*** akuznetsova has joined #openstack-mistral | 15:47 | |
*** rakhmerov has joined #openstack-mistral | 15:49 | |
openstackgerrit | Dougal Matthews proposed openstack/mistral master: Verify the retry policy when passed in via variables https://review.openstack.org/440646 | 15:51 |
openstackgerrit | Dougal Matthews proposed openstack/mistral master: Verify the retry policy when passed in via variables https://review.openstack.org/440646 | 15:53 |
*** chlong_ has quit IRC | 16:01 | |
*** chlong__ has joined #openstack-mistral | 16:01 | |
*** rook is now known as rook-afk | 16:04 | |
*** tuan_ has quit IRC | 16:22 | |
*** tuan__ has joined #openstack-mistral | 16:25 | |
openstackgerrit | Michal Gershenzon proposed openstack/mistral master: Update docs for tasks function https://review.openstack.org/433096 | 16:30 |
openstackgerrit | Michal Gershenzon proposed openstack/mistral master: Update docs for tasks function https://review.openstack.org/433096 | 16:32 |
openstackgerrit | Dougal Matthews proposed openstack/mistral master: Reduce the number of with-items and retried in the concurrency test https://review.openstack.org/440633 | 16:40 |
openstackgerrit | Dougal Matthews proposed openstack/mistral master: Verify the retry policy when passed in via variables https://review.openstack.org/440646 | 16:40 |
openstackgerrit | Dougal Matthews proposed openstack/mistral master: Remove the delay from the direct workflow rerun tests https://review.openstack.org/440625 | 16:40 |
mgershen | d0ugal rakhmerov: I made a blog post from the example I made about using tasks function (in PTG it was suggested we blog more). https://mgershen.blogspot.fr/2017/03/why-did-my-nested-mistral-workflow.html | 16:48 |
d0ugal | mgershen: great, I'll take a look | 16:49 |
d0ugal | mgershen: you should make sure your blog is included on http://planet.openstack.org/ | 16:49 |
mgershen | d0ugal: you think so? even though it's just one post, and it's not that good/finished | 16:50 |
mgershen | ? | 16:50 |
d0ugal | mgershen: well, maybe add yourself when it is finished :) I assume/hope you plan to write more! | 16:51 |
d0ugal | mgershen: My blog is included there and it gets me most of my traffic for openstack posts. | 16:51 |
mgershen | d0ugal: cool | 16:52 |
d0ugal | http://www.dougalmatthews.com/ | 16:52 |
d0ugal | I try and write about mistral now and then :) | 16:52 |
mgershen | d0ugal: your blog is great. | 16:55 |
d0ugal | mgershen: thanks, still lots of work to do to make it better :) | 16:55 |
mgershen | d0ugal: and you have your own domain | 16:58 |
d0ugal | yeah, I got that a long time ago. | 16:59 |
mgershen | it looks great. I'm going to bookmark it and read when I will have time :) | 17:01 |
d0ugal | mgershen: cool, let me know if you have any feedback | 17:01 |
mgershen | sure :) | 17:01 |
*** mgershen is now known as _mgershen | 17:06 | |
*** jpich has quit IRC | 17:21 | |
*** Kevin_Zheng_ has quit IRC | 17:43 | |
*** rook-afk is now known as rook | 17:50 | |
*** thrash is now known as thrash|biab | 17:54 | |
*** jaosorior has quit IRC | 18:19 | |
*** shardy has quit IRC | 18:21 | |
rook | huh d0ugal interesting | 18:23 |
rook | i suppose the Mistral actions that are "running" are actually doing something | 18:23 |
rook | 1e25df14-075a-4ecf- | c213df50-4f81-4abc- | tripleo.baremetal.v | sub-workflow | 3675d70c-40bb-4d23- | RUNNING | None | 2017-02-24 22:43:13 | 2017-02-24 22:43:14 | | 18:23 |
rook | for example | 18:23 |
rook | however, nothing is happening on the host as we speak | 18:24 |
d0ugal | rook: maybe something got stuck? | 18:30 |
rook | d0ugal: I think I explained a bit more in #tripleo | 18:31 |
rook | d0ugal: say a user ctrl+c's a deployment | 18:31 |
rook | does mistral clean those old workflows? | 18:31 |
d0ugal | rook: yup, it should do | 18:31 |
d0ugal | rook: it looks like the workflow name is truncated - can you see the full name? | 18:32 |
d0ugal | tripleo.baremetal.v1.... | 18:32 |
d0ugal | rook: you might have to open a bug and/or get help from thrash|biab - its th end of my day now | 18:32 |
d0ugal | Mistral logs would be worth checking | 18:32 |
d0ugal | and mistral action-execution-list is useful | 18:33 |
d0ugal | if you can get that together and thrash|biab doesn't look first I can try tomorrow | 18:33 |
d0ugal | rook: ^ | 18:33 |
rook | https://gist.github.com/jtaleric/72b8e69e779d188b1434a4b26f5d96ee d0ugal | 18:33 |
*** tuan__ has quit IRC | 18:37 | |
*** tuan_ has joined #openstack-mistral | 18:42 | |
*** thrash|biab is now known as thrash | 19:11 | |
thrash | rook: that's all that's in action-execution-list? | 19:13 |
rook | thrash: ohh, no | 19:13 |
rook | thrash: i have tons of output if you want it all | 19:14 |
thrash | it would be helpful to see everything from at least the start of the deployment. | 19:14 |
rook | This is multiple deployments | 19:14 |
rook | well | 19:14 |
rook | scale deplopyments. | 19:14 |
thrash | from the one that's stuck. | 19:15 |
rook | this is just one large deployment, however i Ctrl+c'ed a deployment or two | 19:20 |
thrash | Yeah... Ctrl-C really doesn't do any cleanup. | 19:22 |
thrash | The client is just waiting for a zaqar message from mistral that it's finished. | 19:23 |
*** jkilpatr has quit IRC | 19:35 | |
*** jkilpatr has joined #openstack-mistral | 19:35 | |
*** tuan_ has quit IRC | 19:43 | |
rook | ah thrash so, if a user ctrl+c the tripleo deploy in the middle there is no clean up? | 19:48 |
thrash | No. The client is decoupled from the actual deployment. | 19:48 |
*** jamielennox|away is now known as jamielennox | 20:02 | |
rook | thrash should running things eventually timeout | 20:21 |
rook | thrash: https://gist.github.com/jtaleric/89219c6115accfdfc8b8c0f51feddacb | 20:22 |
d0ugal | thrash, rook - there is no cleanup, but workflows should eventually finish - just the messages wont be read. | 20:34 |
d0ugal | anyway, it looks like the set note state workflow got stuck for some reason | 20:35 |
thrash | d0ugal: rook lots of errors in that set_node_state | 20:36 |
rook | thrash: yup, i saw that too | 20:37 |
rook | thrash this is going to be quite a large TripleO deployment | 20:37 |
thrash | rook: how many nodes were you scaling up to? | 20:37 |
rook | going to start about 107 nodes, and go to ~1000 | 20:37 |
rook | baremetal nodes | 20:37 |
rook | Ceph have been a absolute pain in my ass | 20:37 |
thrash | rook: what's the output from 'action-execution-get' on one of the set_node_state that is in ERROR? | 20:38 |
thrash | but as d0ugal said, eventually, it will time out. | 20:39 |
thrash | as will the heat stack update. | 20:39 |
rook | well this is after mutliple successful stack updates | 20:40 |
*** jkilpatr has quit IRC | 20:45 | |
*** jkilpatr has joined #openstack-mistral | 20:45 | |
*** dprince has quit IRC | 21:06 | |
*** jkilpatr has quit IRC | 21:34 | |
*** rbrady is now known as rbrady-afk | 21:47 | |
*** jkilpatr has joined #openstack-mistral | 21:53 | |
*** catintheroof has quit IRC | 22:40 | |
*** jamielennox is now known as jamielennox|away | 23:37 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!