[openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Alan Kavanagh alan.kavanagh at ericsson.com
Fri Jan 17 04:27:41 UTC 2014

The point was that tenant-A can not read or be able to "retrieve any data" once the blade lease is over the the blade is returned to the pool. 
Therefore, what would make sense is that we build an "in-service" a method to ensure that the disk is erased before being brought back into the pool to be made available for provisioning, at least that is my thinking here and the concerns Paul had too. Do I sense a Blueprint!!!


-----Original Message-----
From: Clint Byrum [mailto:clint at fewbar.com] 
Sent: January-16-14 12:25 AM
To: openstack-dev
Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Excerpts from Alan Kavanagh's message of 2014-01-15 19:11:03 -0800:
> Hi Paul
> I posted a query to Ironic which is related to this discussion. My thinking was I want to ensure the case you note here (1) " a tenant can not read another tenants disk......" the next (2) was where in Ironic you provision a baremetal server that has an onboard dish as part of the blade provisioned to a given tenant-A. then when tenant-A finishes his baremetal blade lease and that blade comes back into the pool and tenant-B comes along, I was asking what open source tools guarantee data destruction so that no ghost images  or file retrieval is possible?

Is that really a path worth going down, given that tenant-A could just drop evil firmware in any number of places, and thus all tenants afterward are owned anyway?

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list