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!!!
Alan -----Original Message----- From: Clint Byrum [mailto:cl...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
