[openstack-dev] [FUEL]Re-thinking Fuel Client

Juan Antonio Osorio jaosorior at gmail.com
Thu Nov 20 10:21:32 UTC 2014


Hi,

As a Fuel user I would like to give some input.

0) This would make fuel adhere to the standards for clients, I agree with
this change.
1) cliff is not really necessary, but is actually being adopted by some
other projects (other than OpenStack unified client) I initially proposed
it for barbican and implemented it, so if it helps, I could do the same
work here. If other people are interested in this I could submit a
blueprint.
3) What's the benefit of using oslo auth? I'm not very familiar with it;
I'm actually more familiar with other projects using keystone.

On Thu, Nov 20, 2014 at 11:01 AM, Vladimir Kozhukalov <
vkozhukalov at mirantis.com> wrote:

> Roman,
>
> I am absolutely +1 for re-designing fuel client and bringing it out of
> fuel-web repo.
>
> If you ask me, it is also important to make new design following kind of
> standard just to avoid re-re-designing it in the foreseeable future. Some
> points here are:
> 0) Rename fuelclient into python-fuelclient like any other OpenStack
> clients when moving it to a separate repo.
> 1) Use cliff as a cli library. AFAIU it is a kind of unofficial standard
> for OpenStack clients for future. At least python-openstackclient uses
> cliff. Correct me if I am wrong.
> 2) Follow common OpenStack practice for naming files and directories in a
> project (shell.py, api, object, etc). I am not sure whether such a common
> practice exists, but we again can follow python-openstackclient naming
> model.
> 3) Use oslo for auth stuff (Fuel uses keystone at the moment) and wherever
> it is suitable.
>
>
>
>
>
> Vladimir Kozhukalov
>
> On Mon, Nov 17, 2014 at 8:08 PM, Roman Prykhodchenko <
> rprikhodchenko at mirantis.com> wrote:
>
>> Hi folks!
>>
>> I’ve made several internal discussions with Łukasz Oleś and Igor
>> Kalnitsky and decided that the existing Fuel Client has to be redesigned.
>> The implementation of the client we have at the moment does not seem to
>> be compliant with most of the use cases people have in production and
>> cannot be used as a library-wrapper for FUEL’s API.
>>
>> We’ve came of with a draft of our plan about redesigning Fuel Client
>> which you can see here:
>> https://etherpad.openstack.org/p/fuelclient-redesign
>> Everyone is welcome to add their notes, suggestions basing on their needs
>> and use cases.
>>
>> The next step is to create a detailed spec and put it to everyone’s
>> review.
>>
>>
>>
>> - romcheg
>>
>>
>> _______________________________________________
>> 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
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosorior at gmail.com

"All truly great thoughts are conceived by walking."
- F.N.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141120/d0faaa1d/attachment.html>


More information about the OpenStack-dev mailing list