[salt-cloud] Fix creating droplet from snapshot in digital_ocean provider

[systembell]

Problem
Digital Ocean's API returns 'None' instead of None for a non-existent image slug, rendering the conditional in get_image useless:

[DEBUG   ] Sending event - data = {'_stamp': '2015-09-01T19:22:48.162645', 'event': 'requesting instance', 'kwargs': {'ssh_keys': ['XXXXXXX], 'region': 'nyc3', 'ipv6': True, 'private_networking': True, 'backups': False, 'size': '1gb', 'image': 'None', 'name': 'test1'}}
[ERROR   ] Error creating salt-test1 on DIGITAL_OCEAN

The following exception was thrown when trying to run the initial deployment: An error occurred while querying DigitalOcean. HTTP Code: 422  Error: u'{"id":"unprocessable_entity","message":"You specified an invalid image for Droplet creation."}'

Solution
if image['slug'] != 'None'. Fixes #22724.

[techhat]

@Pravka this makes sense, but somebody is going to come along and change it back if there's no comment explaining why it's like this. Could you please add a comment?

[systembell]

@techhat Thanks -- I dug a little deeper and noticed that the real issue is that digital_ocean_v2.avail_images is converting all the values in each image dict (including None) to a string; this was probably not the desired result (the types in the response from Digital Ocean's API should remain the same, especially constants).

So, I've reverted my initial fix and updated avail_images and get_image to fix this behavior.

tl;dr (for those who might come after me and want to change it): changing None to a string (unless it's '') is bad, we shouldn't do it.

[techhat]

I like it. Thanks @Pravka!

[systembell]

FYI @techhat, 2015.8 and develop are also affected by this; I'm assuming that this didn't happen automatically because digital_ocean_v2 was moved to digital_ocean after 2015.5.5. Do you want me to open a separate PR for 2015.8?

[techhat]

@Pravka this will get merged forward into 2015.8 and develop, probably in the next day or so, so don't worry about it. Ping @basepi.

[systembell]

Thanks!

[systembell]

This still has not been merged into 2015.8 or develop.

[rallytime]

@Pravka The change should be in 2015.5, as that is where you made the pull request. It looks correct to me here and here - Sorry, I thought said 2015.5 originally, but you said 2015.8. My mistake. :)

However, I think your original concern was correct about the merge forward. I've ported your change to the digital_ocean.py driver in 2015.8 in #27164. Once that is merged, it should merge-forward cleanly into develop.

[basepi]

Ah, yes, I think I saw these changes but since v2 doesn't exist in 2015.8 I disregarded those changes on the merge forward.

@rallytime for my information, is 2015.5's digital_ocean_v2 the same as 2015.8's digital_ocean? Was it renamed when the old one was deprecated?

[rallytime]

@basepi Yep. D.O. is removing support for their original API Nov 1st. So I removed the original driver (based on APIv1) and renamed digital_ocean_v2.py to just digital_ocean.py starting with 2015.8.0.

[basepi]

Thanks for the heads up. I've probably lost a few fixes on merge forward, unfortunately.

[rallytime]

Yeah I was just thinking that actually. I will see what I can do to get any changes in that driver merged forward today.

[basepi]

If it hasn't changed substantially in 2015.8 you may be able to just eyeball a diff of the two files and bring over the new stuff from 2015.5. Sorry to make your life difficult.

[systembell]

avail_images and get_image are the affected functions. I can open a PR for 2015.8/develop if y'all want.

[rallytime]

@Pravka I already did for this particular pull request. It's been merged into the 2015.8 branch in PR #27164. :)

What @basepi and I were talking about was if there were other changes to this driver in the 2015.5 branch that didn't make it into the 2015.8 for the same reason that this one didn't. I just didn't even think about it. So, @Pravka I think we're good as far as your change here goes. Thanks again for the fix!

[systembell]

Awesome. Thanks!