feat: configure flavors in Nova automatically

[skrobul]

This PR brings a little operator style application that monitors a directory with YAML specifications of the machine flavors. If any of the files in the linked repository changes, the application parses all the specs in a directory, then compares and reconciles them with the configured Nova instance.

Please note that this will NOT delete (prune) flavors that have been removed from the repository.

Closes https://rackspace.atlassian.net/browse/PUC-598
Supersedes #454

Merge with https://github.com/RSS-Engineering/undercloud-deploy/pull/224

[cardoe]

I'm still wondering why not just using ansible and having a playbook for managing a flavor and it takes in the flavor spec as an input?

[skrobul]

I'm still wondering why not just using ansible and having a playbook for managing a flavor and it takes in the flavor spec as an input?

OK, that's fair question - let me break this down. At the moment the Flavor specifications are presented as collection of YAML files in a specific structured format.
For each of those files, we have to execute some business logic in order to make them usable. Some of those tasks are:

• parsing the input and validating that given flavor is defined correctly
• filtering out the records that are not pertinent to a given environment
• for the data itself, there are various unit conversions needed. For example, the specs have the memory size defined in gigabytes, but Nova expect them to be defined in mebibytes and the BMC/Redfish on the baremetal node reports them as megabytes.
• for each of the flavors, the name will be different depending on the context - for example specification will say nonprod.gp2.small but in Nova this needs to have a resource class of resources:CUSTOM_BAREMETAL_GP2SMALL and in Ironic, this has to be baremetal.gp2small.
• since Nova API does not support 'update' operation (unless you are updating just the description), to update flavors they need to be deleted and recreated. It's good to do that only when needed.

Now, you could of course implement all this logic inside of Ansible (which really is just a YAML wrapper around Python), but I am pretty sure it will get messy and untestable pretty quickly. You could write a custom module for Ansible, which would again be just another Python script.

Alternatively, you could manually write out playbooks with some of this data precomputed. However, this approach would result in duplicated data in various formats, which would make it more error-prone and require more work to maintain.

For the sake of argument, let's say we decided to use Ansible for all of this and you have a role that sets up flavors in Nova. Now you need to make sure that you run this playbook every time someone adds or removes a new flavor. As far as I know, we do not have the machinery to do that at the moment, so it would probably require additional dependencies like Argo to detect repository changes and yet another container image to execute the Ansible.

On top of all that, the testability of such solution would be difficult to achieve and quite convoluted.

Based on these considerations, I believe implementing this in a programming language like Python is a more suitable approach than using a markup language.

[cardoe]

I'll say long term I don't think this is the way to go. This is a lot of code for just flavor handling and we've got to handle images and keystone objects. But it moves us forward.

[cardoe]

I'll say long term I don't think this is the way to go. This is a lot of code for just flavor handling and we've got to handle images and keystone objects. But it moves us forward.