Yeah, I think the evil firmware issue is separate and should be solved separately.
Ideally, there should be a mode you can set the bare metal server into where firmware updates are not allowed. This is useful to more folks then just baremetal cloud admins. Something to ask the hardware vendors for. Kevin ________________________________________ From: CARVER, PAUL [pc2...@att.com] Sent: Thursday, January 16, 2014 5: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
