Volume-backed flavors

This is a blueprint for the short-term option described in this Queens PTG recap email:

http://lists.openstack.org/pipermail/openstack-dev/2017-September/122238.html

Related discussion from the Boston forum too:

http://lists.openstack.org/pipermail/openstack-dev/2017-May/117012.html

This proposes a new microversion to allow setting a volume_backed flag on flavors which will tell nova to auto-generate a volume-backed instance as long as there are no user or image-defined BDMs in the same request, as those take precedence.

This should simplify booting from volume for users and allow operators to configure all of their flavors to use persistent storage for the root disk.

Related efforts:

- https://gist.github.com/mgagne/161bd7eaeb4c747fa1ae97c0bc43c093
- https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/flavor-root-disk-none.html
- https://blueprints.launchpad.net/nova/+spec/create-bdm-from-flavor-extra-specs
- https://blueprints.launchpad.net/nova/+spec/nova-ephemeral-cinder

Issues:

There will be discoverability issues with this given it's a new flavor attribute in a microversion. For example, an admin creates all of their flavors with volume_backed=True so Nova is going to create a volume-backed instance for all instances. However, if the user is only listing and showing flavor details at v2.1 (or any lower microversion than the one that added the new attribute), then they might be surprised why they have a volume-backed instance, and they might even delete it while it's being created (at the same time as the server create) which will actually make the server create fail. Hopefully the name of the flavor will be sufficient to explain it is a volume-backed flavor even if the attribute (or soon to be description field) doesn't get exposed to the user on v2.1.