Feedback requested: Helper gem for Automate development

Automate
#1

From the conversations and presentations at the MIQ Summit 2016 it seems like the community is moving towards using custom gems to help develop and manage Automate code.

Below is one of our public gems that we use to eliminate code duplication around logging, troubleshooting, and to also make some common tasks easier.

If anyone wants to use this gem in their code, feel free. If you have feedback on the concept, code quality, or have ideas for code that would be useful

The released version on rubygems is 0.2.0 https://github.com/ewannema/miq_dev_util/tree/v0.2.0.

There are a few enhancements that we are working on in the master branch if you want examine those changes and potentially build the gem yourself. https://github.com/ewannema/miq_dev_util

This gem is targeted specifically at general use Automate development, but here is an example of an extension to rbvmomi for VIX calls that a co-worker wrote for a different domain of code reuse. https://github.com/dericcrago/rbvmomi_helper

2 Likes
#2

Thanks @ewannema for sharing,…that’s awesome!

#3

+1

#4

Per usual we continue to:

swallow exceptions -

def vm_by_id(vm_id)
      @evm.vmdb('vm_or_template', vm_id)
    rescue StandardError
      nil
    end

require too much boilerplate -

options = {}
options[:namespace] = 'MyCustomCode'
options[:class_name] = 'Methods'
options[:instance_name] = 'do_something'
options[:user_id] = $evm.vmdb(:user).find_by_userid('admin').id

hard code attributes instead of making them parameters with sensible defaults -

#class MiqDevUtil::Logger
def initialize(evm, method_name)
@evm = evm
@method_name = method_name
@dump_log_level = :info #looking at you info
end

#5

@woot4moo Thanks for the feedback. It looks like you took extra effort in signing up for an account just to provide it.

RE: exceptions
I am struggling with the correct approach here. This gem is intended to be used by Automate developers who tend not to be very familiar with the underlying Rails code. I am not sure what an automate developer would do with an exception from $evm.vmdb.

Perhaps the expectation is that they would catch the exception and perform a retry in the state machine?

RE: boilerplate
This method is really just a wrapper providing the functionality of $evm.execute('create_automation_request') for a < CF 4.0 system and as such mirrors what I think is the common way of calling that method based upon comments in this thread: Running an Automate method in a particular zone

Would you suggest that the helper method provide its own interface which abstracts the options hash needed by the underlying service method?

RE: hard coded attributes
Yep, clearly not the best idea. I can look at updating it in a future release.

#6

@ewannema I do hope my comments did not come off overly critical. In the morning I can offer some code here that could be used, if there is interest.