Open Stack

On 6/8/2017 10:17 AM, Arne Wiebalck wrote:
> 
>> On 08 Jun 2017, at 15:58, Matt Riedemann <mriedemos at gmail.com 
>> <mailto:mriedemos at gmail.com>> wrote:
>>
>> Nova stores the output of the Cinder os-initialize_connection info API 
>> in the Nova block_device_mappings table, and uses that later for 
>> making volume connections.
>>
>> This data can get out of whack or need to be refreshed, like if your 
>> ceph server IP changes, or you need to recycle some secret uuid for 
>> your ceph cluster.
>>
>> I think the only ways to do this on the nova side today are via volume 
>> detach/re-attach, reboot, migrations, etc - all of which, except live 
>> migration, are disruptive to the running guest.
>>
>> I've kicked around the idea of adding some sort of admin API interface 
>> for refreshing the BDM.connection_info on-demand if needed by an 
>> operator. Does anyone see value in this? Are operators doing stuff 
>> like this already, but maybe via direct DB updates?
>>
>> We could have something in the compute API which calls down to the 
>> compute for an instance and has it refresh the connection_info from 
>> Cinder and updates the BDM table in the nova DB. It could be an admin 
>> action API, or part of the os-server-external-events API, like what we 
>> have for the 'network-changed' event sent from Neutron which nova uses 
>> to refresh the network info cache.
>>
>> Other ideas or feedback here?
> 
> I have opened https://bugs.launchpad.net/cinder/+bug/1452641 for this 
> issue some time ago.
> Back then I was more thinking of using an alias and not deal with IP 
> addresses directly. From
> what I understand, this should work with Ceph. In any case, there is 
> still interest in a fix :-)
> 
> Cheers,
>   Arne
> 
> 
> --
> Arne Wiebalck
> CERN IT
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Yeah this was also discussed in the dev mailing list over a year ago:

http://lists.openstack.org/pipermail/openstack-dev/2016-May/095170.html

At that time I was opposed to a REST API for a *user* doing this, but 
I'm more open to an *admin* (by default) doing this. Also, if it were 
initiated via the volume API then Cinder could call the Nova 
os-server-external-events API which is admin-only by default and then 
Nova can do a refresh.

Later in that thread Melanie Witt also has an idea about doing a refresh 
in a periodic task on the compute service, like we do for refreshing the 
instance network info cache with Neutron in a periodic task.

-- 

Thanks,

Matt