Open Stack

Mike,

I never mentioned us having any fork. What I said is that fuelclient is not
currently usable as a library and that is why we are more inclined to write
our own client that solves the limited scope of our problems.

On Mon, Oct 13, 2014 at 11:53 AM, Mike Scherbakov <mscherbakov at mirantis.com>
wrote:

> Ilya,
> 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.
> It should be easier for you too - instead of maintaining the fork, you
> will simply use upstream version.
>
> Thanks,
>
> On Fri, Oct 10, 2014 at 5:52 PM, Ilya Kharin <ikharin at mirantis.com> wrote:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Mike Scherbakov
> #mihgen
>
>
> _______________________________________________
> 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/20141014/9f254304/attachment.html>