Open Stack

Hi guys,

I agree with some of the issues Lukasz mentioned. All of them require some
workaround to make it possible to use the client as a library. I can
summarize some of the problems I encountered while working with fuelclient:

- The distribution of the package is absent. The client cannot be specified
as a dependency because it is not presented on PyPI and cannot be installed
by pip (that is so for the current releases but not for the development
branch).

- The client cannot be initialized properly because it's designed as a
singleton which is initialized on the import of a module. Initialization
parameters can be specified either in a configuration file with a hardcoded
filename (which can potentially be absent on the client-side host because
of its location at /etc/fuel/client/config.yaml) or in environment
variables. These limitations force us to specify the environment variables
and then use inline imports.

In my team we are thinking about our own implementation of the client as a
solution.

Best regards,
Ilya


On Mon, Oct 6, 2014 at 6:09 PM, Igor Kalnitsky <ikalnitsky at mirantis.com>
wrote:

> 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
> * OSTF
> * 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.
>
> Thanks,
> Igor
>
> On Mon, Oct 6, 2014 at 4:49 PM, Lukasz Oles <loles at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141010/369627c1/attachment.html>