OpenStack Compute (nova)

Volume Code cleanup

Registered by Vish Ishaya

Volume code needs to be cleaned up to ease integration with other schedulers and backends.

The following steps are necessary:

1. Remove aoe (no one is using it)
2. Store ip addresses for iscsi targets instead of discovering
3. Change discover volume to prepare_attach, sending in ip that will attach to volume
4. Return credentials from prepare (CHAP credentials to begin with)
5. Similar change to undiscover volume

Blueprint information

Status:
Complete
Approver:
Vish Ishaya
Priority:
Medium
Drafter:
Vish Ishaya
Direction:
Needs approval
Assignee:
Piston Cloud Computing
Definition:
Approved
Series goal:
Accepted for essex
Implementation:
Implemented
Milestone target:
milestone icon 2012.1
Started by
Thierry Carrez
Completed by
Thierry Carrez

Sprints

Whiteboard

I'm all for removing code, but are we sure nobody is using AoE? I've used AoE storage in the past (never in Nova) and I prefer it to iSCSI in certain situations. Why does the code need to be removed? Does it not work or is it just rotting?

Vish,

Sorry for the delay. I have taken a look at the volume-cleanup code and II still think the call to “initialize_connection” is not in the right place if we want to have the ability to police the attachment of volumes outside of the compute node.

My reading of the code flow is as follows:

Server: API
nova/api/openstack/contrib/volumes.py:
                Create volume attachment:
                Calls compute_api.attach_volume

Server: API
nova/compute/api.py:
                attach_volume:
                calls volume_api.check_attach(context, volume_id=volume_id)
                this is a DB check of the volume status

                RPC cast to compute host to attach_volume method

Server: Compute
nova/compute/manager.py:
                attach_volume:
                calls volume_api.initialize_connection

Server: Compute
nova/volume/api.py:
                initialize_connection
                RPC cast to volume manager to driver specific initialization

I think this call is too late in the sequence. In addition it is the kind of thing we don’t want the Compute server to be able to do.
If we called this on the API server after the call to check attach and before the RPC cast the compute host, then we could perform this function on a “trusted” API node. It would mean that we would need to pass the driver specific connection_info on in the RPC cast, but I think this si doable,

Tim

(?)

Work Items

Nearby

This blueprint contains Public information 
Everyone can see this information.