<div dir="ltr">







<p class="">Hi guys,</p><p class="">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:</p><p class="">- 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).</p><p class="">- 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.</p><p class="">In my team we are thinking about our own implementation of the client as a solution.</p><p class="">Best regards,<br>
Ilya</p><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 6, 2014 at 6:09 PM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Lukasz,<br>
<br>
I have the same thoughts - we have to design a good Python library for<br>
dealing with Nailgun and this library has to be used by:<br>
<br>
* Fuel CLI<br>
* System Tests<br>
* Fuel Upgrade<br>
* OSTF<br>
* other scripts<br>
<br>
But it's a big deal and we definetely should have a separate blueprint<br>
for this task. Moreover, we have to carefully consider its<br>
architecture to be convenient not only for CLI usage.<br>
<br>
Thanks,<br>
Igor<br>
<div class=""><div class="h5"><br>
On Mon, Oct 6, 2014 at 4:49 PM, Lukasz Oles <<a href="mailto:loles@mirantis.com">loles@mirantis.com</a>> wrote:<br>
> Hello all,<br>
><br>
> I'm researching if we can use Rally project for some Fuel testing.<br>
> It's part of 100-nodes blueprint[1].<br>
> To write some Rally scenario I used our Fuelclient "library".<br>
> In it's current state it's really painful to use and it's not usable<br>
> as production tool.<br>
><br>
> Here is the list of the biggest issues:<br>
><br>
> 1. If API returns code other than 20x it exits. Literally it calls<br>
> sys.exit(). It should just rise Exception.<br>
> 2. Using API Client as a Singleton. In theory we can have more than<br>
> one connection, but all new objects will use default connection.<br>
> 3. Can not use  keystone token. It requires user and password.<br>
>  Server address and all credentials can be given via config file or<br>
> environment variables. There is no way to set it during client<br>
> initialization.<br>
><br>
> All this issues show that library was designed only with CLI in mind.<br>
> Especially issue nr 1.<br>
> Now I know why ostf doesn't use fuelcient, why Rally wrote their own<br>
> client. And I can bet that MOX team is also using their own version.<br>
><br>
> I'm aware of Fuelclient refactoring blueprint[1] I reviewed it and<br>
> gave +1 to most of the reviews. Unfortunately it focuses on CLI usage.<br>
> Move to Cliff is very good idea,<br>
> but for library it actually makes things worse [2] like moving data<br>
> validation to CLI or initializing object using single dictionary<br>
> instead of normal arguments.<br>
><br>
> I think instead of focusing on CLI usage we should focus on a library<br>
> part. To make it easier to use by other programs. After that we can<br>
> focus on CLI. It's very important now when we are planning to support<br>
> 100 nodes and more in future because more and more users will start<br>
> use Fuel via API instead of UI.<br>
><br>
> What do you think about this?<br>
><br>
> Regards,<br>
><br>
> [1] <a href="https://blueprints.launchpad.net/fuel/+spec/refactoring-for-fuelclient" target="_blank">https://blueprints.launchpad.net/fuel/+spec/refactoring-for-fuelclient</a><br>
> [2] <a href="https://review.openstack.org/#/c/117294/" target="_blank">https://review.openstack.org/#/c/117294/</a><br>
><br>
><br>
><br>
><br>
> Regards,<br>
><br>
> --<br>
> Łukasz Oleś<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>