<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Thank you Dimitri and Renat for your kind and swift replies.  This was very helpful at the least, it will certainly drive or reinforce an option I am likely to promote and consider taking for driving integration both inside and outside of OpenStack. <br><br></div><div>I won't unfortunately be going to the OpenStack Summit this year but please feel free to reach me via skype, my skype ID is rbenikar , and my gtalk/gmail ID is rbenikar as well.  I am based in the East Coast, in RTP, NC, USA. <br></div><div><br></div>I believe in my new project, I have begun working with a former US-based Mirantis employee, his name Koffi Nogbe.  Small world.  <br><br></div>Let me ask you as well, lets say I implement OpenStack out of the box, without extending any of its own code and thus provide access to the OpenStack API unchanged, can Mistral be interjected in such a way that during any API request, it can play a role in executing logic outside of OpenStack, and then update the data or input going into the request that OpenStack now achieves the specific custom Use Case required?   This would also be quite powerful. Imagine a Provider telling a customer, "We use OpenStack and we simply allow you customer to call its API directly. We have not modified it, we have not extended it, we have simply banded together, hooked in a mechanism to evaluate and then perform additional work to complete your use case".    <br><br></div>Example Use Cases:<br></div>1) Auto-generate machine names based on simple OS, environment, and business or tenant-based details with ability to override this naming convention by allowing the customer to specify their own VM ( in the event they are migrating existing machines), and allowing CRUD DB operations as to check, keep track, and record machine names allocated.<br></div>2) Execute approval workflows as well as generate automatic service tickets and audit trails in systems used by customer outside of the confines of OpenStack.<br></div>3) Integrate with customer ESB, to drive other automation requirements outside confines of OpenStack. For example, register the machine name, its IPAM determined IP, the primary contact of the app, the system owner, the type of machine env [prod, dev, qa, pre-prod, d/r, ] , etc inside a SOR and then synchronize that detail with enterprise security products which now know what type of compliance and technical vulnerability checking will be executed against and on this machine.<br></div>4 Perform via REST API, after machine is created, various REST interactions to tell reporting and monitoring systems to begin agent-based and agent-less monitoring of the machine, to begin scanning the machine via network, to begin performing remote logon OS baseline analysis, to begin performing ETLs of data residing in other databases into database instances running in the cloud ( e.g. for Clinical Research, pull data from live systems, cleanse of Patient Information, leaving only Clinical data, and place inside a DB in a VM, and finally register BI tools and SAS/SPSS, and other analytical platforms to begin using the local DB source, and then load their data sets with this tool so the analyst can begin shortly after provisioning without doing any work asking for the data, and getting proper security clearances, etc.  Convert 6-8 week task into under 30 minutes )<br><br></div><div>I also wonder too, if Mistral could be extended to offer a 2nd type of feature, an API proxy to OpenStack?  In this case, if this feature was added, all requests to OpenStack could be proxied via Mistral, the REST Operations would remained unaltered or changed.  However, one could then enable workflow logic where it is required for any given operation.  Example, a user submits a machine creation request.  During this, a WF invokes an external BPM suite to perform an external approval workflow, the API proxy 's WF waits until the approval is complete, and then proceeds to create the VM.  One could also auto-generate VM name, ... Lets say that the standard API has required inputs that cannot be left null, with the Proxy, one could have use cases where when left null, there is logic to auto-generate the setting of this value based on business rules pulling data from other systems. This Proxy and WF could also integrate with DB, ESB, and there can be out of band WF triggers that after one WF completes and places a message inside the ESB or in the DB, a 2ndary WF detects this, and performs the next WF run required.  Now you have WF when you need it, a scheduling mechanism, a proxy for direct in-band, and the trigger for out-of-process integration.<br><br></div>Please feel free to contact me. It would be a pleasure to speak with you. I first want to best understand Mistral, and will begin testing it with DevStack in my lab.  <br><br></div>Thanks,<br></div>RJ<br><div><div><div><br><br><br><div><div><div><div><div><div><br><div><br><div><div><br><br><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 31, 2014 at 5:03 AM, Renat Akhmerov <span dir="ltr"><<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Raanan,<div><br></div><div>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).</div><div><br></div><div>Just in case, here are the screencasts that can highlight Mistral capabilities (although not all of them):</div><div>* <a href="http://www.youtube.com/watch?v=9kaac_AfNow" target="_blank">http://www.youtube.com/watch?v=9kaac_AfNow</a></div><div>* <a href="http://www.youtube.com/watch?v=u6ki_DIpsg0" target="_blank">http://www.youtube.com/watch?v=u6ki_DIpsg0</a></div><div><br></div><div>Soon there’ll be more.</div><div><br></div><div>And full specification of current Mistral DSL: <a href="https://wiki.openstack.org/wiki/Mistral/DSLv2" target="_blank">https://wiki.openstack.org/wiki/Mistral/DSLv2</a></div><div><br></div><div>Would be nice to talk to you personally if you’re going to the summit or using any other channel and discuss the details )</div><div><span class="HOEnZb"><font color="#888888"><br><div>
<div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div><br>

</div>
<br></font></span><div><blockquote type="cite"><div><div class="h5"><div>On 31 Oct 2014, at 02:22, Raanan Jossefi (RJ) Benikar <<a href="mailto:rbenikar@gmail.com" target="_blank">rbenikar@gmail.com</a>> wrote:</div><br></div></div><div><div><div class="h5"><br><blockquote type="cite"><br>Hi,<br><br>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.<br><br>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?   <br><br>My current use case looks like this:<br><br>1) Tenant requests VM with specific properties (image, etc etc) --> Service Now<br>2) Service Now ---> API ( based on properties/inputs ) query a DB to automatically generate a server name )<br>3) API ---> OpenStack API to provision new VM.<br><br><br>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.<br><br>Your advice is kindly appreciated,<br>Raanan <br><br><br><br></blockquote><br></div></div><span class="">_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></span></div></blockquote></div><br></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div>