GPII-4057: Fix use of removed to_hash in custom Stackdriver code

[stepanstipl]

Ruby protobuf library removed to_hash methods (see details protocolbuffers/protobuf#6166) which breaks our Stackdriver code. This PR fixes the issue.

Changes:

• Use to_h instead of removed to_hash method

The error below happens on the current fresh build of exekube image (although is not present in the gpii/exekube:0.9.2-google_gpii.0 tag):

/rakefiles/stackdriver.rb:111:in `method_missing': undefined method `to_hash' for #<Google::Monitoring::V3::NotificationChannel:0x000056471d319420> 

Note: Looks like our exekube builds are a bit behind, so quite a few libraries got updated when rebuilding from scratch, probably caused by combination of caching and use of alpine:3.8:

google-cloud-env (1.0.5)                            | google-cloud-env (1.2.0)
google-gax (1.5.0)                                  | google-gax (1.7.0)
google-protobuf (3.7.1, 3.6.1)                      | google-protobuf (3.9.0, 3.6.1)
grpc (1.20.0)                                       | grpc (1.22.0)
jwt (2.1.0)                                         | jwt (2.2.1)
multipart-post (2.0.0)                              | multipart-post (2.1.1)
public_suffix (3.0.3)                               | public_suffix (3.1.1)
rake (12.3.2)                                       | rake (12.3.3)

Moving to newer Alpine (3.10 is latest) is still blocked by grpc (which is required for Stackdriver code) failing to build with gcc8 (see grpc/grpc#14452 for details).

[mrtyler]

LGTM

I'm still curious why it seems you are the only person who encountered this error.

[stepanstipl]

I'm still curious why it seems you are the only person who encountered this error.

It turned out it was a different error then last time (same error message undefined method 'to_hash', but for a different reason). Now I'm the only one experiencing the error because I rebuilt the exekube image from scratch, without any caching, and that pulled in several new ruby gems incl. the google-protobuf one.

[amatas]

LGTM

[natarajaya]

To prevent this from happening in future we should lock all gems with bundler (add Gemfile and Gemfile.lock, run bundle install instead of adding gems directly) and call stackdriver.rb via bundle exec.

[stepanstipl]

Thanks for reviews.

To prevent this from happening in future we should lock all gems with bundler (add Gemfile and Gemfile.lock, run bundle install instead of adding gems directly) and call stackdriver.rb via bundle exec.

I think it would be more fruitful to spend effort on migrating to Terraform resources - that would allow to drop the custom code and also move to the latest alpine, instead of adding more layers of dependencies (exekube image does not even have bundler installed atm.).

[natarajaya]

I think it would be more fruitful to spend effort on migrating to Terraform resources

@stepanstipl It would be more fruitful indeed, but it is not a priority now, so I don't understand why original issue from this PR can't be addressed in a proper way, considering that very low effort is needed.