Open Stack

Thanks for bringing this up. We at Reliance are building a team completely
dedicated to make the EC2 API support in OpenStack rock-solid and complete.
Coming from block-storage background, I submitted a few blueprints[1][2][3]
for the volumes stuff, along with the code for them[4][5][6] in the
Icehouse release. Unfortunately, the reviews didn't get the attention they
required and they were pushed to Juno (probably, partly due to it being
residing in Nova but actually being related to Cinder).

I was the only person in our team for a few months to take care of efforts
in this direction. The process of adding more resources has already been
started, although I am expecting that it will take a month of time before
they start actively contributing to upstream code.

The point I am trying to make is that there are people interested in
keeping this layer functional and in a healthy state. Now that we have
promised in the writing that we will dedicate efforts, I think waiting till
end of Icehouse is a good idea. Let this cycle be our last chance to show
that we care for this piece of code :)

I will make sure I make it clear to my team that making the EC2 API
'robust' is more important than making it 'feature complete'. As you can
see from my contributions, I have been guilty of not following this myself
in the past.

Links:
1. https://blueprints.launchpad.net/nova/+spec/ec2-volume-and-snapshot-tags
2. https://blueprints.launchpad.net/nova/+spec/ec2-volume-type
3. https://blueprints.launchpad.net/nova/+spec/ec2-volume-filtering

4. [DescribeVolumes all filters](https://review.openstack.org/#/c/70085/)
5. [EC2 Volume type](https://review.openstack.org/#/c/61041/)
6. [EC2 volume tags(metadata)](https://review.openstack.org/#/c/64690/)

Regards,
Rushi Agrawal
Cloud engineer,
Reliance Jio Infocomm

On 23 April 2014 17:17, Sean Dague <sean at dague.net> wrote:

> I've spent a couple of days getting to the bottom of:
>
> Bug 1302774 - Failed to detach volume because of volume not found error
> prevents vm teardown
>
> This is an ec2 specific failure path, which mostly looks like a
> combination of a not very good test case and the EC2 code in nova
> collapsing the volume states in a way that seems completely incorrect
> based on what I can read on what's expected from this call.
>
> However, these are symptoms of a bigger issue. The EC2 paths in Nova are
> old, fragile, and error prone. The test coverage for these paths is
> minimal, and largely hasn't evolved in the last year. The last
> substantial addition to the EC2 tests in Tempest was by Burt Holtzman in
> July 2013, Burt has also been contributing to the Nova side, but beyond
> Burt, there basically aren't contributors right now.
>
> I really don't like shipping code in Nova that we know isn't good. With
> very few contributions in this code though, it's defacto, if not
> officially, deprecated.
>
> I'd like to see if there are any more people interested in keeping these
> interfaces functional (by contributing both on the nova and tempest
> sides). If so, great!
>
> If we get to the end of Juno in the current state, I think we need to
> consider actually deprecating the EC2 support in Nova. Because I'm
> pretty sure what we have today actually only works if you are using boto
> on the client side, and doesn't really look like EC2 at any real level
> of inspection.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>



Regards,
Rushi Agrawal
Cloud engineer,
Reliance Jio Infocomm, India
Ph: (+91) 99 4518 4519
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140425/ee6c2880/attachment.html>