Open Stack

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.

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.

I believe in my new project, I have begun working with a former US-based
Mirantis employee, his name Koffi Nogbe.  Small world.

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".

Example Use Cases:
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.
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.
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.
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 )

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.

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.

Thanks,
RJ









On Fri, Oct 31, 2014 at 5:03 AM, Renat Akhmerov <rakhmerov at mirantis.com>
wrote:

> 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=u6ki_DIpsg0
>
> Soon there’ll be more.
>
> And full specification of current Mistral DSL:
> 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
>
>
>
> _______________________________________________
> 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/dfcb40fe/attachment.html>