Hello all, I'm researching if we can use Rally project for some Fuel testing. It's part of 100-nodes blueprint[1]. To write some Rally scenario I used our Fuelclient "library". In it's current state it's really painful to use and it's not usable as production tool.
Here is the list of the biggest issues: 1. If API returns code other than 20x it exits. Literally it calls sys.exit(). It should just rise Exception. 2. Using API Client as a Singleton. In theory we can have more than one connection, but all new objects will use default connection. 3. Can not use keystone token. It requires user and password. Server address and all credentials can be given via config file or environment variables. There is no way to set it during client initialization. All this issues show that library was designed only with CLI in mind. Especially issue nr 1. Now I know why ostf doesn't use fuelcient, why Rally wrote their own client. And I can bet that MOX team is also using their own version. I'm aware of Fuelclient refactoring blueprint[1] I reviewed it and gave +1 to most of the reviews. Unfortunately it focuses on CLI usage. Move to Cliff is very good idea, but for library it actually makes things worse [2] like moving data validation to CLI or initializing object using single dictionary instead of normal arguments. I think instead of focusing on CLI usage we should focus on a library part. To make it easier to use by other programs. After that we can focus on CLI. It's very important now when we are planning to support 100 nodes and more in future because more and more users will start use Fuel via API instead of UI. What do you think about this? Regards, [1] https://blueprints.launchpad.net/fuel/+spec/refactoring-for-fuelclient [2] https://review.openstack.org/#/c/117294/ Regards, -- Łukasz Oleś -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp