Dean, thank you for your input. > On 20 Nov 2014, at 15:43, Dean Troyer <[email protected]> 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 > <[email protected] <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
