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

Roman Prykhodchenko rprikhodchenko at mirantis.com
Thu Nov 20 15:30:57 UTC 2014

Dean, thank you for your input.

> On 20 Nov 2014, at 15:43, Dean Troyer <dtroyer at gmail.com> wrote:
> [pardon my jumping in like kibo, someone mentioned 'client' ;) ]

Now I know for sure how to summon you :)

> On Thu, Nov 20, 2014 at 3:01 AM, Vladimir Kozhukalov <vkozhukalov at mirantis.com <mailto:vkozhukalov at mirantis.com>> wrote:
> 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.  
> Neutron client also used cliff, but in a different manner than OpenStackClient; just using cliff doesn't necessarily make things work similar to other clients.

To be honest I didn’t look at internals of OpenStackClient but have some experience with Ironic client instead. Anyway, this is still a topic which need more discussion and investigation.

> 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.
> OSC's model is to put the CLI command handlers in openstackclient.<api-name>.v<major-version> and, where necessary, the REST API in openstackclient.api.<api-name>_v<major-version>.

For the versioning we’ll have to use slightly different approach due to a different versioning in Fuel, I’m afraid. However, I agree that we should follow naming conventions and practices from other OpenStack projects in order to make it easier to other folks to dive in.

> 3) Use oslo for auth stuff (Fuel uses keystone at the moment) and wherever it is suitable.
> Are you referring to the apiclient in Oslo Incubator?  I believe that has been tagged to not graduate and left as-is for now.  I would suggest using the Keystone client Session and authentication plugins if you want a stand-alone client as you will get SAML auth, and whatever else is being developed, for free. 

That sounds like a good idea.

> Alternatively you could write your client as just a library and add an OpenStackClient plugin[0] to leverage the existing CLI.  In this case, OSC handles all of the auth and session overhead, you just worry about the REST handlers.

I think this is not very reasonable because Fuel does not provide any service in OpenStack but instead allows to set up and manage OpenStack clusters.

> dt
> [0] https://github.com/dtroyer/python-oscplugin <https://github.com/dtroyer/python-oscplugin> is the original template, https://git.openstack.org/cgit/stackforge/python-congressclient/ <https://git.openstack.org/cgit/stackforge/python-congressclient/> is a current example of a lib+plugin repo.
> -- 
> Dean Troyer
> dtroyer at gmail.com <mailto:dtroyer at gmail.com>
> _______________________________________________
> 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/20141120/b461717d/attachment.html>

More information about the OpenStack-dev mailing list