[Openstack-operators] Deprecation of in tree EC2 API in Nova for Kilo release

George Shuklin george.shuklin at gmail.com
Thu Jan 29 20:35:43 UTC 2015


On 01/28/2015 09:56 PM, Sean Dague wrote:
> The following review for Kilo deprecates the EC2 API in Nova -
> https://review.openstack.org/#/c/150929/
>
> There are a number of reasons for this. The EC2 API has been slowly
> rotting in the Nova tree, never was highly tested, implements a
> substantially older version of what AWS has, and currently can't work
> with any recent releases of the boto library (due to implementing
> extremely old version of auth). This has given the misunderstanding that
> it's a first class supported feature in OpenStack, which it hasn't been
> in quite sometime. Deprecating honestly communicates where we stand.
>
> There is a new stackforge project which is getting some activity now -
> https://github.com/stackforge/ec2-api. The intent and hope is that is
> the path forward for the portion of the community that wants this
> feature, and that efforts will be focused there.
>
> Comments are welcomed, but we've attempted to get more people engaged to
> address these issues over the last 18 months, and never really had
> anyone step up. Without some real maintainers of this code in Nova (and
> tests somewhere in the community) it's really no longer viable.
>
>
I think, if we talking about 'mature openstack', first step of 
deprecation should be removal from sample configs and moving 
documentation for it to chapter 'obsolete functions'. At least one 
release it should be deprecated in documentation, not in the code. Next 
few releases should just mark it as deprecated, and just print warning 
in logs. And only after that it can be removed from code.

To be honest I don't really like deprecation rate in Openstack. Compare 
to Linux motto: 'If it's used it is not deprecated'. I understand that 
developers hate old code, but from usability (operators) point of view, 
all stuff should just continue work as it is after upgrade. How many 
application stops working due 'obsolete syscall' after kernel update? 
(F.e. I see notices about deprecation of oom_adj for last 5 years - and 
it still ok to use). And look to the openstack! Half of the code is 
already deprecated, second halt is candidate to deprecation...

 From user point of view all openstack is just big bug big pile of 
changes. Half of older code does not work with neutron or work 
incorrectly (they expects simple nova networking). And what should I (as 
operator) say to user who complains that vagrant/fog code can not 
connect to networking and using local only network instead of internet? 
(It use any first network by uuid it receive). It is me guilty (who use 
neutron instead of nova-networks), is it vagrant wrong, is it fog wrong, 
is it user wrong? I think user is wrong. Wrong user with wrong money. 
Should go away.

Deprecation:
* no one use, no one notice, no one complains, one-two releases and it's 
gone.
* If someone use it, it should be the same like cutting a leg. May be it 
is cancer. But if you can live with it - better not to cut.



More information about the OpenStack-operators mailing list