Tuesday, December 3, 2013

clouds bleeding context

In OpenStack havana we had a bug that did not affect functionality, but it bothered me a great deal. In OpenStack grizzly when the Nova Compute driver for VMware's management API would create a new instance (aka virtual machine) it would name the VM in vSphere's API based on the pattern instance-000001 where the number portion of the instance's name was the row number that the instance record was represented by in the Nova database.

There's several really glaring problems here. First, it violates Nova rather blatantly. We were taking a value that you could never utilize in the exposed Nova API and flagrantly exposing it to the world. That's a major violation of Nova's internal implementation details.

Fortunately in Havana we managed to solve this problem and the vSphere name is based on a value that is exposed by Nova. The UUID for the instance is now the vSphere name. We kept the vestigial code that did lookups based on the pattern /instance-\d+/ around just for people doing Nova upgrades. The result is that at least Nova's internals don't bleed into vSphere.

The bug I've filed today is related to the fact that in vSphere the name attribute of a guest virtual machine is not immutable. If a VI Admin edits the instance name with the initially released Havana version of the driver that admin can break their OpenStack automation. Ideally, this should never be a problem since the Nova Compute manager should be able to accomplish all the tasks that a VM administrator or tenant need, but in practice this is likely to be a sore spot with hybrid cloud administrators working in cloud environments that are both OpenStack and vSphere and managed simultaneously through tools like Power CLI or RVC which will allow modification of the name.

Hopefully we'll get a fix that can be applied that will make the linkage between Nova Compute and vSphere's admin tools more robust but until then, there are cloud details that bleed through each layer and that's a sign of possible trouble in design, implementation, and administration.

I'm just trying to watch out for that admin with too many hats to wear.

1 comment:

  1. I'd love us to change the name of the instance to the name that the user uses to create the instance + the uuid (which is what happens when you create multiple instances)

    ReplyDelete