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 <mscherba...@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 <ikha...@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 <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 >> >> > > > -- > Mike Scherbakov > #mihgen > > > _______________________________________________ > 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
