Open Stack

On 11/10/2015 10:28 AM, Renat Akhmerov wrote:
>
>
>> On 09 Nov 2015, at 20:43, Adam Young <ayoung at redhat.com> wrote:
>>
>> On 11/06/2015 06:28 PM, Tim Hinrichs wrote:
>>> Congress allows users to write a policy that executes an action under certain conditions.
>>>
>>> The conditions can be based on any data Congress has access to, which includes nova servers, neutron networks, cinder storage, keystone users, etc.  We also have some Ceilometer statistics; I'm not sure about whether it's easy to get the Keystone notifications that you're talking about today, but notifications are on our roadmap.  If the user's login is reflected in the Keystone API, we may already be getting that event.
>>>
>>> The action could in theory be a mistral/heat API or an arbitrary script.  Right now we're set up to invoke any method on any of the python-clients we've integrated with.  We've got an integration with heat but not mistral.  New integrations are typically easy.
>> Sounds like Mistral and Congress are competing here, then.  Maybe we should merge those efforts.
> I may be wrong on this but the difference is that Mistral provides workflow. Meaning you can have a graph of tasks related by conditional logic whereas Congress action is something simple like calling a function. Correct me if my understanding is wrong. I actually don’t know at this point whether a workflow is really needed, IMO it does make sense if we need to create a bunch of heavy resources so it should be an HA service managing the process of configuring/creating the new tenant. The power of workflow is in automating long-running stuff.
>
> But both technologies are missing notifications part now.

This does not need to be super complicated; we need a listener that can 
kick off workflows.  If congress is that listener, super.


I would think that it would then be

1. Keystone sends "new federated user" notification out on the message bus.
2. Congress Picks up the message and checks policy to see what should be 
done.
3. Congress calls Heat to fire off template for autoprovisioning user.

It could also be:

1. Keystone sends "new federated user" notification out on the message bus.
2. Murano Picks up the message and checks policy to see what should be done.
3. Murano calls Heat to fire off template for autoprovisioning user.


You are suggesting it should be:

1. Keystone sends "new federated user" notification out on the message bus.
2. Congress Picks up the message and checks policy to see what should be 
done.
3. Congress calls Murano to fire off template for autoprovisioning user.

And, the most complex solution:

1. Keystone sends "new federated user" notification out on the message bus.
2. Congress Picks up the message and checks policy to see what should be 
done.
3. Congress calls Murano to fire off template for autoprovisioning user.
4. Murano calls Heat to fire off template for autoprovisioning user.

Personally, I would prefer:

1. Keystone sends "new federated user" notification out on the message bus.
2. Heat Picks up the message and checks policy to see what should be done.
3. Heat fires off template for autoprovisioning user.

Why the last:  Heat already exists and already has a message listener.






>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev