Update service template API

[jntullo]

This PR updates the way update on a service template works.

Previously, it was using the generic method, but it requires the update_catalog_item method added in #13811 with the same format required in create and returned via show:

        {
          :name        => 'Updated Template Name',
          :display     => 'false',
          :description => 'a description',
          :config_info => {
            :miq_request_dialog_name => request_dialog.name,
            :placement_auto          => [true, 1],
            :number_of_vms           => [1, '1'],
            :src_vm_id               => [new_vm.id, new_vm.name],
            :vm_name                 => new_vm.name,
            :schedule_type           => ['immediately', 'Immediately on Approval'],
            :instance_type           => [flavor.id, flavor.name],
            :src_ems_id              => [ems.id, ems.name],
            :provision               => {
              :fqname    => ra1.fqname,
              :dialog_id => nil
            },
            :reconfigure             => {
              :fqname    => ra3.fqname,
              :dialog_id => service_dialog.id
            }
          }
        }

@abellotti since update was already implemented, I am not sure if this is considered a breaking change that requires a version bump.

@miq-bot add_label enhancement, api
@miq-bot assign @abellotti

[abellotti]

how different are the update payloads without and with this PR ?

I think previous release service_templates edit was basic stuff, name/description which should still valid with this PR.

[jntullo]

@abellotti the payloads now take in the config_info - name, description etc is all still valid

[abellotti]

Ahh ok, no need to bump version then.

However, I'm trying to just edit name (no config_info in update payload), and I'm getting the following:

POST /api/service_templates/1

{
  "action" : "edit",
  "resource" : { "name" : "updated_vm_provision_catalog_item" }
}

{
  "error": {
    "kind": "bad_request",
    "message": "Could not update Service Template - undefined method `except' for nil:NilClass",
    "klass": "Api::BadRequestError"
  }
}

Maybe there needs to be a fix to the update_catalog_item() method ?

Could you also add a test that exercises above failure ? i.e. just update name.

Thanks

[jntullo]

@abellotti ah well now that you mention that, I guess there is more to it 😳 - the config_info is required, as it expects the same format that it gets from show - the update includes both updating / adding / removing attributes, which is why it's necessary to send back the config_info. I will add validation on it

[jntullo]

@abellotti LMK what you think about this update. We can keep it so that it uses the super class unless config_info is present. Added in a test for it too

[abellotti]

Thanks for adding a test for update with just name attribute.

While this works, it might be better if update_catalog_item() could handle both cases. Could you see what it would take to update that method ? i.e. maybe only call update_service_resources and update_resource_actions only if config_info is present.

[jntullo]

@bzwei would appreciate your input here - should the API allow for updating of service_templates without config info (ie can update just basic attributes such as name)? Or should we require config_info?

[bzwei]

I don't have personal preference. Our current backend code would require it. If we make config_info optional, then more code changes are required.

If from common API practice any field is optional and missing field means do not update, then yes, config_info should be optional too. In reality from our UI usage it seems every field will be provided.

[jntullo]

@abellotti going to check for config_info in update_catalog_item in #14147

[miq-bot]

Checked commit jntullo@200ff70 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
3 files checked, 0 offenses detected
Everything looks good. ⭐

[abellotti]

This looks great @jntullo 👍

Thanks @jntullo and @bzwei for making the updates in the model more flexible.