Re: [Openstack] Propagation of account state management changes in keystone across all the services
Thanks Jay. Susanne -Original Message- From: Openstack [mailto:openstack-bounces+susanne.balle=hp@lists.launchpad.net] On Behalf Of Jay Pipes Sent: Tuesday, June 25, 2013 2:57 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Propagation of account state management changes in keystone across all the services On 06/25/2013 01:50 PM, Balle, Susanne wrote: > Hi > > We are looking into how to best architect the propagation of account > state management changes in keystone across all the services. For > example, when we delete a customer domain and/or its tenants, it is > currently a multi-step process with potentially many manual tasks. This > is error prone and does not scale. Ideally, we would want the state > change in Keystone to dynamically propagate to all our services so they > can do things like provision or de-provision internal entities. We were > thinking of initially implementing some standard APIs in Keystone to > propagate the state change but are open to discussing the best > architectural path forward to solving this problem( e.g. Message queue, > standard API, etc). > > Additionally we need to be able to do administrative functions like > delete a project and have that propagate throughout all the services and > perform the correct cleanup operations. Hi Susanne, This is what you are looking for: https://blueprints.launchpad.net/keystone/+spec/notifications Please lobby to get this done in Havana. Frankly, Keystone really should get aligned with the rest of the OpenStack projects WRT to notifications and use oslo.notify. Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Propagation of account state management changes in keystone across all the services
On 06/25/2013 01:50 PM, Balle, Susanne wrote: Hi We are looking into how to best architect the propagation of account state management changes in keystone across all the services. For example, when we delete a customer domain and/or its tenants, it is currently a multi-step process with potentially many manual tasks. This is error prone and does not scale. Ideally, we would want the state change in Keystone to dynamically propagate to all our services so they can do things like provision or de-provision internal entities. We were thinking of initially implementing some standard APIs in Keystone to propagate the state change but are open to discussing the best architectural path forward to solving this problem( e.g. Message queue, standard API, etc). Additionally we need to be able to do administrative functions like delete a project and have that propagate throughout all the services and perform the correct cleanup operations. Hi Susanne, This is what you are looking for: https://blueprints.launchpad.net/keystone/+spec/notifications Please lobby to get this done in Havana. Frankly, Keystone really should get aligned with the rest of the OpenStack projects WRT to notifications and use oslo.notify. Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Propagation of account state management changes in keystone across all the services
Susanne: How much synchronicity is required? Can we broadcast an rpc.cast-style event over AMQP and simply tell each component to react as it sees fit, on its own timeframe? Or does Keystone need to get an ACK from every participant before it can proceed? --Daniel Hardman Chief Solutions Architect Adaptive Computing On Tue, Jun 25, 2013 at 11:50 AM, Balle, Susanne wrote: > Hi > > ** ** > > We are looking into how to best architect the propagation of account state > management changes in keystone across all the services. For example, when > we delete a customer domain and/or its tenants, it is currently a > multi-step process with potentially many manual tasks. This is error prone > and does not scale. Ideally, we would want the state change in Keystone > to dynamically propagate to all our services so they can do things like > provision or de-provision internal entities. We were thinking of initially > implementing some standard APIs in Keystone to propagate the state change > but are open to discussing the best architectural path forward to solving > this problem( e.g. Message queue, standard API, etc). > > > > Additionally we need to be able to do administrative functions like delete > a project and have that propagate throughout all the services and perform > the correct cleanup operations. > > ** ** > > Thoughts? > > ** ** > > Susanne > > --- > > Susanne M. Balle > Hewlett-Packard > Cloud Services > > Please consider the environment before printing this email. > > ** ** > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > -- Why? I believe in making complex computing simple so the world can innovate and improve. http://codecraft.co/2013/01/30/why ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Propagation of account state management changes in keystone across all the services
Hi We are looking into how to best architect the propagation of account state management changes in keystone across all the services. For example, when we delete a customer domain and/or its tenants, it is currently a multi-step process with potentially many manual tasks. This is error prone and does not scale. Ideally, we would want the state change in Keystone to dynamically propagate to all our services so they can do things like provision or de-provision internal entities. We were thinking of initially implementing some standard APIs in Keystone to propagate the state change but are open to discussing the best architectural path forward to solving this problem( e.g. Message queue, standard API, etc). Additionally we need to be able to do administrative functions like delete a project and have that propagate throughout all the services and perform the correct cleanup operations. Thoughts? Susanne --- Susanne M. Balle Hewlett-Packard Cloud Services Please consider the environment before printing this email. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
