Open Stack

Hello all,

On 16/02/2021 22:32, Christian Rohmann wrote:
>
> I have just been trying to reproduce the issue, but in all my new 
> attempts it just worked as expected:
>
>> [162262.926512] sd 0:0:0:1: Capacity data has changed
>> [162262.932868] sd 0:0:0:1: [sdb] 6291456 512-byte logical blocks: 
>> (3.22 GB/3.00 GiB)
>> [162262.933061] sdb: detected capacity change from 2147483648 to 
>> 3221225472

On 17/02/2021 09:43, Tobias Urdin wrote:
>
> Regarding the actual extending of in-use volumes, we had an issue 
> where cinder could not talk to os-server-external-events endpoint for 
> nova because it used the wrong endpoint when looking up in keystone. 
> We saw the error in cinder-volume.log except for that I can't remember 
> we did anything special.
>
>
> Had to use newer microversion for cinder when using CLI.
> cinder --os-volume-api-version 3.42 extend <volume ID or name> <new 
> size in GB>
>


I am very sorry for the delay, but I was now finally able to reproduce 
the issue and with a VERY strange finding:


1)

* When using the cinder client with a Volume API version >= 3.42  like 
you suggested Tobias, it works just fine using cloud admin credentials.
* The volume is attached / in-use, but it is resized just fine, 
including the notification of the kernel on the VM.


2)

* When attempting the same thing using the project users credentials the 
resize also works just fine, volume still attached and in-use, but then 
the VM is NOT notified
* Also this does not seems to be related to nova or QEMU, but rather it 
appears there is no extend_volume event triggered or at least logged:


--- cut ---
Request ID  -- Action -- Start Time -- User ID -- Message

req-a4065b2d-1b77-4c5a-bf53-a2967b574fa0     extend_volume May 5, 2021, 
1:22 p.m.     784bd2a5b82c3b31eb56ee     -
req-5965910b-874f-4c7a-ab61-32d1a080d1b2     attach_volume     
May 5, 
2021, 1:09 p.m.     4b2abc14e511a7c0b10c     -
req-75ef5bd3-75d3-4146-84eb-1809789b6586     Create     May 5, 2021, 
1:09 p.m.     4b2abc14e511a7c0b10c     -
--- cut ---

UserID "784bd2a5b82c3b31eb56ee" is the regular user creating and 
attaching the volume. But that user also did an extend_volume, which is 
not logged as an event.
There also was no API errors reported back to the client, the resize did 
happen - just not propagated to the VM - so a stop and restart was required.

But the admin user with id "4b2abc14e511a7c0b10c" doing a resize attempt 
caused an extend_volume and consequently did trigger a notification of 
the VM,
just as expected and documented in regards to this feature.



Does anybody have any idea what could cause this or where to look for 
more details?
Regards


Christian