warn about group-id --> group-name in 2011-01-01 EC2 API

[jtriley]

Originally I thought filters were broken all together, below is the initial report:

I was experimenting with using boto 2.0 in StarCluster and quickly realized that filters are badly broken in boto 2.0. Even the simplest of filters don't work (they never return anything). I used 'git bisect' to figure out that the commit causing the issue was c722d82. Looking at the commit I noticed that the default EC2 API version has been bumped from 2010-08-31 to 2011-01-01 in the 2.0 release and the same in the latest git code. Sure enough, changing the API version back to 2010-08-31 in the latest boto git code gets filters working again.

I haven't had a chance yet to figure out what needs to be updated to get filters working with 2011-01-01 but when I do I'll do my best to fix it and make a pull request if someone else doesn't beat me to it ;). For me this is a total showstopper for upgrading deps to boto 2.0+ until it's fixed and released. Fortunately 2.0b4 is still available on pypi and uses 2010-08-31 API so there's at least a work around for now...

[jtriley]

Nevermind, I found the culprit after looking at @gtaylor's comment on c722d82. In my filters I was using group-id which in the old API mapped to the security group's name. In the new 2011-01-01 API you must use group-name instead. group-id is now a newly auto-assigned identifier for security groups similar to instance ids, image ids, etc.

Perhaps we should raise a warning when using group-id in filters? At the very least documenting that the group-id changed in pydoc/docs would be useful. Which approach do folks prefer? I'm willing to make the changes...

[garnaat]

That is a pretty nasty, incompatible change they made. Personally, I think this merits a runtime warning. @gtaylor, any opinion?

[gtaylor]

A runtime warning and documenting this as backwards-incompatible is probably the way to go. If others notice breakage, they'll at least have something to go from.

It might not hurt to have a changes.rst doc that also hi-lights backwards-incompatible stuff like this. Celery does a good job with this and may serve as a useful inspiration: http://ask.github.com/celery/changelog.html

[jtriley]

I've also discovered that DescribeSpotInstanceRequests' launch.group-id filter now expects the security group id instead of the name. This will also require a runtime warning and documenting.

[jtriley]

@gtaylor - I agree, Celery does a fantastic job with maintaining a Changelog. I just submitted a pull request with the warnings and a new Changelog.rst for boto which contains notes about backwards-incompatible filter changes in 2.0.

[jtriley]

closed by ba1734b