Hi Lukasz,

I have the same thoughts - we have to design a good Python library for
dealing with Nailgun and this library has to be used by:

* Fuel CLI
* System Tests
* Fuel Upgrade
* other scripts

But it's a big deal and we definetely should have a separate blueprint
for this task. Moreover, we have to carefully consider its
architecture to be convenient not only for CLI usage.


On Mon, Oct 6, 2014 at 4:49 PM, Lukasz Oles <lo...@mirantis.com> 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ś
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to