+1....makes sense to me. I will write up a Blueprint for this for review in Ironic and we take it from their.
I don't see this as evil firmware, more a good process we need to automate as part of sanity checks before taking a leased baremetal back and making it available in the pool again, imho. Or do others see it differently, if so would like to hear so. /Alan -----Original Message----- From: CARVER, PAUL [mailto:pc2...@att.com] Sent: January-16-14 8:34 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder. Clint Byrum wrote: >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? I think a change of subject line is in order for this topic (assuming it hasn't been discussed in sufficient depth already). I propose "[Ironic] Evil Firmware" but I didn't change it on this message in case folks interested in this thread aren't reading Ironic threads. Ensuring clean firmware is definitely something Ironic needs to account for. Unless you're intending to say that multi-tenant bare metal is a dead end that shouldn't be done at all. As long as anyone is considering Ironic and bare metal in general as a viable project and service it is critically important that people are focused on how to ensure that a server released by one tenant is "clean" before being provided to another tenant. It doesn't even have to be "evil" firmware. Simply providing a tenant with a server where the previous tenant screwed up a firmware update or messed with BIOS settings or whatever is a problem. If you're going to lease bare metal out on a short term basis you've GOT to have some sort of QC to ensure that when the hardware is reused for another tenant it's as good as new. If not, it will be all too common for a tenant to receive a bare metal server that's been screwed up by a previous tenant through incompetence as much as through maliciousness. _______________________________________________ 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
