[openstack-dev] [nova] Deleting 'default' security group for deleted tenant with nova-net
This bug recently came to my attention: https://bugs.launchpad.net/nova/+bug/1241587 I've reopened it, because it is an actual problem, especially for people using nova-network and Rally, which creates and deletes tons of tenants. The obvious simple solution is to allow deletion of the 'default' security group if it is assigned to a tenant that doesn't exist, but I wasn't sure what the most acceptable way to do that within Nova would be. Is it acceptable to perform a call to the Keystone API to check for the tenant? Or is there another, better way? Alternatively, is there a better way to tackle the problem altogether? Thanks! -- Chris St. Pierre __ 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
Re: [openstack-dev] [nova] Deleting 'default' security group for deleted tenant with nova-net
Hi Chris, So there is no rule saying you can't ask keystone. However, we do emit events (audit, needs to be configured) to the message bus when tenants (or in v3 parlance, projects) are deleted. This allows nova to mark things in a way to cleanup / do direct cleanup. There have been a few conversations about this, but we haven't made significant progress (as far as I know) on this topic. The best solution proposal (iirc) was that we need to creat a listener or similar that the other services could hook a callback to that will do the cleanup directly rather than require blocking the main API for the cleanup. Keystone is open to these improvements and ideas. It just doesn't scale of every action from every service has to ask keystone if still exists. Let's make sure we don't start using a pattern that will cause significant issues down the road. --Morgan Sent via mobile > On May 7, 2015, at 09:37, Chris St. Pierre > wrote: > > This bug recently came to my attention: > https://bugs.launchpad.net/nova/+bug/1241587 > > I've reopened it, because it is an actual problem, especially for people > using nova-network and Rally, which creates and deletes tons of tenants. > > The obvious simple solution is to allow deletion of the 'default' security > group if it is assigned to a tenant that doesn't exist, but I wasn't sure > what the most acceptable way to do that within Nova would be. Is it > acceptable to perform a call to the Keystone API to check for the tenant? Or > is there another, better way? > > Alternatively, is there a better way to tackle the problem altogether? > > Thanks! > > -- > Chris St. Pierre > __ > 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
Re: [openstack-dev] [nova] Deleting 'default' security group for deleted tenant with nova-net
Jinkies, that sounds like *work*. Got any links to docs I can start diving into? In particular, keystone audit events and anything that might be handy about the solution proposal you mention. Keystone is mostly foreign territory to me so some learning will be in order. Thanks! On Thu, May 7, 2015 at 12:49 PM, Morgan Fainberg wrote: > Hi Chris, > > So there is no rule saying you can't ask keystone. However, we do emit > events (audit, needs to be configured) to the message bus when tenants (or > in v3 parlance, projects) are deleted. This allows nova to mark things in a > way to cleanup / do direct cleanup. > > There have been a few conversations about this, but we haven't made > significant progress (as far as I know) on this topic. > > The best solution proposal (iirc) was that we need to creat a listener or > similar that the other services could hook a callback to that will do the > cleanup directly rather than require blocking the main API for the cleanup. > > Keystone is open to these improvements and ideas. It just doesn't scale of > every action from every service has to ask keystone if still > exists. Let's make sure we don't start using a pattern that will cause > significant issues down the road. > > --Morgan > > Sent via mobile > > On May 7, 2015, at 09:37, Chris St. Pierre > wrote: > > This bug recently came to my attention: > https://bugs.launchpad.net/nova/+bug/1241587 > > I've reopened it, because it is an actual problem, especially for people > using nova-network and Rally, which creates and deletes tons of tenants. > > The obvious simple solution is to allow deletion of the 'default' security > group if it is assigned to a tenant that doesn't exist, but I wasn't sure > what the most acceptable way to do that within Nova would be. Is it > acceptable to perform a call to the Keystone API to check for the tenant? > Or is there another, better way? > > Alternatively, is there a better way to tackle the problem altogether? > > Thanks! > > -- > Chris St. Pierre > > __ > 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 > > -- Chris St. Pierre __ 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
Re: [openstack-dev] [nova] Deleting 'default' security group for deleted tenant with nova-net
On May 7, 2015 at 11:21:00 AM, Chris St. Pierre (chris.a.st.pie...@gmail.com) wrote: Jinkies, that sounds like *work*. Got any links to docs I can start diving into? In particular, keystone audit events and anything that might be handy about the solution proposal you mention. Keystone is mostly foreign territory to me so some learning will be in order. The event notifications are documented here: http://docs.openstack.org/developer/keystone/event_notifications.html As to the rest of the topic, there are a few threads in the past on the ML such as http://lists.openstack.org/pipermail/openstack-dev/2015-February/055801.html I don’t think we’ve really gotten much further at this point than that. Thanks! On Thu, May 7, 2015 at 12:49 PM, Morgan Fainberg wrote: Hi Chris, So there is no rule saying you can't ask keystone. However, we do emit events (audit, needs to be configured) to the message bus when tenants (or in v3 parlance, projects) are deleted. This allows nova to mark things in a way to cleanup / do direct cleanup. There have been a few conversations about this, but we haven't made significant progress (as far as I know) on this topic. The best solution proposal (iirc) was that we need to creat a listener or similar that the other services could hook a callback to that will do the cleanup directly rather than require blocking the main API for the cleanup. Keystone is open to these improvements and ideas. It just doesn't scale of every action from every service has to ask keystone if still exists. Let's make sure we don't start using a pattern that will cause significant issues down the road. --Morgan Sent via mobile On May 7, 2015, at 09:37, Chris St. Pierre wrote: This bug recently came to my attention: https://bugs.launchpad.net/nova/+bug/1241587 I've reopened it, because it is an actual problem, especially for people using nova-network and Rally, which creates and deletes tons of tenants. The obvious simple solution is to allow deletion of the 'default' security group if it is assigned to a tenant that doesn't exist, but I wasn't sure what the most acceptable way to do that within Nova would be. Is it acceptable to perform a call to the Keystone API to check for the tenant? Or is there another, better way? Alternatively, is there a better way to tackle the problem altogether? Thanks! __ 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
