Re: [openstack-dev] [Solum] Command Line Interface for Solum
I have updated the blueprint for this feature, and approved the direction for the v0.1 milestone: https://blueprints.launchpad.net/solum/+spec/command-line The specification for the CLI is not intended to be complete at this stage. It only specified what I expect we will need for v0.1. Additional commands can be added as we add support for additional features in subsequent releases. Adrian On Nov 15, 2013, at 12:00 PM, Doug Hellmann doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote: On Thu, Nov 14, 2013 at 2:28 AM, Adrian Otto adrian.o...@rackspace.commailto:adrian.o...@rackspace.com wrote: Doug, On Nov 13, 2013, at 9:28 AM, Doug Hellmann doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote: On Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M noo...@noorul.commailto:noo...@noorul.com wrote: Hello all, I registered a new blueprint [1] for command line client interface for Solum. We need to decide whether we should have a separate repository for this or go with new unified CLI framework [2]. Since Solum is not part of OpenStack I think it is not the right time to go with the unified CLI. One of the key features of the cliff framework used for the unified command line app is that the subcommands can be installed independently of the main program. So you can write plugins that work with the openstack client, but put them in the solum client library package (and source repository). That would let you, for example: $ pip install python-solumclient $ pip install python-openstackclient $ openstack solum make me a paas Dean has done a lot of work to design a consistent noun-followed-by-verb command structure, so please look at that work when picking subcommand names (for example, you shouldn't use solum as a prefix as I did in my example above, since we are removing the project names from the commands). Are you referring to openstack solum … in your suggestion of what not to do? If there is no project name in there, how would it work? Would we have a flat global namespace for all verbs? I could imagine the following verb/noun combinations off the bat: deploy app list assemblies list plans list services get assembly assembly_name|uri get plan plan_name|uri get service service_name|uri scale assembly assembly_name|uri (+|-n) resize du assembly_name|uri start assembly stop assembly delete assembly delete app What about using combined noun+verb combinations, so you would end up with commands like: deploy_app …etc. That might be more specific and require less processing logic. There is a namespace for the nouns, and each noun has a namespace with verbs. So you might say openstack app deploy, openstack assembly show, etc. Placing the noun first lets us use tab completion to help the user figure out what options they have (openstack assembly tab would show scale, resize, start, and stop as completion options). As far as processing logic, that's all handled by the framework already. The commands are registered as multi-word names pointing to a single class, and cliff figures out which one to run based on the input command line. Doug Thanks, Adrian Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [Solum] Command Line Interface for Solum
On Thu, Nov 14, 2013 at 2:28 AM, Adrian Otto adrian.o...@rackspace.comwrote: Doug, On Nov 13, 2013, at 9:28 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M noo...@noorul.comwrote: Hello all, I registered a new blueprint [1] for command line client interface for Solum. We need to decide whether we should have a separate repository for this or go with new unified CLI framework [2]. Since Solum is not part of OpenStack I think it is not the right time to go with the unified CLI. One of the key features of the cliff framework used for the unified command line app is that the subcommands can be installed independently of the main program. So you can write plugins that work with the openstack client, but put them in the solum client library package (and source repository). That would let you, for example: $ pip install python-solumclient $ pip install python-openstackclient $ openstack solum make me a paas Dean has done a lot of work to design a consistent noun-followed-by-verb command structure, so please look at that work when picking subcommand names (for example, you shouldn't use solum as a prefix as I did in my example above, since we are removing the project names from the commands). Are you referring to openstack solum … in your suggestion of what not to do? If there is no project name in there, how would it work? Would we have a flat global namespace for all verbs? I could imagine the following verb/noun combinations off the bat: deploy app list assemblies list plans list services get assembly assembly_name|uri get plan plan_name|uri get service service_name|uri scale assembly assembly_name|uri (+|-n) resize du assembly_name|uri start assembly stop assembly delete assembly delete app What about using combined noun+verb combinations, so you would end up with commands like: deploy_app …etc. That might be more specific and require less processing logic. There is a namespace for the nouns, and each noun has a namespace with verbs. So you might say openstack app deploy, openstack assembly show, etc. Placing the noun first lets us use tab completion to help the user figure out what options they have (openstack assembly tab would show scale, resize, start, and stop as completion options). As far as processing logic, that's all handled by the framework already. The commands are registered as multi-word names pointing to a single class, and cliff figures out which one to run based on the input command line. Doug Thanks, Adrian Doug ___ 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
Re: [openstack-dev] [Solum] Command Line Interface for Solum
On Nov 14, 2013 1:10 PM, Adrian Otto adrian.o...@rackspace.com wrote: Noorul, On Nov 13, 2013, at 7:43 PM, Noorul Islam K M noo...@noorul.com wrote: Doug Hellmann doug.hellm...@dreamhost.com writes: On Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M noo...@noorul.com wrote: Hello all, I registered a new blueprint [1] for command line client interface for Solum. We need to decide whether we should have a separate repository for this or go with new unified CLI framework [2]. Since Solum is not part of OpenStack I think it is not the right time to go with the unified CLI. One of the key features of the cliff framework used for the unified command line app is that the subcommands can be installed independently of the main program. So you can write plugins that work with the openstack client, but put them in the solum client library package (and source repository). That would let you, for example: $ pip install python-solumclient $ pip install python-openstackclient $ openstack solum make me a paas Dean has done a lot of work to design a consistent noun-followed-by-verb command structure, so please look at that work when picking subcommand names (for example, you shouldn't use solum as a prefix as I did in my example above, since we are removing the project names from the commands). I think we should follow this. If others have no objection, I will submit a review to openstack-infra/config to create a new repository named python-solumclient with intial code from cookiecutter template. Adrian, Does this blue-print require to be in Approved state to perform above task? Thanks for the enthusiasm! I'd like further input from additional team members before advancing on this. I think whichever path we take a separate repository is required. Regards, Noorul ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Command Line Interface for Solum
Angus Salkeld asalk...@redhat.com writes: On 14/11/13 13:32 +0530, Noorul Islam Kamal Malmiyoda wrote: On Nov 14, 2013 1:10 PM, Adrian Otto adrian.o...@rackspace.com wrote: Noorul, On Nov 13, 2013, at 7:43 PM, Noorul Islam K M noo...@noorul.com wrote: Doug Hellmann doug.hellm...@dreamhost.com writes: On Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M noo...@noorul.com wrote: Hello all, I registered a new blueprint [1] for command line client interface for Solum. We need to decide whether we should have a separate repository for this or go with new unified CLI framework [2]. Since Solum is not part of OpenStack I think it is not the right time to go with the unified CLI. One of the key features of the cliff framework used for the unified command line app is that the subcommands can be installed independently of the main program. So you can write plugins that work with the openstack client, but put them in the solum client library package (and source repository). That would let you, for example: $ pip install python-solumclient $ pip install python-openstackclient $ openstack solum make me a paas Dean has done a lot of work to design a consistent noun-followed-by-verb command structure, so please look at that work when picking subcommand names (for example, you shouldn't use solum as a prefix as I did in my example above, since we are removing the project names from the commands). I think we should follow this. If others have no objection, I will submit a review to openstack-infra/config to create a new repository named python-solumclient with intial code from cookiecutter template. Adrian, Does this blue-print require to be in Approved state to perform above task? Thanks for the enthusiasm! I'd like further input from additional team members before advancing on this. I think whichever path we take a separate repository is required. Yip, no harm making the new repo IMO. Here [1] it is. Regards, Noorul [1] https://review.openstack.org/#/c/56505/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Command Line Interface for Solum
On Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M noo...@noorul.comwrote: Hello all, I registered a new blueprint [1] for command line client interface for Solum. We need to decide whether we should have a separate repository for this or go with new unified CLI framework [2]. Since Solum is not part of OpenStack I think it is not the right time to go with the unified CLI. One of the key features of the cliff framework used for the unified command line app is that the subcommands can be installed independently of the main program. So you can write plugins that work with the openstack client, but put them in the solum client library package (and source repository). That would let you, for example: $ pip install python-solumclient $ pip install python-openstackclient $ openstack solum make me a paas Dean has done a lot of work to design a consistent noun-followed-by-verb command structure, so please look at that work when picking subcommand names (for example, you shouldn't use solum as a prefix as I did in my example above, since we are removing the project names from the commands). Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Command Line Interface for Solum
Doug, On Nov 13, 2013, at 9:28 AM, Doug Hellmann doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote: On Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M noo...@noorul.commailto:noo...@noorul.com wrote: Hello all, I registered a new blueprint [1] for command line client interface for Solum. We need to decide whether we should have a separate repository for this or go with new unified CLI framework [2]. Since Solum is not part of OpenStack I think it is not the right time to go with the unified CLI. One of the key features of the cliff framework used for the unified command line app is that the subcommands can be installed independently of the main program. So you can write plugins that work with the openstack client, but put them in the solum client library package (and source repository). That would let you, for example: $ pip install python-solumclient $ pip install python-openstackclient $ openstack solum make me a paas Dean has done a lot of work to design a consistent noun-followed-by-verb command structure, so please look at that work when picking subcommand names (for example, you shouldn't use solum as a prefix as I did in my example above, since we are removing the project names from the commands). Are you referring to openstack solum … in your suggestion of what not to do? If there is no project name in there, how would it work? Would we have a flat global namespace for all verbs? I could imagine the following verb/noun combinations off the bat: deploy app list assemblies list plans list services get assembly assembly_name|uri get plan plan_name|uri get service service_name|uri scale assembly assembly_name|uri (+|-n) resize du assembly_name|uri start assembly stop assembly delete assembly delete app What about using combined noun+verb combinations, so you would end up with commands like: deploy_app …etc. That might be more specific and require less processing logic. Thanks, Adrian Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [Solum] Command Line Interface for Solum
On Mon, Nov 11, 2013 at 12:01 AM, Clayton Coleman ccole...@redhat.comwrote: The implication I heard from the session is the command infrastructure and client code have or will have a well defined interface from the framework, although I haven't looked through current state enough to say that's totally true today. If that interface is in place we certainly would be better isolated from upstream. OSC has a very simple plugin mechanism that is little more than pre-defined entry point groups that are scanned for additional commands. That works but doesn't properly leverage the desirable common bits, such as auth, that are available to the built-in clients. Enhancing this has not been a high priority before now but needs to be done. I guess it depends where we want to spend our focus as well - do we write something that in the long run we'd end up porting, or benefit from the work the common client is doing (doc, common patterns, keystone auth work with x509 and potentially Kerberos, bash completion, etc) as well as help them out. I'd suggest you focus on putting together a clean and well-defined library API that implements your REST API. Consider that work is going on to refactor the implementation of these layers in existing clients and that some of the library APIs will be changing. Specifically, the first of these efforts is a much-needed cleanup of the Identity Auth interfaces and the migration of existing clients to use that rather than their own embedded auth. Please don't just copy one of the existing clients, down that path lies madness. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Command Line Interface for Solum
On Nov 11, 2013, at 2:53 PM, Dean Troyer dtro...@gmail.com wrote: On Mon, Nov 11, 2013 at 12:01 AM, Clayton Coleman ccole...@redhat.com wrote: The implication I heard from the session is the command infrastructure and client code have or will have a well defined interface from the framework, although I haven't looked through current state enough to say that's totally true today. If that interface is in place we certainly would be better isolated from upstream. OSC has a very simple plugin mechanism that is little more than pre-defined entry point groups that are scanned for additional commands. That works but doesn't properly leverage the desirable common bits, such as auth, that are available to the built-in clients. Enhancing this has not been a high priority before now but needs to be done. I guess it depends where we want to spend our focus as well - do we write something that in the long run we'd end up porting, or benefit from the work the common client is doing (doc, common patterns, keystone auth work with x509 and potentially Kerberos, bash completion, etc) as well as help them out. I'd suggest you focus on putting together a clean and well-defined library API that implements your REST API. Consider that work is going on to refactor the implementation of these layers in existing clients and that some of the library APIs will be changing. Specifically, the first of these efforts is a much-needed cleanup of the Identity Auth interfaces and the migration of existing clients to use that rather than their own embedded auth. Please don't just copy one of the existing clients, down that path lies madness. I know in the session a generic API client lib was mentioned, is that in a branch somewhere to highlight the things that were common across a lot of API libs? Or knowing your opinion of the best client to copy. :) dt -- Dean Troyer dtro...@gmail.com ___ 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
Re: [openstack-dev] [Solum] Command Line Interface for Solum
On 11/10/2013 10:15 AM, Noorul Islam K M wrote: Hello all, I registered a new blueprint [1] for command line client interface for Solum. We need to decide whether we should have a separate repository for this or go with new unified CLI framework [2]. Since Solum is not part of OpenStack I think it is not the right time to go with the unified CLI. I think a separate repository (python-solumclient) is appropriate. There are two main camps of client tool programming: using the cliff library [1] and using the framework that was originally used for the Rackspace Cloud Servers CLI tool and library. Example of the cliff style is python-neutronclient [2]. Example of the other style is the current python-novaclient [3]. I actually would love to see the Solum client take the best of both of the styles and create a client library that uses the cliff library for the underlying CLI plumbing and use the object-oriented style of python-novaclient that returns Resource objects instead of raw dicts like python-neutronclient does... Best, -jay [1] https://cliff.readthedocs.org/en/latest/ [2] https://github.com/openstack/python-neutronclient [3] https://github.com/openstack/python-novaclient ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Command Line Interface for Solum
On Nov 10, 2013, at 3:47 PM, Paul Belanger paul.belan...@polybeacon.com wrote: On 13-11-10 12:36 PM, Jay Pipes wrote: On 11/10/2013 10:15 AM, Noorul Islam K M wrote: Hello all, I registered a new blueprint [1] for command line client interface for Solum. We need to decide whether we should have a separate repository for this or go with new unified CLI framework [2]. Since Solum is not part of OpenStack I think it is not the right time to go with the unified CLI. I think a separate repository (python-solumclient) is appropriate. There are two main camps of client tool programming: using the cliff library [1] and using the framework that was originally used for the Rackspace Cloud Servers CLI tool and library. Example of the cliff style is python-neutronclient [2]. Example of the other style is the current python-novaclient [3]. I actually would love to see the Solum client take the best of both of the styles and create a client library that uses the cliff library for the underlying CLI plumbing and use the object-oriented style of python-novaclient that returns Resource objects instead of raw dicts like python-neutronclient does... Best, -jay [1] https://cliff.readthedocs.org/en/latest/ [2] https://github.com/openstack/python-neutronclient [3] https://github.com/openstack/python-novaclient +1 to cliff. I've used cliff a few times now for some CLI clients and it works very well. Even though it'll be a long time (maybe never) before Solum is a core project, it'd be good to track the CLI work going on in the common client [1]. The session at the design summit [2] definitely conveyed a broad agreement on this direction (ie common client is mostly inevitable), so being cognizant of the plugin pattern they have going is smart. We could potentially ship an isolated common client (ie based on that code) that used only a Solum plugin, so in the future we would have the option to switch to being integrated. [1] https://github.com/openstack/python-openstackclient [2] https://etherpad.openstack.org/p/icehouse-oslo-openstack-client-update___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Command Line Interface for Solum
Excerpts from Noorul Islam K M's message of 2013-11-10 07:15:34 -0800: Hello all, I registered a new blueprint [1] for command line client interface for Solum. We need to decide whether we should have a separate repository for this or go with new unified CLI framework [2]. Since Solum is not part of OpenStack I think it is not the right time to go with the unified CLI. Solum will not be the last project that will want to eventually be part of the openstack unified client, but must get through the governance process first. What about working out a plugin system for the openstack client? Then all of the different clients become a plugin. Projects that are just OpenStack related would need to have their plugins installed separately but would work the same whether they've been integrated or are still just related (or all the things in-between). ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Command Line Interface for Solum
On Nov 10, 2013, at 11:41 PM, Noorul Islam K M noo...@noorul.com wrote: Clayton Coleman ccole...@redhat.com writes: On Nov 10, 2013, at 3:47 PM, Paul Belanger paul.belan...@polybeacon.com wrote: On 13-11-10 12:36 PM, Jay Pipes wrote: On 11/10/2013 10:15 AM, Noorul Islam K M wrote: Hello all, I registered a new blueprint [1] for command line client interface for Solum. We need to decide whether we should have a separate repository for this or go with new unified CLI framework [2]. Since Solum is not part of OpenStack I think it is not the right time to go with the unified CLI. I think a separate repository (python-solumclient) is appropriate. There are two main camps of client tool programming: using the cliff library [1] and using the framework that was originally used for the Rackspace Cloud Servers CLI tool and library. Example of the cliff style is python-neutronclient [2]. Example of the other style is the current python-novaclient [3]. I actually would love to see the Solum client take the best of both of the styles and create a client library that uses the cliff library for the underlying CLI plumbing and use the object-oriented style of python-novaclient that returns Resource objects instead of raw dicts like python-neutronclient does... Best, -jay [1] https://cliff.readthedocs.org/en/latest/ [2] https://github.com/openstack/python-neutronclient [3] https://github.com/openstack/python-novaclient +1 to cliff. I've used cliff a few times now for some CLI clients and it works very well. Even though it'll be a long time (maybe never) before Solum is a core project, it'd be good to track the CLI work going on in the common client [1]. The session at the design summit [2] definitely conveyed a broad agreement on this direction (ie common client is mostly inevitable), so being cognizant of the plugin pattern they have going is smart. We could potentially ship an isolated common client (ie based on that code) that used only a Solum plugin, so in the future we would have the option to switch to being integrated. Isn't that going to be painful to sync changes in CLI work into this separate repository often? I think we have to keep doing that because there will be bug fixes and other enhancements. The implication I heard from the session is the command infrastructure and client code have or will have a well defined interface from the framework, although I haven't looked through current state enough to say that's totally true today. If that interface is in place we certainly would be better isolated from upstream. I guess it depends where we want to spend our focus as well - do we write something that in the long run we'd end up porting, or benefit from the work the common client is doing (doc, common patterns, keystone auth work with x509 and potentially Kerberos, bash completion, etc) as well as help them out. It might be too early to draft but if the stuff we'd get for free is more cost than staying up to date with changes, I'd say that would be a good argument to pitch in. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
