Failing to set name of Volume we booted from is no longer fatal

[pjdarton]

If we boot from a VolumeSnaphot, the Instance has a Volume attached to it, but OpenStack doesn't automatically set its name and it sometimes forgets to remove it with the Instance, so the plugin sets the name to make it easier for humans to figure out who owns what Volume.
... however this doesn't always work with all versions of OpenStack (see #277) and it's better that we live without this naming than fail to work at all, so we should log this error instead of letting it escape.

[pjdarton]

Resolved merge issue (38885fd#diff-ad5b949f8229920edea4ba285ad66563R191 was deemed too close to my changes to permit auto-merge) and rebased on master.
Code changes remain exactly the same as they were in 2a33b75

[olivergondza]

@pjdarton, is there still a scenario for this to fail after we integrate openstack4j version with openstack4j/openstack4j#10?

[pjdarton]

Yes.

It's OpenStack; IME anything can fail.
e.g. some OpenStack instances have rate-limiting on them which means that any API call can be rejected.

If we lived in an ideal world then this could never happen, but we don't live in an ideal world, so this code change makes the plugin degrade more gracefully in non-ideal circumstances.
This code change means that a non-critical failure (at this point in the code) is not treated as a critical failure.

i.e. Yes, I think it's still worthwhile having this.

[olivergondza]

Alright, thanks!