Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[google] Fix Google Engine tests #2509

Closed
wants to merge 18 commits into from
Closed

Conversation

allomov
Copy link
Contributor

@allomov allomov commented Dec 26, 2013

Google Engine live tests fail after v1 update. More fixes coming.

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling e809e0e on allomov:google-tests into 7880a55 on fog:master.

@allomov
Copy link
Contributor Author

allomov commented Dec 26, 2013

@icco I've found interesting bug/feature in GCE REST API. Different types of requests are using different object representations in fields with the same names: for instance Instances#get will return URL-like zone, but in the same time Instances#reset call requires you to specify zone as a simple name. So if you call

compute.services.each { |s| s.reset }

, you will get this error:

Parameter 'zone' has an invalid value: https://www.googleapis.com
/compute/v1/projects/<project-name>/zones/us-central1-a. 
Must match: /^[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?$/. (ArgumentError)

@allomov
Copy link
Contributor Author

allomov commented Dec 26, 2013

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling ce570cf on allomov:google-tests into 7880a55 on fog:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling aef8974 on allomov:google-tests into 7880a55 on fog:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-12.45%) when pulling ffce747 on allomov:google-tests into 7880a55 on fog:master.

end
operation
operation = service.operations.new(service.delete_disk(name, zone_name).body)
operation.wait_for { ready? }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is slightly different then what currently exists. To be the same it should be operation.wait_for { !pending? }.

@icco
Copy link
Member

icco commented Dec 26, 2013

As for the zones bug, we've come across that before. I had gone through any made it so all requests at the time took just a zone name from our perspective and tweaked it to fit the API. It looks like some of that got deleted (doh). The key when reading the docs is if it wants a zone resource, you give it the full URL, and if it just wants the zone name, then you do that. The best place to do this is in the request.

In a perfect world, a user would pass in either a url or a shortened zone name into the model, and the request would clean it up and make it perfect.

@allomov
Copy link
Contributor Author

allomov commented Dec 27, 2013

@icco I don't like the idea to have undetermined value format inside zone_name or machine_type fields. You can divided such type of fields into zone_url and zone_name (for instance) and set them after zone attribute is set appropriately, but you shouldn't have in zone_name either URL or name and delegate request to deal with it.

@allomov
Copy link
Contributor Author

allomov commented Dec 27, 2013

I see this solutions:

  • fast one: use converter to get stored attribute in one way.
  • other one: add zone_url and zone_name getters (maybe also hide zone getter to prevent misunderstandings) which will work using @zone variable that will be set with zone=

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling 7e5dece on allomov:google-tests into 7940b30 on fog:master.

request :set_metadata


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: delete extra line.

@icco
Copy link
Member

icco commented Dec 27, 2013

@allomov, I don't think I understand what you're trying to do with the converter or what you're saying about zones. The model is the user interface, we take in data from the user, validate it and pass it on to the request, which builds the request and sends it off to GCE. We shouldn't care what the user passes into our model, as long as we are consistent with what we return to them.

Maybe write a test explaining the bug and the desired outcome?

@ghost ghost assigned icco Dec 27, 2013
@allomov
Copy link
Contributor Author

allomov commented Dec 27, 2013

@icco I think this illustrates what I am trying to do: https://github.com/Altoros/bosh/blob/google-cpi/bosh_google_cpi/spec/integration/remove_all_instances_spec.rb#L54-L56
without converter you'll have an error:

Parameter 'zone' has an invalid value: https://www.googleapis.com
/compute/v1/projects/<project-name>/zones/us-central1-a. 
Must match: /^[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?$/. (ArgumentError)

If you use instance that is creates by get request, then you'll have zone field with URL mapped to zone_name. Obviously you can solve this part in delete request.

But the problem is that zone URL is stored in zone_name field and zone name is not zone URL.

@allomov
Copy link
Contributor Author

allomov commented Dec 27, 2013

@icco this issue is solved in different parts in different way. for instance in disk. I think such thing should be done for all objects and fields that need it. what way do you prefer ?

@allomov
Copy link
Contributor Author

allomov commented Dec 27, 2013

@icco I strongly recommend to distinguish zone_name and zone_url attributes fields to prevent misunderstandings in future. I think I will create PR to show you what I mean.

@icco
Copy link
Member

icco commented Dec 28, 2013

so, my point is that we shouldn't need to show the zone url to users. The zone name is just a shortened representation of the zone url. I personally like how we do it in Disk, and would love if that was consistent across the project. At one point it was, but over time I guess we've gotten sloppy. I guess my problem with the converter is it doesn't make much sense to me and seems far too generic. When else would you use something like that? Why not just put it into the zone method like we do with disk? I guess my point is I'd prefer to be explicit about the transformation that we're doing to the data we're getting back.

@allomov
Copy link
Contributor Author

allomov commented Jan 8, 2014

@icco ok, I guess we can go with it :)
Will change my approach :bowtie:

@coveralls
Copy link

Coverage Status

Coverage decreased (-12.56%) when pulling 9ff70d4 on allomov:google-tests into 2560ac1 on fog:master.

@allomov
Copy link
Contributor Author

allomov commented Jan 8, 2014

@icco I want to follow least astonishment principle in the question with urls and names. Personally I was surprised with fact that zone can take either zone url either zone name. I removed attributes converter and came with following solution: https://github.com/allomov/fog/blob/google-tests/lib/fog/google/requests/compute/reset_server.rb#L12-L13 also I've added requests helper to store common helper methods.

@allomov
Copy link
Contributor Author

allomov commented Jan 8, 2014

@icco if you agree with this approach, I'll move other requests to use this convention.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.45%) when pulling 134967e on allomov:google-tests into 2560ac1 on fog:master.

@icco
Copy link
Member

icco commented Jan 8, 2014

Sounds good to me. Thanks!

@coveralls
Copy link

Coverage Status

Coverage increased (+0.04%) when pulling c48392d on allomov:google-tests into 7f7665a on fog:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-12.7%) when pulling e8ca5b9 on allomov:google-tests into 612e33a on fog:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.01%) when pulling 28e3df3 on allomov:google-tests into 8e393db on fog:master.

@allomov
Copy link
Contributor Author

allomov commented Jan 15, 2014

I close this PR as far I as merged this branch to #2501.

@allomov allomov closed this Jan 15, 2014
@geemus
Copy link
Member

geemus commented Jan 15, 2014

Thanks!

On Wed, Jan 15, 2014 at 5:33 AM, Alexander Lomov
notifications@github.comwrote:

Closed #2509 #2509.


Reply to this email directly or view it on GitHubhttps://github.com//pull/2509
.

@allomov allomov deleted the google-tests branch June 6, 2014 11:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants