1.[Apache libcloud](https://libcloud.apache.org/index.html) vagy [OpenStack SDK](https://docs.openstack.org/openstacksdk/rocky/)
\ No newline at end of file
### Kommunikáció módja az Cloud Managerrel (esetünkben OpenStack): [Apache libcloud](https://libcloud.apache.org/index.html) vagy [OpenStack SDK](https://docs.openstack.org/openstacksdk/rocky/)
__Apache libcloud__
* + Több Cloud Manager-el is jól működik
* +- Valószínüleg jól működik OpenStack-el
* - Nem biztos, hogy minden OpS művelet szerepel benne úgy ahogy nekünk kell
__OpenStack SDK__
* + Jól működik Openstack-el
* +- Máshol kell meghúzni a határokat a reuseability szempontjából
__Döntés__
Az OpenStack SDK mellett döntöttünk, mert így a Cloud Manager függő kódot egy magasabb szinten különíthetjük el az általánostól.
### Kommunikáció módja a klienssel: REST vagy MQ
__REST__
* + Viszonylag egyszerű
* + Bizonyos műveletek nehezen kezelhetőek
* - 2 irányú kommunikáció nehézkes
__MQ__
* + 2 irányú kommunikációra jó
* - Nehézkes és bonyolult
__Döntés__
A REST mellett döntöttünk. Mind a *portal* mind az *interface* publikál egy REST API-t. Ez egyszerűen megvalósítható. Jó kiindulási pont.
### Authentikáció, authorizáció
Az authentikációra az OpenStack tartalmaz egy modult a Keystone-t. Ez egy jól specifikált és implementált modul, ám a céljainknak nem felel meg tökéletetes.
Problémák:
* Használatával megsértenénk azt a követelményt, hogy több Cloud Manager-t is támogasson a rendszer.
* Nem minden művelet végezhető el benne a jogosultságokkal kapcsolatban úgy, ahogy a mi üzleti logikánkban szerepel. (Szabolcsnál felmerült: nehéz a CIRCLE user-ek mappelése a keystone-os user fogalomhoz )
