method_missing for missing attr

[jameswnl]

#95

[jameswnl]

@syncrou @bdunne this is a naive fix

[gmcculloug]

@bzwei Please review

[bzwei]

@jameswnl The idea is good. Need to add responding_to_missings?. Also please add a spec test.

[jameswnl]

@miq-bot add_label bug

[bdunne]

😱 I need to investigate further to figure out how we got here, but this feels pretty drastic.

[miq-bot]

Checked commits jameswnl/ansible_tower_client_ruby@15ad288~...699b2f6 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
3 files checked, 0 offenses detected
Everything looks fine. 🍰

[bzwei]

@bdunne The model class and methods are created while converting the first hash. If the second hash has some keys that do not appear in the first hash, you will get method not exist error if trying to access them. The fix tries to add new methods if possible.

[jameswnl]

@bdunne yes please!

[jameswnl]

@bdunne check my workaround fix for ManageIQ/manageiq-providers-ansible_tower#9 to get the spec to pass

[jameswnl]

@miq-bot add_label blocker

[miq-bot]

@jameswnl Cannot apply the following label because they are not recognized: blocker

[Fryguy]

I reviewed this with @jameswnl and @bdunne and what we discovered is (ignoring the current hack that's in the refresher_v2.yml) that every credential in the v2 yml does not have a domain and every credential in the v3 yaml does have a domain. This means that when talking to the same provider, the API is consistent and this issue doesn't exist.

However, the tests don't do that. One set of tests runs against a v2 API, and another set of tests run against v3. Since the models are shared, they are effectively creating test contamination depending on which one loads first and defines the class.

The only way this could happen in the real world is if 2 different towers are accessed in the same process and those towers are two different API versions. IMO, the only way to handle this is to create separate class sets based on the tower version. Those class sets can be subclasses of a common class to allow simpler .is_a? calls, if that's desired.

Credential
├─ CredentialV2
└─ CredentialV3

Within a kind, we're not sure if different kinds of the same type have different payloads. If they do, we may need to further subclass by kind.

Credential
├─ CredentialV2
│  ├─ CredentialVmwareV2
│  └─ CredentialAwsV2
└─ CredentialV3
   ├─ CredentialVmwareV3
   └─ CredentialAwsV3

In the above I just tacked on the V2/V3...it could also be done like one of the following

• Credential::V2::Vmware < Credential
• Credential::V2::Vmware < Credential::V2 < Credential

[Fryguy]

It seems this is sort of already done for JobTemplate:

ansible_tower_client_ruby/lib/ansible_tower_client/api.rb

Lines 155 to 163 in 3af723b

	def job_template_class
	@job_template_class ||= begin
	if Gem::Version.new(version).between?(Gem::Version.new(2), Gem::Version.new(3))
	AnsibleTowerClient::JobTemplateV2
	else
	AnsibleTowerClient::JobTemplate
	end
	end
	end

. Perhaps this can be done strategically for Credential to get over that bug, then generically for all classes in a follow up.

[miq-bot]

@jameswnl Cannot apply the following label because they are not recognized: blocker