Yes i think you are disabling the stuff in the wrong place. You want to disable osapi_volume on serverA (where nova-api is running) You then want to restart nova-api and start cinder-api on serverA. ServerB sounds like just a compute/volume node so it doesn't sound like it should be running the api services at all.
If you are running nova-api for metadata, you can use the same process of disabling osapi_volume but you don't need to start cinder-api on ServerB. (Alternatively, just run nova-api-metadata instead of the full nova-api) Vish On Oct 22, 2012, at 12:06 PM, Jonathan Proulx <j...@csail.mit.edu> wrote: > Hi All, > > I'm trying to get from nova-volume to cinder and seem to be tripping > up near the end. > > I have ServerA running as the cloud controller (horizon, keystone, glance, > rabbitmq, mysql, nova-api, etc...), ServerB was running nova-volume > and is now running cinder. I got the DB created (on ServerA) and > pupulated with cinder-manage migrate bits in the release notes. > > I disabled osapi_volume on ServerB, restarted nova-api and then > cinder-api as directed. > > But api request still seem to be trying (and failing) to use the > nova-volume service, as seen by updates to the nova.volumes table when > trying to create or attach volumes through Horizon or booting from > volume with the python-novaclient. > > What piece of plubing am I missing? Seem like the controller should be > running cinder-api too (but not cinder volume)? > > -Jon > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp