fuel-dev team mailing list archive

[Lukasz Oles <loles@xxxxxxxxxxxx>]

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ś