| Summary: | [docs] [director] Document the inclusion of Mistral for deployment | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Dougal Matthews <dmatthew> |
| Component: | documentation | Assignee: | Dan Macpherson <dmacpher> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Don Domingo <ddomingo> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 10.0 (Newton) | CC: | dmacpher, dmatthew, lbopf, mburns, srevivo |
| Target Milestone: | --- | Keywords: | Documentation |
| Target Release: | 10.0 (Newton) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-01-17 16:19:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Dougal Matthews
2016-09-09 14:05:32 UTC
<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. |