<div dir="ltr">Ilya,<div>would that be possible to contribute your changes back to our upstream client? We are willing it to be evolved in this exact direction, though we never had enough resources for it. We will be happy to review and accept your requests.</div><div>It should be easier for you too - instead of maintaining the fork, you will simply use upstream version.</div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 5:52 PM, Ilya Kharin <span dir="ltr"><<a href="mailto:ikharin@mirantis.com" target="_blank">ikharin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">







<p>Hi guys,</p><p>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>- 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>- 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>In my team we are thinking about our own implementation of the client as a solution.</p><p>Best regards,<br>
Ilya</p><div><div class="h5"><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><div><br>
On Mon, Oct 6, 2014 at 4:49 PM, Lukasz Oles <<a href="mailto:loles@mirantis.com" target="_blank">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" target="_blank">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" target="_blank">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></div></div>
<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></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</div>