fuel-dev team mailing list archive

[Lukasz Oles <loles@xxxxxxxxxxxx>]

done

On Mon, Oct 6, 2014 at 3:31 PM, Mike Scherbakov
<mscherbakov@xxxxxxxxxxxx> wrote:
> Hi Lukasz,
> I'm not sure if anyone from Rally is subscribed to fuel-dev. I suggest to
> discuss this (and any other Fuel development related questions) in
> openstack-dev.
> For this topic, you could use [Fuel] [Rally] in subject to attract
> developers from both Fuel & Rally projects.
> Can you resend it there?
>
> Thanks,
>
> On Mon, Oct 6, 2014 at 5:28 PM, Lukasz Oles <loles@xxxxxxxxxxxx> wrote:
>>
>> 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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> Mike Scherbakov
> #mihgen
>



-- 
Łukasz Oleś