Open Stack

On 2014-09-16 7:03 PM, Walter A. Boring IV wrote:

> The upside to brick not making it in Nova is that it has given us some
> time to rethink things a bit.  What I would actually
> like to see happen now is to create a new cinder/storage agent instead
> of just a brick library.   The agent would run on every cinder node,
> nova node and potentially ironic nodes to do LUN discovery. Duncan and I
> are looking into this for the Kilo release.
>

Thanks for reviving this idea [1] [2] [3]. I wish to say that I like it 
because months ago, we found use cases for it and wished cinder-agent 
was a thing.

One use case we have is the need to rescan an iSCSI target used by a 
Nova instance after an in-use volume has been extended in order to 
reflect its new size at the hypervisor level.

During the implementation, we quickly saw the code duplication hell that 
exists between both Nova and Cinder, all implementing iSCSI management. 
Due to the amount of work required to introduce a cinder-agent and due 
to my inexperience with OpenStack back then, we went down an other path 
instead.

We addressed our needs by introducing a Cinder->Nova interaction through 
custom code in Cinder and an API extension in Nova: Cinder triggers the 
rescan through the Nova API (instead of cinder-agent).

With cinder-agent, Cinder would be able to remotely trigger a rescan of 
the iSCSI target without relying on a custom API extension in Nova. I 
feel this implementation would be much more resilient and reduce code 
duplication in the long term.

I'm sure there is more use cases. This is mine.

[1] https://blueprints.launchpad.net/cinder/+spec/cinder-agent
[2] https://lists.launchpad.net/openstack/msg19825.html
[3] https://etherpad.openstack.org/p/cinder-agent

-- 
Mathieu