Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141013/47db0a3f/attachment.html>