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


OpenStack-dev mailing list

Reply via email to