On 11/10/2015 10:28 AM, Renat Akhmerov wrote:
On 09 Nov 2015, at 20:43, Adam Young <ayo...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
