This happens to me every time I restart Hudson (after I change something in the main configuration). I'm using Hudson 1.352 and ec2 plugin 1.7.

After some investigation it looks as if the config.xml file refers to the cloud node the wrong way. The config.xml refers to hudson.plugins.ec2.EC2Cloud while it should in fact use hudson.plugins.ec2.AmazonEC2Cloud or hudson.plugins.ec2.Eucalyptus.

Looks like fallout from the EC2 refactoring into separate clouds, I guess.

The issue is due to the following lines at the bottom of EC2Cloud.java:

    static {
        // backward compatibility. EC2Cloud used to be a concrete class that represents AmazonEC2Cloud
        Hudson.XSTREAM.alias(EC2Cloud.class.getName(),AmazonEC2Cloud.class);
    }

This is fine for writing the config.xml, but unfortunately the config.xml is deserialized (on startup) by XStream before the EC2Cloud class is initialized, so XStream is not aware of the alias when deserializing the config.xml.

A simple fix would be to rename AmazonEC2Cloud back to EC2Cloud, and maybe rename EC2Cloud AbstractEC2Cloud or something. This would enable all existing configs to work correctly since it's obvious that no one out there has a config with an AmazonEC2Cloud in it.

But I think there is a larger issue with the plugin initialization lifecycle here. If plugins can contribute extensions to core components, they must have some way to contribute configuration options such as this earlier in the initialization cycle. IE, since the config.xml is read before plugins are initialized, but may contain data from those plugin's classes.

Or is there some other existing way to solve this issue?

I've attached a hand-built version of the ec2 plugin which implements my simple suggestion above. I'd appreciate someone downloading it and see if it resolves their issues as well. I expect it will; it did for me.

I've also attached a patch which implements my suggested solution:

• Rename EC2Cloud to GenericEC2Cloud
• Rename AmazonEC2Cloud to EC2Cloud
• Remove the Xstream alias for AmazonEC2Cloud

Unfortunately, the patch is ugly as sin because it looks like modifications to existing files. Perhaps it would be best to be applied using the simple instructions above instead of applying the patch?

It is finally fixed by JENKINS-6782.
So resolved as duplicate.