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 <ikalnit...@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 <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 > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev