Updates to provide compatibility with Fog 2.4.0, take 2

[vicomte]

Ooops, crunched my own PR #48 . Trying again.

Remaining Issues:

• Should Aliases to the old names be included here for better compatibility?
• LoadBalancer test failures

[vicomte]

@geemus new pull req, I cancelled the prev on accident.

[geemus]

K , thanks. I have some travel presently, but will try to get to it week after next.

[geemus]

FWIW, the way I've usually done renames in stuff has been to still support the old name, but when you use it there is a deprecation warning that then passes things along to the new version. So basically aliasing but a bit noisier. Not saying we have to do that here, but thought I would share it as a data point at least.

That being said, it's a lot easier to do this with methods than classes. Not sure if there is a particularly nice/clean way to proceed or if it's more trouble than it's worth (it's also been a while since I worked on one of these conversions myself, so my memory is a little fuzzy).

[geemus]

I'll work on a review of what's here, but could you maybe rebase this when you get a chance? I think that should bring in the github actions/ci config so that we can get the test run and see the load balancer or other issues.

[geemus]

Thanks again for taking this on, I know from experience how tedious it can be to get through these renames. I was finally able to find some time to review everything and it's looking good so far.

I think it's probably good to have the aliases like you do at least for the time being for backwards compatibility, it might be slightly nicer to have those classes actually warn and then handoff like I mentioned (I guess you could do it on initialize probably). What do you think?

Hopefully if we rebase the CI will run and then that can hopefully give us something to dig into around the load balancer stuff (though it looks like master/main CI is failing already anyway, so maybe it's a broader issues anyway).

[vicomte]

I'll work on a review of what's here, but could you maybe rebase this when you get a chance? I think that should bring in the github actions/ci config so that we can get the test run and see the load balancer or other issues.

This pr is current on fog-rackspace:master, not sure why it isn't kicking in.

[geemus]

Oops, sorry about that then. Let me try to close/reopen, sometimes that does it.

[geemus]

Ok, so that does appear to have kicked off the tests again.

Unfortunately I think they are broken on main as well as this branch, which makes things harder certainly.

@vicomte Could you help point me to the particular LoadBalancer related breakage you were referring to so we can maybe try to sort that out at least?

[vicomte]

The get_stats_test looks like something upstream changed what it is expecting. I looked at it briefly, but wasn't sure if changing this arg to just pass the attr hash was the correct action.

   tests/rackspace/requests/load_balancers/get_stats_tests.rb
      Fog::Rackspace::LoadBalancers | load_balancer_get_stats (rackspace)
    Initialization parameters must be an attributes hash, got Fog::Rackspace::LoadBalancers::VirtualIp     <Fog::Rackspace::LoadBalancers::VirtualIp
      id="204",
      address="246.294.440.598",
      type="PUBLIC",
      ip_version="IPV4"
    > (ArgumentError)
      /Users/mhassman/.rvm/gems/ruby-3.2.2/gems/fog-core-2.4.0/lib/fog/core/collection.rb:89:in `new'
      /Users/mhassman/.rvm/gems/ruby-3.2.2/gems/fog-core-2.4.0/lib/fog/core/collection.rb:79:in `block in load'
      /Users/mhassman/.rvm/gems/ruby-3.2.2/gems/fog-core-2.4.0/lib/fog/core/collection.rb:19:in `each'
      /Users/mhassman/.rvm/gems/ruby-3.2.2/gems/fog-core-2.4.0/lib/fog/core/collection.rb:19:in `each'
      /Users/mhassman/.rvm/gems/ruby-3.2.2/gems/fog-core-2.4.0/lib/fog/core/collection.rb:79:in `load'
      /Users/mhassman/Projects/fog-rackspace/lib/fog/rackspace/models/load_balancers/load_balancer.rb:111:in `virtual_ips='