comment the supports feature code

[kbrock]

We have validate_resize for backwards compatibility. It feels safer to just implement this rather than ask the customer to find this method and update it.

the 2 validate methods look like they are implementing the AvailabilityMixin but they are just a boolean method instead

[kbrock]

@bdunne @Fryguy I mostly wanted to document it as we were greping our code base.

both versions of this method have been around since 2016. Since these methods are only used by customer automate scripts running in production, I thought it didn't make sense to introduce the deprecation messages.

I'm also not sure if we want to push supports_resize or supports?(:resize), or just let them all slide.

refs:

• verify https://github.com/ManageIQ/manageiq/pull/7922
• supports https://github.com/ManageIQ/manageiq/pull/9683

[kbrock]

update:

• rebased

I still feel it is best to just add this as a reference for our future selves and not deprecate or make any changes here.

[miq-bot]

Checked commit https://github.com/kbrock/manageiq-automation_engine/commit/6eeb73fc12c80c75411de48a3ed2c4bdd009e18e with ruby 2.6.10, rubocop 1.28.2, haml-lint 0.35.0, and yamllint 1 file checked, 0 offenses detected Everything looks fine. :+1:

[Fryguy]

Since these methods are only used by customer automate scripts running in production, I thought it didn't make sense to introduce the deprecation messages.

That's exactly why we want to mark it deprecated - at least they should see the deprecation in the logs, and then we can remove it later.

But I agree that this PR is just to document and we can deprecate in a separate PR.