Open Stack

Hi Raanan,

In addition I would say that what you described after “Secondly” is one of the most important reasons why Mistral exists. This is probably its strongest side (not sure what else can fit so well).

Just in case, here are the screencasts that can highlight Mistral capabilities (although not all of them):
* http://www.youtube.com/watch?v=9kaac_AfNow <http://www.youtube.com/watch?v=9kaac_AfNow>
* http://www.youtube.com/watch?v=u6ki_DIpsg0 <http://www.youtube.com/watch?v=u6ki_DIpsg0>

Soon there’ll be more.

And full specification of current Mistral DSL: https://wiki.openstack.org/wiki/Mistral/DSLv2 <https://wiki.openstack.org/wiki/Mistral/DSLv2>

Would be nice to talk to you personally if you’re going to the summit or using any other channel and discuss the details )

Renat Akhmerov
@ Mirantis Inc.



> On 31 Oct 2014, at 02:22, Raanan Jossefi (RJ) Benikar <rbenikar at gmail.com> wrote:
> 
> 
>> 
>> Hi,
>> 
>> I see that Mistral can perform workflow automation and task execution per scheduling but wanted to confirm if workflows can be executed in real-time on-demand via REST API?   Can a REST API call into Mistral execute the workflow upon request, is what I am confirming, as it seems it is the case. Besides on-demand, is the purpose of Triggers currently being developed to automatically detect changes or notifications and execute in response to these triggers?  If so I would highly recommend triggers based on database change log, on file changes , on message arrival inside an AMQP queue, and on polling a REST API in which you expect a certain result, or status message.
>> 
>> Secondly, if one has a very tailored and mature cloud orchestration and operations process in place and wants to migrate to OpenStack and offer similar automation integrating with external change management systems, performing secondary LDAP searches, performing multiple SOR / DB queries, and thus interacting with other external non-cloud related technologies as part of the process of creating new tenants, adding users, creating new images, and creating and deploying machine instances would mistral be the best mechanism for this, in terms of driving automation, and invoking 3rd party APIs during and as part of the process?   
>> 
>> My current use case looks like this:
>> 
>> 1) Tenant requests VM with specific properties (image, etc etc) --> Service Now
>> 2) Service Now ---> API ( based on properties/inputs ) query a DB to automatically generate a server name )
>> 3) API ---> OpenStack API to provision new VM.
>> 
>> 
>> This is just an example, during this exchange, the API will interact with several external systems besides a DB, and do more than just autogenerate custom and unique machine names. In this case, the API could be Mistral that I am calling via REST.  I would create API wrappers to the other components ( which for the most part, I already have) and Mistral would now call both wrapper APIs and OpenStack APIs to provision a machine via Nova with all of the dependencies met.
>> 
>> Your advice is kindly appreciated,
>> Raanan 
>> 
>> 
>> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141031/1ef32877/attachment.html>