Thursday, 2017-03-02

*** jkilpatr has joined #openstack-mistral00:07
*** gongysh has joined #openstack-mistral00:45
*** gongysh has quit IRC00:49
*** catintheroof has joined #openstack-mistral01:04
*** rbrady has quit IRC01:08
*** jamielennox is now known as jamielennox|away01:16
*** thrash is now known as thrash|g0ne01:37
*** catintheroof has quit IRC02:01
*** rbrady has joined #openstack-mistral02:05
*** openstackgerrit has joined #openstack-mistral02:28
openstackgerritLingxian Kong proposed openstack/mistral master: Fix update workflow by admin  https://review.openstack.org/43721202:28
*** gongysh has joined #openstack-mistral03:04
*** gongysh has quit IRC03:16
*** dnalezyt has quit IRC04:23
*** ist has quit IRC04:36
*** sharatss has joined #openstack-mistral04:45
openstackgerritOpenStack Proposal Bot proposed openstack/mistral master: Updated from global requirements  https://review.openstack.org/44005805:14
openstackgerritSharat Sharma proposed openstack/mistral-dashboard master: Add test for mistral-dashboard action_executions  https://review.openstack.org/43828005:20
openstackgerritOpenStack Proposal Bot proposed openstack/python-mistralclient master: Updated from global requirements  https://review.openstack.org/44009905:21
openstackgerritOpenStack Proposal Bot proposed openstack/mistral master: Updated from global requirements  https://review.openstack.org/44005805:29
*** Kevin_Zheng has quit IRC05:33
openstackgerritOpenStack Proposal Bot proposed openstack/python-mistralclient master: Updated from global requirements  https://review.openstack.org/44009905:36
*** zhurong has joined #openstack-mistral06:46
*** zhurong has quit IRC06:53
rakhmerovd0ugal: 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
rakhmerovhere $ will be pointing an element of task().result collection, not the root context07:03
*** ist has joined #openstack-mistral07:08
d0ugaloh yeah, good point.07:23
* d0ugal slowly wakes up07:25
*** gongysh has joined #openstack-mistral07:41
d0ugalrakhmerov: are you able to explain the "flat" parameter to the tasks function?07:48
d0ugalI'm reading the spec, the draft docs and the code and I still don't understand :(07:49
openstackgerritRico Lin proposed openstack/mistral master: Update test requirement  https://review.openstack.org/44017707:53
openstackgerritRico Lin proposed openstack/python-mistralclient master: Update test requirement  https://review.openstack.org/44017807:56
openstackgerritRico Lin proposed openstack/mistral-dashboard master: Update test requirement  https://review.openstack.org/44018107:58
openstackgerritRico Lin proposed openstack/mistral-specs master: Update test requirement  https://review.openstack.org/44018208:00
openstackgerritRico Lin proposed openstack/mistral-lib master: Update test requirement  https://review.openstack.org/44018408:03
*** shardy has joined #openstack-mistral08:04
mgershend0ugal: I will make a workflow that shows what it comes to solve and maybe it will help.08:22
d0ugalmgershen: thanks :)08:22
* d0ugal is probably being stupid08:23
*** sharatss has quit IRC08: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
d0ugalmgershen: I see, so if the execution has the state ERROR it will return the tasks that are also in ERROR state?08:31
d0ugalhmm, no I don't think that is correct08:33
*** sharatss has joined #openstack-mistral08:33
d0ugaloh, I should read the unit tests08:33
mgershend0ugal: not really, I'm working on the examples08:34
d0ugalokay, I'll wait - thanks :-)08:34
*** jpich has joined #openstack-mistral08:37
rakhmerovd0ugal: I'll look at it in a few..08:48
openstackgerritMerged openstack/mistral-lib master: Updated from global requirements  https://review.openstack.org/44006008:50
rakhmerovd0ugal, mgershen: can you pls review/approve patches from Rico? Seems like they should fix pbr 2.0.0 problem for us08:50
rakhmerovafter they land we'll need to rebase Michal's patch about removing 'output'08:50
rakhmerovd0ugal, 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 workflows08:53
openstackgerritJeremy Liu proposed openstack/mistral master: Add idempotent_id decorator to tempest testcases  https://review.openstack.org/44022108:54
d0ugalrakhmerov: I think I already reviewed it :)08:54
*** jaosorior has joined #openstack-mistral08:56
d0ugalrakhmerov: am I only allowed to +2 on master?08:57
d0ugalrakhmerov: I can't +2 this https://review.openstack.org/#/c/438544/08:57
* d0ugal will brb08:58
rakhmerovd0ugal: oh, yes, it's a different group in gerrit that manages stable branches09:02
rakhmerovI'm not even sure I can add you to that group09:02
rakhmerovand maybe it's better to be more conservative on stable branch maintenance and keep less people there for now09:03
rakhmerov(it doesn't mean though in any way that I don't trust you)09:03
*** shardy has quit IRC09:04
*** shardy has joined #openstack-mistral09:04
d0ugalokay, fair enough09:15
d0ugalin TripleO at least, we don't have the distinction09:15
d0ugalso I didn't know that happened on other projects09:15
rakhmerovdiscussable09:19
d0ugalI don't often see many stable patches, so it is fine :)09:20
rakhmerovif you think we should change it, np, let's discuss our policy around it at a weekly meeting09:20
rakhmerovwe can change it, no problem09:20
rakhmerovyeah, that's what I thought too (about stable patches)09:20
d0ugalrakhmerov: by the way, do we have the review policy stated somewhere for Mistral?09:21
d0ugalrakhmerov: 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 same09:22
d0ugalhttps://github.com/openstack/tripleo-specs/tree/master/specs/policy09:22
rakhmerovd0ugal: ooh, that's good. Let's do it, I agree09:31
rakhmerovmay be with some changes though (still need to read more carefully what you have for TripleO)09:31
d0ugalrakhmerov: Yeah, I just want to copy the idea - not the contents09:33
d0ugalsome of it is very specific to tripleo or because of the size of tripleo09:33
rakhmerovd0ugal: can you send a patch with a skeleton?09:36
d0ugalyup!09:36
openstackgerritMerged openstack/mistral master: Update test requirement  https://review.openstack.org/44017709:50
mgershensorry for taking so long09:50
mgershenlook here please : http://share.pho.to/Ad65s09:50
rakhmerovd0ugal, 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
mgershenwow, I can approve things! :-D09:59
mgershennot sure I should have though, cover gate failed09:59
rakhmerov:))10:00
ddejamgershen: do not do it, make rakhmerov fix coverage :P10:01
rakhmerovmgershen: use your power bravely but wisely :)10:01
rakhmerovddeja: why me? :)10:01
openstackgerritJeremy Liu proposed openstack/mistral master: Add idempotent_id decorator to tempest testcases  https://review.openstack.org/44022110:02
mgershenI checked if I can take back my +workflow10:02
mgershennot sure. haha.10:02
rakhmerovmgershen: np, if it's too late just send another patch to fix coverage10:02
ddejarakhmerov: I assumed that it was about your patch10:03
mgershenI'm talking about this review: https://review.openstack.org/#/c/44017810:03
rakhmerovI think we need to make coverage gate voting10:03
ddejamgershen: ACK10:03
rakhmerovaah..10:03
mgershen2017-03-02 07:59:35.661528 | ERROR: unknown environment 'cover'10:04
rakhmerovmgershen: ooh, Michal, I think coverage gate failure here is expected.10:04
rakhmerovyes, the gate is just not 100% configured yet10:04
rakhmerovsharatss should be able to share details I think10:05
mgershenrakhmerov: interesting10:05
rakhmerovmgershen: so you can approve it, this failure is not related to the patch10:05
mgershenok, I want to see what happens next. gate is running now.10:06
sharatssrakhmerov, coverage is failing in mistralclient10:06
rakhmerovyes, that's right10:07
sharatssrakhmerov, mgershen, so that patch can go10:07
d0ugalrakhmerov: it would be good to make it voting, but I am suspicious of the coverage gate :)10:07
rakhmerovwe're talking about mistralclient now10:07
d0ugalrakhmerov: I think it fails even if you decrease coverage by 1 line - do we want to be that strict?10:07
rakhmerovd0ugal: why? what do you mean?10:07
rakhmerovhm...10:07
rakhmerovd0ugal: 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
mgershenI 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 test10:09
d0ugalrakhmerov: Yeah, I guess - or can we make it fail if the (rounded) percentage drops?10:14
d0ugali.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 tested10:15
d0ugalMaybe I just need to read and understand the coverage gate logic - I don't know how strict it is10:15
d0ugalmgershen: the inconsistent results also make me suspicious :)10:15
ddejad0ugal: as far as I remember the coverage gate fails if code coverage drops by more then 4 lines10:16
d0ugalAlso, how can coverage drop for a requirements.txt change lol10:16
d0ugalhttps://review.openstack.org/#/c/440178/10:16
d0ugalddeja: ^ not in that one :)10:16
rakhmerov:)10:17
ddejad0ugal: yeah, I know, just a generic 'how to' ;)10:17
d0ugaloh, maybe the coverage gate just failed in that case...10:17
rakhmerovd0ugal: yes, what you said makes sense10:17
rakhmerovwe need to know better possible consequences10:17
d0ugalI 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 voting10:18
openstackgerritMerged openstack/mistral-specs master: Update test requirement  https://review.openstack.org/44018210:21
rakhmerovok10:21
openstackgerritMerged openstack/mistral-lib master: Update test requirement  https://review.openstack.org/44018410:22
openstackgerritMerged openstack/mistral-dashboard master: Update test requirement  https://review.openstack.org/44018110:23
mgershend0ugal: did you see the like for the 'flat' example? http://share.pho.to/Ad65s10:24
d0ugalmgershen: whoops, sorry, I opened it in a tab and got distracted. Looking now.10:24
openstackgerritSharat Sharma proposed openstack/python-mistralclient master: Add script for unit test coverage job  https://review.openstack.org/41790210:25
*** gongysh has quit IRC10:27
d0ugalmgershen: 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
mgershenusually10:30
d0ugalI think I am starting to understand but I'm not sure how to document it :)10:32
mgershenanother example (without writing a workflow for it): http://pasteboard.co/Ex2KAcgNW.png10:36
d0ugaloh!10:37
d0ugalso it is when the status of a task is different than the status of the action/workflow it calls?10:37
mgershenyes10:37
d0ugalright10:38
d0ugalmgershen: and in your first example task4 fails because the publish in invalid but the workflow was successful?10:39
mgershenit is useful mostly when you are also passing workflow_execution_id and state ERROR10:39
d0ugalyup10:39
mgershend0ugal: you got it10:40
openstackgerritDougal Matthews proposed openstack/mistral master: Remove output from list action executions API  https://review.openstack.org/43383110:40
d0ugal^ rebased that to get the requirements change.10:40
openstackgerritSharat Sharma proposed openstack/mistral master: Add hacking for code style checks  https://review.openstack.org/43539510:41
mgershenwe found using expression to publish things is not that easy and unexperienced users really struggle with.10:41
openstackgerritMerged openstack/python-mistralclient master: Update test requirement  https://review.openstack.org/44017810:42
*** tuan__ has joined #openstack-mistral10:46
mgershenin 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
d0ugalmgershen, 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.rst10:51
tuan__Hi guys, since the fix of Istvan for removing wf_def from wf_exec still has some concerns10:52
tuan__i would like to ask you guys about the purpose of using wf_def_spec in wf_exec10:53
tuan__from very beginning, what is the idea behind using it10:53
mgershend0ugal: 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_exec10:54
mgershend0ugal: a significant improvement to the original wording.10:54
d0ugaltuan__: 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
d0ugaltuan__: but rakhmerov can give you a better answer than me :) I am too new to understand any historical reasons.10:55
d0ugalmgershen: great.10:55
tuan__so the reason that we would like to have a sync between workflow and work_exec10:57
tuan__but IMHO it does not make sense10:58
openstackgerritSharat Sharma proposed openstack/mistral-dashboard master: Add test for mistral-dashboard action_executions  https://review.openstack.org/43828010:59
*** shardy has quit IRC11:00
*** shardy has joined #openstack-mistral11:01
tuan__as i see that wf_def_spec just only used inside start process11:01
tuan__stop, rerun, resume do not use it11:01
tuan__another thing is we declare wf_id, wf_name in wf_execution besides wf_def_spec11:03
tuan__it seems like a redundancy because if you would like to store information of wf_def11:04
tuan__either wf_id/wf_name or wf_def_spec is enough11:04
rakhmerovtuan__: 10 mins..11:05
mgershenif 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 enough11:06
mgershenuser would like the wf_name as well...11:07
tuan__a copy of wf_def is not neccessary for this purpose, IMHO11:07
mgershenIMO11:07
rakhmerovd0ugal, mgershen: this makes sense to me now11:07
rakhmerovI mean that doc thing..11:07
mgershenrakhmerov: happy to hear!11:07
rakhmerovso yeah, it's basically to see only errors caused by tasks themselves11:08
rakhmerovnot workflows associated with them11:08
mgershenrakhmerov d0ugal: worked a lot on the example, happy it helped.11:08
rakhmerovyes, it did11:08
d0ugal111:13
d0ugal+1*11:13
rakhmerovtuan__: 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 things11:14
rakhmerove.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 again11:15
rakhmerovtuan__: why did you say that Istvan patch is under concern?11:16
rakhmerovnot sure I understand11:16
rakhmerovtuan__: regarding id, name etc. they are not in the spec11:17
rakhmerovspec has a name but it may be different from the name in wf def11:17
rakhmerovspec may have "my_wf" but full name could be "my_wb.my_wf"11:18
tuan__rakhmerov: Hi Renat,11:25
rakhmerovhi11:25
rakhmerovjust responded to Istvan's patch11:26
tuan__yeap, that patch is okay for short term11:26
tuan__as Michelle also commented that11:26
tuan__we should think about the versioned wf_definition11:26
tuan__because when we update the wf_def meanwhile its execution is running11:27
rakhmerovalready thinking..11:27
rakhmerovso?11:27
tuan__as an operator i would like to run a new execution for the new updated wf_def11:27
tuan__and the new execution does not break the old one11:28
rakhmerovwith this patch you'll be able to do it11:28
rakhmerovit will not after this patch11:28
rakhmerovso co-existence of workflow executions based on different workflow versions is now possible11:29
rakhmerovthe only thing we are missing is just navigation through versions of the same workflow11:29
rakhmerovbut that's a different topic11:29
rakhmerovit'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_definition11:31
*** thrash|g0ne is now known as thrash11:31
rakhmerovyes11:31
tuan__they have the same name and id of wf_definition11:31
tuan__?11:31
rakhmerovyes11:31
openstackgerritDougal Matthews proposed openstack/mistral-specs master: Add a policy section to the Mistral specs  https://review.openstack.org/44036211:31
openstackgerritDougal Matthews proposed openstack/mistral-specs master: Added the Epediated Approvals policy for reviews  https://review.openstack.org/44036311:32
tuan__but the actual content of two version wf_def is different11:32
rakhmerovcorrect11:32
tuan__hmm, okay, so it is the current behavior11:32
tuan__thanks renat11:32
tuan__and others too :D11:32
rakhmerovnp :)11:32
rakhmerovtuan__: so, question11:33
tuan__yeap11:33
rakhmerovthen 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-exec11:34
rakhmerov?11:34
tuan__since when i show the content of wf-exec after deleting the wf-def11:34
tuan__i saw the deleted wf-id11:34
tuan__and name too11:34
rakhmerovaaah11:34
tuan__i also want to understand11:34
*** jkilpatr has quit IRC11:34
tuan__it is what we want to have11:34
tuan__to show the user or not11:35
rakhmerovwell, but as long as it's not a FK constraint in DB that is fine, no? It's basically just for information11:35
tuan__yeap11:35
rakhmerovI don't see anything bad with having this info in wf_ex honestly11:35
rakhmerovfurthermore, this info can help when investigating/debugging issues11:35
tuan__well, it depends on what we want and based o nthe purpose11:36
tuan__for instance, in neutron when delete the subnet11:36
tuan__you will not see it in network11:36
tuan__but in this case, i just wanna ask it11:36
tuan__not against on it11:37
rakhmerovneutron's nets and subnets is a completely different story, I would not compare it with our situations11:37
tuan__since this behavior is also implemented in Nova11:37
tuan__yeah11:37
rakhmerovlike I said, it's not really a strong relationship, it's rather informational11:37
rakhmerovok11:37
tuan__yeap11:37
tuan__clear11:37
tuan__:D11:37
rakhmerovI think we're on the same page here11:37
tuan__thanks again11:37
rakhmerovok, I'll approve the patch11:37
tuan__yeah :)11:37
openstackgerritSharat Sharma proposed openstack/mistral master: Add hacking for code style checks  https://review.openstack.org/43539511:40
openstackgerritOpenStack Proposal Bot proposed openstack/mistral master: Updated from global requirements  https://review.openstack.org/44005811:46
openstackgerritOpenStack Proposal Bot proposed openstack/mistral-dashboard master: Updated from global requirements  https://review.openstack.org/44005911:46
openstackgerritOpenStack Proposal Bot proposed openstack/mistral-lib master: Updated from global requirements  https://review.openstack.org/44038311:46
tuan__rakhmerov: Otherwise, could you put your comment about my patch of the pagination of db11:47
tuan__the topic we have talked about before PTG11:47
rakhmerovtuan__: you mean expiration policy working with batches?11:48
tuan__yeap11:48
*** jkilpatr has joined #openstack-mistral11:51
openstackgerritOpenStack Proposal Bot proposed openstack/python-mistralclient master: Updated from global requirements  https://review.openstack.org/44009911:54
rakhmerovtuan__: yes, I'll look at it11:57
*** jkilpatr has quit IRC11:58
*** jkilpatr has joined #openstack-mistral12:12
*** shardy is now known as shardy_lunch12:21
openstackgerritMerged openstack/mistral master: Correction in workflow state change handling  https://review.openstack.org/43891312:25
*** catintheroof has joined #openstack-mistral12:56
*** shardy_lunch is now known as shardy12:58
*** sharatss has quit IRC13:16
*** sharatss has joined #openstack-mistral13:16
*** sharat has joined #openstack-mistral13:20
*** sharatss has quit IRC13:20
*** dprince has joined #openstack-mistral13:26
*** sharat has quit IRC13:28
d0ugalrakhmerov: Hey, you got a moment?13:38
*** chlong_ has joined #openstack-mistral13:40
*** rook has joined #openstack-mistral13:42
rookhey! so, doing some deployments with OOO and I see mistral always hitting about 50% of a CPU - is that normal?13:43
rookThere 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
d0ugalrook: I've heard of similar reports, but never seen it myself.13:47
d0ugalrook: Have you checked there are no Mistral executions running? mistral execution-list13:47
rookI just kicked another deployment :) scaling things up13:48
rooki can after it.13:48
d0ugalrook: okay, thanks13:49
d0ugalrook: it would also be useful to check mistral logs and see if anything is happening there13:50
*** breton has quit IRC14:07
*** Kevin_Zheng_ has joined #openstack-mistral14:25
*** breton has joined #openstack-mistral14:32
*** tuan__ has quit IRC15:30
openstackgerritDougal Matthews proposed openstack/mistral master: Reduce the number of with-items and retried in the concurrency test  https://review.openstack.org/44063315:32
d0ugalthrash: ^ more seconds15:33
d0ugalor, less seconds really!15:33
thrashd0ugal: fewer. :)15:34
d0ugalum, that too15:34
thrashd0ugal: sorry... Mom was an English teacher. :P15:34
*** tuan_ has joined #openstack-mistral15:35
d0ugalthrash: oh, then you should help out with the docs patches!15:35
thrashd0ugal: Haha... Didn't mean that I am *that* good at it.15:35
thrashd0ugal: I'm good with the rules. Not necessarily with the creation.15:36
thrashIf that makes any sense at all...15:36
d0ugalthrash: yup15:36
d0ugalthrash: we were discussing this for a while earlier. https://review.openstack.org/#/c/433096/15:36
*** ist has quit IRC15:40
*** rakhmerov has quit IRC15:43
*** akuznetsova has quit IRC15:44
*** akuznetsova has joined #openstack-mistral15:47
*** rakhmerov has joined #openstack-mistral15:49
openstackgerritDougal Matthews proposed openstack/mistral master: Verify the retry policy when passed in via variables  https://review.openstack.org/44064615:51
openstackgerritDougal Matthews proposed openstack/mistral master: Verify the retry policy when passed in via variables  https://review.openstack.org/44064615:53
*** chlong_ has quit IRC16:01
*** chlong__ has joined #openstack-mistral16:01
*** rook is now known as rook-afk16:04
*** tuan_ has quit IRC16:22
*** tuan__ has joined #openstack-mistral16:25
openstackgerritMichal Gershenzon proposed openstack/mistral master: Update docs for tasks function  https://review.openstack.org/43309616:30
openstackgerritMichal Gershenzon proposed openstack/mistral master: Update docs for tasks function  https://review.openstack.org/43309616:32
openstackgerritDougal Matthews proposed openstack/mistral master: Reduce the number of with-items and retried in the concurrency test  https://review.openstack.org/44063316:40
openstackgerritDougal Matthews proposed openstack/mistral master: Verify the retry policy when passed in via variables  https://review.openstack.org/44064616:40
openstackgerritDougal Matthews proposed openstack/mistral master: Remove the delay from the direct workflow rerun tests  https://review.openstack.org/44062516:40
mgershend0ugal 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.html16:48
d0ugalmgershen: great, I'll take a look16:49
d0ugalmgershen: you should make sure your blog is included on http://planet.openstack.org/16:49
mgershend0ugal: you think so? even though it's just one post, and it's not that good/finished16:50
mgershen?16:50
d0ugalmgershen: well, maybe add yourself when it is finished :) I assume/hope you plan to write more!16:51
d0ugalmgershen: My blog is included there and it gets me most of my traffic for openstack posts.16:51
mgershend0ugal: cool16:52
d0ugalhttp://www.dougalmatthews.com/16:52
d0ugalI try and write about mistral now and then :)16:52
mgershend0ugal: your blog is great.16:55
d0ugalmgershen: thanks, still lots of work to do to make it better :)16:55
mgershend0ugal: and you have your own domain16:58
d0ugalyeah, I got that a long time ago.16:59
mgershenit looks great. I'm going to bookmark it and read when I will have time :)17:01
d0ugalmgershen: cool, let me know if you have any feedback17:01
mgershensure :)17:01
*** mgershen is now known as _mgershen17:06
*** jpich has quit IRC17:21
*** Kevin_Zheng_ has quit IRC17:43
*** rook-afk is now known as rook17:50
*** thrash is now known as thrash|biab17:54
*** jaosorior has quit IRC18:19
*** shardy has quit IRC18:21
rookhuh d0ugal interesting18:23
rooki suppose the Mistral actions that are "running" are actually doing something18:23
rook1e25df14-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
rookfor example18:23
rookhowever, nothing is happening on the host as we speak18:24
d0ugalrook: maybe something got stuck?18:30
rookd0ugal: I think I explained a bit more in #tripleo18:31
rookd0ugal: say a user ctrl+c's a deployment18:31
rookdoes mistral clean those old workflows?18:31
d0ugalrook: yup, it should do18:31
d0ugalrook: it looks like the workflow name is truncated - can you see the full name?18:32
d0ugaltripleo.baremetal.v1....18:32
d0ugalrook: you might have to open a bug and/or get help from thrash|biab - its th end of my day now18:32
d0ugalMistral logs would be worth checking18:32
d0ugaland mistral action-execution-list is useful18:33
d0ugalif you can get that together and thrash|biab doesn't look first I can try tomorrow18:33
d0ugalrook: ^18:33
rookhttps://gist.github.com/jtaleric/72b8e69e779d188b1434a4b26f5d96ee d0ugal18:33
*** tuan__ has quit IRC18:37
*** tuan_ has joined #openstack-mistral18:42
*** thrash|biab is now known as thrash19:11
thrashrook: that's all that's in action-execution-list?19:13
rookthrash: ohh, no19:13
rookthrash: i have tons of output if you want it all19:14
thrashit would be helpful to see everything from at least the start of the deployment.19:14
rookThis is multiple deployments19:14
rookwell19:14
rookscale deplopyments.19:14
thrashfrom the one that's stuck.19:15
rookthis is just one large deployment, however i Ctrl+c'ed a deployment or two19:20
thrashYeah... Ctrl-C really doesn't do any cleanup.19:22
thrashThe client is just waiting for a zaqar message from mistral that it's finished.19:23
*** jkilpatr has quit IRC19:35
*** jkilpatr has joined #openstack-mistral19:35
*** tuan_ has quit IRC19:43
rookah thrash so, if a user ctrl+c the tripleo deploy in the middle there is no clean up?19:48
thrashNo. The client is decoupled from the actual deployment.19:48
*** jamielennox|away is now known as jamielennox20:02
rookthrash should running things eventually timeout20:21
rookthrash: https://gist.github.com/jtaleric/89219c6115accfdfc8b8c0f51feddacb20:22
d0ugalthrash, rook - there is no cleanup, but workflows should eventually finish - just the messages wont be read.20:34
d0ugalanyway, it looks like the set note state workflow got stuck for some reason20:35
thrashd0ugal: rook lots of errors in that set_node_state20:36
rookthrash: yup, i saw that too20:37
rookthrash this is going to be quite a large TripleO deployment20:37
thrashrook: how many nodes were you scaling up to?20:37
rookgoing to start about 107 nodes, and go to ~100020:37
rookbaremetal nodes20:37
rookCeph have been a absolute pain in my ass20:37
thrashrook: what's the output from 'action-execution-get' on one of the set_node_state that is in ERROR?20:38
thrashbut as d0ugal said, eventually, it will time out.20:39
thrashas will the heat stack update.20:39
rookwell this is after mutliple successful stack updates20:40
*** jkilpatr has quit IRC20:45
*** jkilpatr has joined #openstack-mistral20:45
*** dprince has quit IRC21:06
*** jkilpatr has quit IRC21:34
*** rbrady is now known as rbrady-afk21:47
*** jkilpatr has joined #openstack-mistral21:53
*** catintheroof has quit IRC22:40
*** jamielennox is now known as jamielennox|away23:37

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