a ceph-es volumeok titkositasara OpenStack alatt varhatsz meg ~2 evet

koszond meg a redhatnak (pacsi Adi), mert egy 70 soros patch faj nekik.

a user base 60+%-a cephet hasznal volume storagenak, de hat kit erdekelnek a juzerek...

( Huncraft v | 2015. 11. 28., szo – 23:06 )

Most nem tudom.. Egy részről értem a te érvelésed is, hogy ha van elérhető funkció, akkor miért ne használja az ember, már ha viszonylag kevés módosítással járna. Más részről azt is meg tudom érteni, hogy nem akarnak mindenféle plusz függőséget belevinni a rendszerbe, hanem inkább standardizálni amit lehet (speciel más témák miatt hasonló vitáim nekem is gyakran vannak, szóval meg tudom érteni a fejlesztők ez irányú törekvéseit).
Persze lehet azt mondani, hogy használjuk ezt amíg a másik nem elérhető normálisan, de az esetek többségében az ilyen jellegű törekvések végérvényesen a kódban szoktak maradni, mert "ha működik, ne nyúlj hozzá".
Más részről felmerül az is, hogy ez mekkora igény ténylegesen is. Mert ha szerinted tényleg sok embernek kéne ez, akkor paterold össze ezeket az embereket, és támadjátok le a fejlesztőket, hogy erre igen is szükségetek van, ott a patch is, meg az igény is mögötte.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nem teljesen feleslegesen, az eddig ujra irt cuccok gyorsabbak mintha nem qemu hivna kovzvetlenul.
Ami legikabb viccess, hogy glusterfs -nel ephemeral storagenel a nova nem hasznalja, csak cinder/block storagenel.

Van egy masik cinder driver patch ami nem lett mergelve papir munka miatt,
https://review.openstack.org/#/c/134134/ ez 17 sor, a cinder resze mar reg megvan.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( uid_228 | 2015. 11. 29., v – 14:55 )

Kíváncsiságból kattintottam ide be és erre látom, hogy megszólítasz. :)

Nem igazán követem az OpenStack fejlődését (ez finom kifejezés volt, mi még mindig VMware-rel szopatjuk magunkat, a részvényesek nagy örömére :)), jól értem, hogy arról van szó, hogy a block device titkosítás jelenleg a guestben zajlik, nem a hypervisor kernelében?

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

a VMware szerintem nagyon kiraly, ha lenne hozza rendes self-provisioning (es most nem a vCAC/vCD vackokrol beszelek, amik a 90-es evekhez kepest is gagyik), azt hasznalnam, tekintve hogy a licenszek szinte semmibe nem kerulnek nekunk.

jelenleg nincs semmilyen titkositas ceph-es volumeokhoz (semmilyen, a teszteket ki kellett kapcsolni a ceph-es CI/CD rendszerben, mert elhasalt az egesz resz!), o szerintuk majd jol lefejlesztik qemu-ba kb fel-egy ev alatt, es akkor az majd jo lesz, szerintem pedig a hypervisoron kene csinalni, ahol ugye a kernel resze mar a dm-crypt eleg reg.

Értem, köszi. Nem tudok állást foglalni a dologban, mert nem foglalkoztam ilyennel sose. Teljesítmény szempontjából nekem is az tűnik jobbnak, ha ezt a host kernele csinálja, de lehet, hogy menedzsment szempontjából ez bonyolultabbá teszi.

Egy előnye biztosan van, annak, ha a hypervisor felel a titkosításért: a workload megosztható jobban a guest-host között. A guest CPU-knak több ideje marad így az alkalmazásra. Persze magok átcsoportosításával lehet ezzel is variálni.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”