Hide Forgot
In OpenStack Newton, TripleO has started to use Mistral as a workflow engine to aid deployments. This is then used by the CLI and new GUI. We need to cover the following topics: - How this impacts troubleshooting - Let users know at a high level what plans are and that they are stored in swift and can be easily retrieved. The best resource upstream is the initial spec this work is based on: https://specs.openstack.org/openstack/tripleo-specs/specs/mitaka/tripleo-mistral-deployment-library.html There is also some WIP documentation upstream: https://review.openstack.org/358685
<dmacpher> ping dmatthews <dmatthews> Hey <dmacpher> Hey Dougal... Just wanted to follow up on this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1374751 <dmatthews> Sure, I've not reported many docs bugs so sorry if I missed anything obvious. <dmacpher> It's all good, but just wanted to confirm my understanding of what Mistral actually is... <dmacpher> So if I understand correctly, it's basically a business logic component that can act as a kind of messaging layer so that the CLI and GUI aren't out of sync... Am I understanding that correctly, or am I off the path? <dmatthews> I quite like the definition on Wikipedia: https://en.wikipedia.org/wiki/Workflow_management_system <dmatthews> What you said is pretty much correct, except we actually use Zaqar for the messaging :) <dmatthews> You can really think of how we use Mistral as a replacement for a rest API <dmacpher> Ah, okay... Now I understand better... <dmacpher> So does it act like a frontend for combining multiple API calls into single tasks? <dmatthews> Yeah, exactly <dmatthews> This logic used to be all stored in the CLI, we moved it into Mistral workflows so that it could be called by different consumers <dmacpher> Okay, so if I wanted to see what one of these workflows looks like, how would I go about it... I've tried the openstack workflow/workbook show commands, but can't actually see more than just base information... <dmatthews> $ mistral workflow-get-definition tripleo.baremetal.v1.register_or_update <dmatthews> (Unfortunately the openstack version of that command is broken. https://bugs.launchpad.net/mistral/+bug/1626054 ) <dmacpher> Ah gotcha <dmacpher> Yep, I see it now <dmatthews> There are two areas of the Mistral docs that I find particulary useful <dmatthews> http://docs.openstack.org/developer/mistral/terminology/index.html <dmatthews> http://docs.openstack.org/developer/mistral/dsl/dsl_v2.html <dmatthews> The writing isn't great, but the content should be useful. <dmacpher> That's okay... I'm starting to understand it a bit more... I can see how you create an execution and what actually occurs now <dmatthews> Great
Link for debugging Mistral from dmatthews' blog: http://www.dougalmatthews.com/2016/Sep/21/debugging-mistral-in-tripleo/
Hi Dan, I think that looks great. Recently my debugging pattern has changed a bit, I almost always dive into the logs first - but that might just be due to my familiarity with the project. I wonder if it is worth explaining the different log files? Mistral has 3 - one for the Mistral REST API, one for the engine (mistral's core process, errors here are critical and something is wrong with Mistral) and one for the executor (which runs all the actions, errors here typically mean something is wrong with one of the custom actions). I have replied to the bug report too - thanks for raising that.
Have also updated the command example to use the mistral client instead of the osc client.