Just thinking a bit about what effective continued support would mean for Proxmox 3.x in our use case (and I'd guess most other deployed users' too).
Generally it just means security updates, so lets break that down:
The attack surface of the environment overall comprises:
1. Management infrastructure:
a. Proxmox specific tools (<10% ?)
b. Debian infrastructure used to access those tools e.g. web servers, ssh servers etc. (>90%).
2. Parts which are accessible to processes running on the containers themselves:
a. The kernel (approx 99%)
b. Management tools which deal with data container "user data" (approx 1%)
I'm happy we can firewall off or otherwise secure "1." the management infrastructure (and most of that is probably accounted for by Debian LTS anyway), so that's not of a great deal of concern. Of what's left, it's mostly the kernel, which is (I believe) mostly the OpenVZ one (and supported by Virtuozzo out to 2019 according to their Wiki, and the non-VZ parts out to 2020 by Redhat).
I'm not sure how much the Proxmox kernel differs from the OpenVZ one, but the options would appear to be:
1. Security support for the OpenVZ kernel, and all customisations
2. Security support for the OpenVZ kernel, but not any customisations
3. Security support for the OpenVZ kernel only (customisations will be removed - admins will need to opt-in to this kernel series)
So, really when I'm asking for long term support, all I'm asking for is kernel security support (as this is the vast majority of the "attack surface" for my use-case), and if that means foregoing customisations not supplied by upstream OpenVZ, then I'll put up with that too.
The user-space updates which Wheezy-LTS will provide are a nice bonus, but probably don't matter much as the hardware nodes aren't going to be accessible by the Great Unwashed Internet anyway.
So I suppose the question is:
How much is Proxmox willing to carry out this kernel support, and how could they organise community help to accomplish this (and/or solicit financial assistance to get this done - which could even be something creative like paying a Debian or CentOS developer to do-so for x hours per week)?
Cheers,
Tim.