Re: [Openstack] Novatools ...
OK, let's try to summarize this long thread. there are two sides, the long-term plan and the short-term plan. For the long-term plan, there seems to be agreement on: * a set of project-oriented client tools (nova, glance...) that allow xe-like commands (nova vm-create) * a superset tool that reflects commands into the project-oriented tools (openstack compute vm-create) * support for interactive shell mode (nova show instances) * lowercase names That's for Diablo and should be further refined at the design summit. For the short term, we need some openstack-api client tool released and packaged, in particular because it is being used in the zones test, but also to start promoting the openstack API. * python-cloudservers is not under our control, so not easily extended * We have a python-novatools fork currently using novatools as the CLI tool * Sandy proposes * rename novatools CLI to nova * Add copyright headers and dual BSD/Apache licensing * Push python-novatools in nova itself under nova/clients/python/oscompute * Objections from Andy on the need to fork python-cloudservers and the perceived non-responsiveness of JKM I think we didn't discuss this part enough to make such a definitive move. I'll add a separate reply with my own remarks. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
+1 for long term plan discussion at the summit +1 for having this in the diablo release +1 for short term goal: tool being under our control via fork I don't think JKM will keep up (nothing against JKM, it's just a lot of work). On Fri, Feb 25, 2011 at 3:20 AM, Thierry Carrez thie...@openstack.orgwrote: Thierry Carrez wrote: For the short term, we need some openstack-api client tool released and packaged, in particular because it is being used in the zones test, but also to start promoting the openstack API. * python-cloudservers is not under our control, so not easily extended * We have a python-novatools fork currently using novatools as the CLI tool * Sandy proposes * rename novatools CLI to nova * Add copyright headers and dual BSD/Apache licensing * Push python-novatools in nova itself under nova/clients/python/oscompute * Objections from Andy on the need to fork python-cloudservers and the perceived non-responsiveness of JKM That's three separate issues. (1) do we need a fork, (2) last changes to python-novatools before making them packageable (rename tool and file header fixes), and (3) make it part of lp:nova or not (and where) On (1) I think we need to be able to control the code, which leaves two options: (1a) JKM gives ownership to us, renames package to something more less cloudservers-branded or (1b) Let python-cloudservers live and fork our own nova-branded tool. Since (1b) is kinda already done and given our time contraints, I tend to lean in (1b) direction. (2) must be done in all cases since that's a bit of prerequisite for proper packaging. On (2)/(3) I think we should rename the tool to nova and move the python-novatools code in nova codebase *only if* it can be reused in the long-term plan: if we plan to drop it and replace the nova CLI tool by something completely different that does not support the same commands, then I think it should rather live outside the nova source tree. Do we think the current tool can be reused as-is in the long-term plan ? Also note that (3) creates a contraint of keeping the client code up to date with the rest of nova and prevents it to change after a release, but maybe that's a good thing :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
Thanks John, While it's nice to have a vision, we also have tactic issues that we need some quick movement on. Can we do something short term to keep all parties happy while continuing this larger discussion? -S From: John Purrier Sent: Thursday, February 24, 2011 1:05 PM To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Including ttx and the mailing list. It seems as if the API experience for OpenStack is going to be a hierarchical stack, from the lowest level service interfaces to an amalgam/integrated API with orchestration. If we are making changes to the bindings and tools does it not make sense to get the schema and naming correct out of the gate? I would suggest: OStools: command line and bindings for the abstracted and orchestrated API. For instance, I can request a VM be created with a 100GB volume connected to private network “foo” and booted with image ‘bar’. OScompute: command line and bindings for OpenStack Compute Services (nova). OSnetwork: command line and bindings for OpenStack Network Services (currently in the nova project, but logically distinct). OSvolume: command line and bindings for OpenStack Volume Services (currently in the nova project, but logically distinct). OSimage: command line and bindings for OpenStack Image Services (glance). OSobject: command line and bindings for OpenStack Object Store (swift). This should be based on the ‘st’ tool currently used. All services should support an API, a command line tool that drives the API, and a web UI (“control panel”) that interfaces with the published API. Also, we should figure out a consistent schema for service tools (\tools, \common, etc.) and make that the standard for all services. The code should be part of the normal OpenStack project sources, and be packaged and distributed in a consistent manner. Thierry, do you have suggestions on the copyright headers? Thanks, John From: Sandy Walsh Sent: Thursday, February 24, 2011 10:33 AM To: Andy Smith; John Purrier; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney Subject: Novatools ... Hi guys, We have some issues around novatools that should be addressed. Here's a little background: Novatools started as a fork of python-cloudservers (https://github.com/jacobian/python-cloudservers) created by jacobian. It's a nice package; well documented, has tests and provides good cmdline and a client library. However, we needed to make changes for it to work with nova. Those changes were made and pull requests were sent to jacobian for inclusion in his branch. They were never accepted (nor rejected). In the meanwhile, more work went into our cloudservers fork: pause, suspend, diagnostics, zones, etc. Because more and more people were asking about cmdline tools for nova, we kept pointing them to our fork. It was clear that this needed to be put under more authoritative control, so we moved it to the rackspace github account. To avoid conflict with existing cloudserver installs, we rebranded as novatools and moved forward. The reality is we need a place where we can push changes quickly and not be hogtied waiting for merge. Without this, we end up pointing the community to our local branch anyway. If jacobian wants to regain control of this branch, we need assurances of timely responses. With the zone work in nova we also started using the new novatools as a client library to nova, for forwarding requests from one zone to another. This had implications on hudson and nova packaging. Hudson requires packages in PPA and I had placed it in PyPi. So this causes more issues. One issue is the BSD license vs. our standard Apache license. From my understanding it is possible to change licenses, just not retroactively. We aren't proposing to do that. We also need to change our headers to reflect copyright of Jacobian and Rackspace. I'm less sure how to go about that and appease all parties. Naming. We are going to rename to python-nova with nova being the cmdline tool. The tool will not include swift/glance cmdline options. If glance wants to inherit from the python-nova infrastructure, that's fine, but it would be a separate package. If there are no objections, I'll get started immediately on the changes. Thanks, Sandy PS Andy, do you have a reliable contact for Jacobian? I'd like to hear his thoughts, but he's incredibly hard to get a hold of. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
Perfect. Objections? (naming bun-fights discouraged ;) -S From: John Purrier Sent: Thursday, February 24, 2011 1:39 PM To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Sure, here are the tactical issues you identify (correct me if I miss any): 1. We have essentially forked python-cloudservers. As you point out, we should make a best effort to get our changes back into the original project. 2. We should integrate the command line and bindings into the nova project on LP. This should serve as the template for other services. 3. We should name the tool OScompute. 4. We should use PPA packaging for Hudson compatibility. 5. Thierry (and others with knowledge) will weigh in on the copyright headers issue. We can get RackLaw involved if necessary. This is consistent with an overall direction and allows specific changes to be made today. Thoughts? John From: Sandy Walsh Sent: Thursday, February 24, 2011 11:28 AM To: John Purrier; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Thanks John, While it's nice to have a vision, we also have tactic issues that we need some quick movement on. Can we do something short term to keep all parties happy while continuing this larger discussion? -S From: John Purrier Sent: Thursday, February 24, 2011 1:05 PM To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Including ttx and the mailing list. It seems as if the API experience for OpenStack is going to be a hierarchical stack, from the lowest level service interfaces to an amalgam/integrated API with orchestration. If we are making changes to the bindings and tools does it not make sense to get the schema and naming correct out of the gate? I would suggest: OStools: command line and bindings for the abstracted and orchestrated API. For instance, I can request a VM be created with a 100GB volume connected to private network “foo” and booted with image ‘bar’. OScompute: command line and bindings for OpenStack Compute Services (nova). OSnetwork: command line and bindings for OpenStack Network Services (currently in the nova project, but logically distinct). OSvolume: command line and bindings for OpenStack Volume Services (currently in the nova project, but logically distinct). OSimage: command line and bindings for OpenStack Image Services (glance). OSobject: command line and bindings for OpenStack Object Store (swift). This should be based on the ‘st’ tool currently used. All services should support an API, a command line tool that drives the API, and a web UI (“control panel”) that interfaces with the published API. Also, we should figure out a consistent schema for service tools (\tools, \common, etc.) and make that the standard for all services. The code should be part of the normal OpenStack project sources, and be packaged and distributed in a consistent manner. Thierry, do you have suggestions on the copyright headers? Thanks, John From: Sandy Walsh Sent: Thursday, February 24, 2011 10:33 AM To: Andy Smith; John Purrier; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney Subject: Novatools ... Hi guys, We have some issues around novatools that should be addressed. Here's a little background: Novatools started as a fork of python-cloudservers (https://github.com/jacobian/python-cloudservers) created by jacobian. It's a nice package; well documented, has tests and provides good cmdline and a client library. However, we needed to make changes for it to work with nova. Those changes were made and pull requests were sent to jacobian for inclusion in his branch. They were never accepted (nor rejected). In the meanwhile, more work went into our cloudservers fork: pause, suspend, diagnostics, zones, etc. Because more and more people were asking about cmdline tools for nova, we kept pointing them to our fork. It was clear that this needed to be put under more authoritative control, so we moved it to the rackspace github account. To avoid conflict with existing cloudserver installs, we rebranded as novatools and moved forward. The reality is we need a place where we can push changes quickly and not be hogtied waiting for merge. Without this, we end up pointing the community to our local branch anyway. If jacobian wants to regain control of this branch, we need assurances of timely responses. With the zone work in nova we also started using the new novatools as a client library to nova, for forwarding requests from one zone to another. This had implications on hudson and nova packaging. Hudson requires packages in PPA and I had
Re: [Openstack] Novatools ...
For copyright headers, just add a new Copyright 2011 OpenStack, LLC. line for existing files under the old copyright line. You can add a new license for new code for existing files, but that gets messy. For new files, just do as we usually do for new files (copyright + license brief). You can also add new files under a different license (Apache instead of BSD) if you like, but I'd probably keep it the same within one project for simplicity. Note that this is only suitable since it's BSD, if it were GPL (or some other viral license), it would be a bit different. -Eric On Thu, Feb 24, 2011 at 05:27:55PM +, Sandy Walsh wrote: Thanks John, While it's nice to have a vision, we also have tactic issues that we need some quick movement on. Can we do something short term to keep all parties happy while continuing this larger discussion? -S -- From: John Purrier Sent: Thursday, February 24, 2011 1:05 PM To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Including ttx and the mailing list. It seems as if the API experience for OpenStack is going to be a hierarchical stack, from the lowest level service interfaces to an amalgam/integrated API with orchestration. If we are making changes to the bindings and tools does it not make sense to get the schema and naming correct out of the gate? I would suggest: OStools: command line and bindings for the abstracted and orchestrated API. For instance, I can request a VM be created with a 100GB volume connected to private network foo and booted with image `bar'. OScompute: command line and bindings for OpenStack Compute Services (nova). OSnetwork: command line and bindings for OpenStack Network Services (currently in the nova project, but logically distinct). OSvolume: command line and bindings for OpenStack Volume Services (currently in the nova project, but logically distinct). OSimage: command line and bindings for OpenStack Image Services (glance). OSobject: command line and bindings for OpenStack Object Store (swift). This should be based on the `st' tool currently used. All services should support an API, a command line tool that drives the API, and a web UI (control panel) that interfaces with the published API. Also, we should figure out a consistent schema for service tools (\tools, \common, etc.) and make that the standard for all services. The code should be part of the normal OpenStack project sources, and be packaged and distributed in a consistent manner. Thierry, do you have suggestions on the copyright headers? Thanks, John From: Sandy Walsh Sent: Thursday, February 24, 2011 10:33 AM To: Andy Smith; John Purrier; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney Subject: Novatools ... Hi guys, We have some issues around novatools that should be addressed. Here's a little background: Novatools started as a fork of python-cloudservers (https://github.com/jacobian/python-cloudservers) created by jacobian. It's a nice package; well documented, has tests and provides good cmdline and a client library. However, we needed to make changes for it to work with nova. Those changes were made and pull requests were sent to jacobian for inclusion in his branch. They were never accepted (nor rejected). In the meanwhile, more work went into our cloudservers fork: pause, suspend, diagnostics, zones, etc. Because more and more people were asking about cmdline tools for nova, we kept pointing them to our fork. It was clear that this needed to be put under more authoritative control, so we moved it to the rackspace github account. To avoid conflict with existing cloudserver installs, we rebranded as novatools and moved forward. The reality is we need a place where we can push changes quickly and not be hogtied waiting for merge. Without this, we end up pointing the community to our local branch anyway. If jacobian wants to regain control of this branch, we need assurances of timely responses. With the zone work in nova we also started using the new novatools as a client library to nova, for forwarding requests from one zone to another. This had implications on hudson and nova packaging. Hudson requires packages in PPA and I had placed it in PyPi. So this causes more issues. One issue is the BSD license vs. our standard Apache license. From my
Re: [Openstack] Novatools ...
In regards to openstack tools, we certainly have some options. We could do everything from one big package with all tools for all languages/services to one project for each language/service (and all permutations in between). IMHO, I think it makes the most sense to keep the client tools for all (or at least a few primary) languages directly in the service project, so Nova would have clients/python, clients/ruby, etc. This makes it easier to reuse those packages within the service (like you need to do for cross-zone communication). Folks can always start new projects for interfacing with the service (other languages, more abstractions, ...), but some core tools will be provided in the main project. Note that this is for the code rep. When tools are actually packaged up for distribution, they can appear as different packages (for example, python-nova-tools, python-nova-server, ...) so you don't need to install everything to get just the tools. I can see great arguments for other layouts too, but in the past I've found this really helps to keep things in sync. -Eric On Thu, Feb 24, 2011 at 05:27:55PM +, Sandy Walsh wrote: Thanks John, While it's nice to have a vision, we also have tactic issues that we need some quick movement on. Can we do something short term to keep all parties happy while continuing this larger discussion? -S -- From: John Purrier Sent: Thursday, February 24, 2011 1:05 PM To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Including ttx and the mailing list. It seems as if the API experience for OpenStack is going to be a hierarchical stack, from the lowest level service interfaces to an amalgam/integrated API with orchestration. If we are making changes to the bindings and tools does it not make sense to get the schema and naming correct out of the gate? I would suggest: OStools: command line and bindings for the abstracted and orchestrated API. For instance, I can request a VM be created with a 100GB volume connected to private network foo and booted with image `bar'. OScompute: command line and bindings for OpenStack Compute Services (nova). OSnetwork: command line and bindings for OpenStack Network Services (currently in the nova project, but logically distinct). OSvolume: command line and bindings for OpenStack Volume Services (currently in the nova project, but logically distinct). OSimage: command line and bindings for OpenStack Image Services (glance). OSobject: command line and bindings for OpenStack Object Store (swift). This should be based on the `st' tool currently used. All services should support an API, a command line tool that drives the API, and a web UI (control panel) that interfaces with the published API. Also, we should figure out a consistent schema for service tools (\tools, \common, etc.) and make that the standard for all services. The code should be part of the normal OpenStack project sources, and be packaged and distributed in a consistent manner. Thierry, do you have suggestions on the copyright headers? Thanks, John From: Sandy Walsh Sent: Thursday, February 24, 2011 10:33 AM To: Andy Smith; John Purrier; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney Subject: Novatools ... Hi guys, We have some issues around novatools that should be addressed. Here's a little background: Novatools started as a fork of python-cloudservers (https://github.com/jacobian/python-cloudservers) created by jacobian. It's a nice package; well documented, has tests and provides good cmdline and a client library. However, we needed to make changes for it to work with nova. Those changes were made and pull requests were sent to jacobian for inclusion in his branch. They were never accepted (nor rejected). In the meanwhile, more work went into our cloudservers fork: pause, suspend, diagnostics, zones, etc. Because more and more people were asking about cmdline tools for nova, we kept pointing them to our fork. It was clear that this needed to be put under more authoritative control, so we moved it to the rackspace github account. To avoid conflict with existing cloudserver installs, we rebranded as novatools and moved forward. The reality is we need a place where we can push changes quickly and not be hogtied waiting for merge. Without this, we end up pointing the community to our local branch
Re: [Openstack] Novatools ...
I would encourage using all lowercase for command line tools (oscompute), I don't really care what the name is though. :) -Eric On Thu, Feb 24, 2011 at 05:42:56PM +, Sandy Walsh wrote: Perfect. Objections? (naming bun-fights discouraged ;) -S -- From: John Purrier Sent: Thursday, February 24, 2011 1:39 PM To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Sure, here are the tactical issues you identify (correct me if I miss any): 1. We have essentially forked python-cloudservers. As you point out, we should make a best effort to get our changes back into the original project. 2. We should integrate the command line and bindings into the nova project on LP. This should serve as the template for other services. 3. We should name the tool OScompute. 4. We should use PPA packaging for Hudson compatibility. 5. Thierry (and others with knowledge) will weigh in on the copyright headers issue. We can get RackLaw involved if necessary. This is consistent with an overall direction and allows specific changes to be made today. Thoughts? John From: Sandy Walsh Sent: Thursday, February 24, 2011 11:28 AM To: John Purrier; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Thanks John, While it's nice to have a vision, we also have tactic issues that we need some quick movement on. Can we do something short term to keep all parties happy while continuing this larger discussion? -S -- From: John Purrier Sent: Thursday, February 24, 2011 1:05 PM To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Including ttx and the mailing list. It seems as if the API experience for OpenStack is going to be a hierarchical stack, from the lowest level service interfaces to an amalgam/integrated API with orchestration. If we are making changes to the bindings and tools does it not make sense to get the schema and naming correct out of the gate? I would suggest: OStools: command line and bindings for the abstracted and orchestrated API. For instance, I can request a VM be created with a 100GB volume connected to private network foo and booted with image `bar'. OScompute: command line and bindings for OpenStack Compute Services (nova). OSnetwork: command line and bindings for OpenStack Network Services (currently in the nova project, but logically distinct). OSvolume: command line and bindings for OpenStack Volume Services (currently in the nova project, but logically distinct). OSimage: command line and bindings for OpenStack Image Services (glance). OSobject: command line and bindings for OpenStack Object Store (swift). This should be based on the `st' tool currently used. All services should support an API, a command line tool that drives the API, and a web UI (control panel) that interfaces with the published API. Also, we should figure out a consistent schema for service tools (\tools, \common, etc.) and make that the standard for all services. The code should be part of the normal OpenStack project sources, and be packaged and distributed in a consistent manner. Thierry, do you have suggestions on the copyright headers? Thanks, John From: Sandy Walsh Sent: Thursday, February 24, 2011 10:33 AM To: Andy Smith; John Purrier; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney Subject: Novatools ... Hi guys, We have some issues around novatools that should be addressed. Here's a little background: Novatools started as a fork of python-cloudservers (https://github.com/jacobian/python-cloudservers) created by jacobian. It's a nice package; well documented, has tests and provides good cmdline and a client library. However, we needed to make changes for it to work with nova. Those changes were made and pull requests were sent to jacobian for inclusion in his branch. They were never accepted (nor rejected). In the meanwhile, more work went into our cloudservers fork: pause, suspend, diagnostics, zones,
Re: [Openstack] Novatools ...
Thanks Eric, I agree. It would be great to do 'bzr branch lp:nova' and have all the client tools we need. Especially given the fact that the client tools are now required by the system itself. I suspect it will also be needed for integration testing. This also prevents more PPA administration. Is there a concern that if I want to simply deploy the client tools on a non-server, I have to get the full branch? Or did I miss a subtle point in there? -S From: Eric Day [e...@oddments.org] In regards to openstack tools, we certainly have some options. We could do everything from one big package with all tools for all languages/services to one project for each language/service (and all permutations in between). IMHO, I think it makes the most sense to keep the client tools for all (or at least a few primary) languages directly in the service project, so Nova would have clients/python, clients/ruby, etc. This makes it easier to reuse those packages within the service (like you need to do for cross-zone communication). Folks can always start new projects for interfacing with the service (other languages, more abstractions, ...), but some core tools will be provided in the main project. Note that this is for the code rep. When tools are actually packaged up for distribution, they can appear as different packages (for example, python-nova-tools, python-nova-server, ...) so you don't need to install everything to get just the tools. I can see great arguments for other layouts too, but in the past I've found this really helps to keep things in sync. -Eric ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
+10 for lowercase. On Thu, Feb 24, 2011 at 12:00 PM, Eric Day e...@oddments.org wrote: I would encourage using all lowercase for command line tools (oscompute), I don't really care what the name is though. :) -Eric On Thu, Feb 24, 2011 at 05:42:56PM +, Sandy Walsh wrote: Perfect. Objections? (naming bun-fights discouraged ;) -S -- From: John Purrier Sent: Thursday, February 24, 2011 1:39 PM To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Sure, here are the tactical issues you identify (correct me if I miss any): 1. We have essentially forked python-cloudservers. As you point out, we should make a best effort to get our changes back into the original project. 2. We should integrate the command line and bindings into the nova project on LP. This should serve as the template for other services. 3. We should name the tool OScompute. 4. We should use PPA packaging for Hudson compatibility. 5. Thierry (and others with knowledge) will weigh in on the copyright headers issue. We can get RackLaw involved if necessary. This is consistent with an overall direction and allows specific changes to be made today. Thoughts? John From: Sandy Walsh Sent: Thursday, February 24, 2011 11:28 AM To: John Purrier; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Thanks John, While it's nice to have a vision, we also have tactic issues that we need some quick movement on. Can we do something short term to keep all parties happy while continuing this larger discussion? -S -- From: John Purrier Sent: Thursday, February 24, 2011 1:05 PM To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Including ttx and the mailing list. It seems as if the API experience for OpenStack is going to be a hierarchical stack, from the lowest level service interfaces to an amalgam/integrated API with orchestration. If we are making changes to the bindings and tools does it not make sense to get the schema and naming correct out of the gate? I would suggest: OStools: command line and bindings for the abstracted and orchestrated API. For instance, I can request a VM be created with a 100GB volume connected to private network foo and booted with image `bar'. OScompute: command line and bindings for OpenStack Compute Services (nova). OSnetwork: command line and bindings for OpenStack Network Services (currently in the nova project, but logically distinct). OSvolume: command line and bindings for OpenStack Volume Services (currently in the nova project, but logically distinct). OSimage: command line and bindings for OpenStack Image Services (glance). OSobject: command line and bindings for OpenStack Object Store (swift). This should be based on the `st' tool currently used. All services should support an API, a command line tool that drives the API, and a web UI (control panel) that interfaces with the published API. Also, we should figure out a consistent schema for service tools (\tools, \common, etc.) and make that the standard for all services. The code should be part of the normal OpenStack project sources, and be packaged and distributed in a consistent manner. Thierry, do you have suggestions on the copyright headers? Thanks, John From: Sandy Walsh Sent: Thursday, February 24, 2011 10:33 AM To: Andy Smith; John Purrier; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney Subject: Novatools ... Hi guys, We have some issues around novatools that should be addressed. Here's a little background: Novatools started as a fork of python-cloudservers (https://github.com/jacobian/python-cloudservers) created by jacobian. It's a nice package; well documented, has tests and provides good cmdline and a client library. However, we needed to make changes for it to work with nova. Those changes were made and pull requests were sent to jacobian for inclusion in his branch. They were never accepted (nor rejected). In the meanwhile, more work
Re: [Openstack] Novatools ...
On Thu, Feb 24, 2011 at 1:49 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Jay, I totally see your argument. Are you proposing a more plug-in type mechanism like nova-manage/django-admin (but uses the public API)? Or, perhaps, similar to the Citrix 'xe' umbrella? Like the nova-manage tool, but using the public API. Is this part of the longer term discussion (as we still need something now)? Yes, longer term discussion. -jay -S From: Jay Pipes [jaypi...@gmail.com] Why is there a need for more than 1 CLI tool? What is the point? I find the euca-* separate tools to be a complete and utter disaster. Having fewer CLI tools makes more sense to me than having eleventy billion mostly-similar CLI tools. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
I see the value in having a separate CLI tool per service as: a. Scales easily, no cross-service dependencies. b. Expectations are clear that each service must provide an API and CLI to drive it. c. Interactions can be clearly targeted to a specified service (no ambiguity). d. These tools are naturally built by the developers to debug the service as it is being built. As I mentioned, we can (should?) also have an aggregated ostools framework that can drive any of the lower level tools, as well as invoke any higher level orchestration constructs that we build. This makes sense to me, but at the end of the day we need a toolset that can drive our service interfaces. Singular or a collection of tools is less important than the fact that the service API's exist and can be accessed via scripts and the command line. John -Original Message- From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Jay Pipes Sent: Thursday, February 24, 2011 12:20 PM To: Eric Day Cc: Josh Kearney; so...@openstack.org; Andy Smith; openstack@lists.launchpad.net; John Purrier; Rick Clark Subject: Re: [Openstack] Novatools ... On Thu, Feb 24, 2011 at 1:00 PM, Eric Day e...@oddments.org wrote: I would encourage using all lowercase for command line tools (oscompute), I don't really care what the name is though. :) Why is there a need for more than 1 CLI tool? What is the point? I find the euca-* separate tools to be a complete and utter disaster. Having fewer CLI tools makes more sense to me than having eleventy billion mostly-similar CLI tools. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
Eric Day wrote: For copyright headers, just add a new Copyright 2011 OpenStack, LLC. line for existing files under the old copyright line. You can add a new license for new code for existing files, but that gets messy. For new files, just do as we usually do for new files (copyright + license brief). You can also add new files under a different license (Apache instead of BSD) if you like, but I'd probably keep it the same within one project for simplicity. Note that this is only suitable since it's BSD, if it were GPL (or some other viral license), it would be a bit different. In fact, the current files do not have any copyright header. Should we invent the copyright line that should have been there, and add to it ? -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
On Thu, Feb 24, 2011 at 2:19 PM, John Purrier j...@openstack.org wrote: I see the value in having a separate CLI tool per service as: a. Scales easily, no cross-service dependencies. I'm talking about CLI tools that access the API, not the individual services... b. Expectations are clear that each service must provide an API and CLI to drive it. No, there is only one OpenStack API. A single tool to talk this API is what I'm recommending c. Interactions can be clearly targeted to a specified service (no ambiguity). Again, only one API... d. These tools are naturally built by the developers to debug the service as it is being built. As I mentioned, we can (should?) also have an aggregated ostools framework that can drive any of the lower level tools, as well as invoke any higher level orchestration constructs that we build. This makes sense to me, but at the end of the day we need a toolset that can drive our service interfaces. Singular or a collection of tools is less important than the fact that the service API's exist and can be accessed via scripts and the command line. Sorry, I don't see how having a proliferations of little command-line tools for managing OpenStack services is useful. Managing OpenStack services should be done through the OpenStack API, not via multiple little tools... Just my 2 cents, jay John -Original Message- From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Jay Pipes Sent: Thursday, February 24, 2011 12:20 PM To: Eric Day Cc: Josh Kearney; so...@openstack.org; Andy Smith; openstack@lists.launchpad.net; John Purrier; Rick Clark Subject: Re: [Openstack] Novatools ... On Thu, Feb 24, 2011 at 1:00 PM, Eric Day e...@oddments.org wrote: I would encourage using all lowercase for command line tools (oscompute), I don't really care what the name is though. :) Why is there a need for more than 1 CLI tool? What is the point? I find the euca-* separate tools to be a complete and utter disaster. Having fewer CLI tools makes more sense to me than having eleventy billion mostly-similar CLI tools. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
Ahh, well I would probably just add our copyright line below Jacob's in the LICENSE file for now, and maybe ping him to add the brief header to the old files. For new files, we can still add our standard copyright/license header. If add files under Apache, be sure to add LICENSE.Apache too for the full text. -Eric On Thu, Feb 24, 2011 at 08:20:16PM +0100, Thierry Carrez wrote: Eric Day wrote: For copyright headers, just add a new Copyright 2011 OpenStack, LLC. line for existing files under the old copyright line. You can add a new license for new code for existing files, but that gets messy. For new files, just do as we usually do for new files (copyright + license brief). You can also add new files under a different license (Apache instead of BSD) if you like, but I'd probably keep it the same within one project for simplicity. Note that this is only suitable since it's BSD, if it were GPL (or some other viral license), it would be a bit different. In fact, the current files do not have any copyright header. Should we invent the copyright line that should have been there, and add to it ? -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
Well, my previous reply somehow isn't going through to the list... so... here it is again: I've got some objections so far: 1. relying on python-cloudservers is a good metric by which to judge your compatibility with the rackspace cloud, once jacob has accepted the changes to support changing the auth endpoint. My opinion is that this project should be a fork of python-cloudservers with the same name and whose intention is not to add additional features at this time. 1a. To support your additional features for the very short term you should be writing extensions to python-cloudservers (possibly with your minor compat modifications) via actual python extension mechanisms (import, inherit and extend). 2. the existing spec for openstack api 1.1 is still contested, so basing the tool chain going forward off of something that is made for compat with cloudservers is possibly misguided at this point. 3. i'm not sure there need to be separate tools/libraries to interact with each service, but i do like the idea of each being able ot provide a piece of a web dashboard. 4. Emails from sandy/others are being duplicated multiple times in this thread, i am replying only to the list for this message. On Thu, Feb 24, 2011 at 11:20 AM, Thierry Carrez thie...@openstack.orgwrote: Eric Day wrote: For copyright headers, just add a new Copyright 2011 OpenStack, LLC. line for existing files under the old copyright line. You can add a new license for new code for existing files, but that gets messy. For new files, just do as we usually do for new files (copyright + license brief). You can also add new files under a different license (Apache instead of BSD) if you like, but I'd probably keep it the same within one project for simplicity. Note that this is only suitable since it's BSD, if it were GPL (or some other viral license), it would be a bit different. In fact, the current files do not have any copyright header. Should we invent the copyright line that should have been there, and add to it ? -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
Perhaps I'm missing something, but I'm not sure what you mean by one API. Each project/service will be driving their own API, no? For example do you expect one CLI tool for swift, nova, and a queue service? I see John's points with allowing each service to drive their own API/tools (hopefully following some cross-project guidelines so they are consistent), and then possibly supplying a super tool that allows complex orchestration using the other tools when needed. For example: os-super-tool create cluster network nodes images ... This would in turn use os-compute, os-network, etc. We could also do some tool reflection to allow: os-compute args To be the same as: os-super-tool compute args So you can only use os-super-tool if you don't want to remember all the others. -Eric On Thu, Feb 24, 2011 at 02:27:58PM -0500, Jay Pipes wrote: On Thu, Feb 24, 2011 at 2:19 PM, John Purrier j...@openstack.org wrote: I see the value in having a separate CLI tool per service as: a. Scales easily, no cross-service dependencies. I'm talking about CLI tools that access the API, not the individual services... b. Expectations are clear that each service must provide an API and CLI to drive it. No, there is only one OpenStack API. A single tool to talk this API is what I'm recommending c. Interactions can be clearly targeted to a specified service (no ambiguity). Again, only one API... d. These tools are naturally built by the developers to debug the service as it is being built. As I mentioned, we can (should?) also have an aggregated ostools framework that can drive any of the lower level tools, as well as invoke any higher level orchestration constructs that we build. This makes sense to me, but at the end of the day we need a toolset that can drive our service interfaces. Singular or a collection of tools is less important than the fact that the service API's exist and can be accessed via scripts and the command line. Sorry, I don't see how having a proliferations of little command-line tools for managing OpenStack services is useful. Managing OpenStack services should be done through the OpenStack API, not via multiple little tools... Just my 2 cents, jay John -Original Message- From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Jay Pipes Sent: Thursday, February 24, 2011 12:20 PM To: Eric Day Cc: Josh Kearney; so...@openstack.org; Andy Smith; openstack@lists.launchpad.net; John Purrier; Rick Clark Subject: Re: [Openstack] Novatools ... On Thu, Feb 24, 2011 at 1:00 PM, Eric Day e...@oddments.org wrote: I would encourage using all lowercase for command line tools (oscompute), I don't really care what the name is though. :) Why is there a need for more than 1 CLI tool? What is the point? I find the euca-* separate tools to be a complete and utter disaster. Having fewer CLI tools makes more sense to me than having eleventy billion mostly-similar CLI tools. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
On Thu, Feb 24, 2011 at 2:48 PM, Eric Day e...@oddments.org wrote: Perhaps I'm missing something, but I'm not sure what you mean by one API. Each project/service will be driving their own API, no? For example do you expect one CLI tool for swift, nova, and a queue service? I see John's points with allowing each service to drive their own API/tools (hopefully following some cross-project guidelines so they are consistent), and then possibly supplying a super tool that allows complex orchestration using the other tools when needed. For example: os-super-tool create cluster network nodes images ... This would in turn use os-compute, os-network, etc. We could also do some tool reflection to allow: os-compute args To be the same as: os-super-tool compute args So you can only use os-super-tool if you don't want to remember all the others. I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
I'd definitely approve of something xe-like. $ os vm-create $ os user-list $ os network-attach That looks pretty neat to me. Ewan. -Original Message- From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Sandy Walsh Sent: 24 February 2011 10:50 To: Jay Pipes; Eric Day Cc: Josh Kearney; so...@openstack.org; Andy Smith; openstack@lists.launchpad.net; John Purrier; Rick Clark Subject: Re: [Openstack] Novatools ... Jay, I totally see your argument. Are you proposing a more plug-in type mechanism like nova- manage/django-admin (but uses the public API)? Or, perhaps, similar to the Citrix 'xe' umbrella? Is this part of the longer term discussion (as we still need something now)? -S From: Jay Pipes [jaypi...@gmail.com] Why is there a need for more than 1 CLI tool? What is the point? I find the euca-* separate tools to be a complete and utter disaster. Having fewer CLI tools makes more sense to me than having eleventy billion mostly-similar CLI tools. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) -Eric ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ... where to place in /nova/?
Yup, this looks like the super tool that jay was talking of earlier (odd too, since that's something I'm using accused of being) I kind of like it as well, since it permits swift, nova and glance to have their own client tools, but fit within the larger umbrella (and tab-completion/hints work ;) We just need to make sure each toolset shares a common infrastructure so it can plug in. That said, for now I'm going to move novatools into nova, rename to oscompute and get on with my life. Unless anyone screams, I'll put it in nova/clients/python/oscompute /me plugs ears I can't hear anyone. la la la From: Ewan Mellor [ewan.mel...@eu.citrix.com] I'd definitely approve of something xe-like. $ os vm-create $ os user-list $ os network-attach That looks pretty neat to me. Ewan. Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ... where to place in /nova/?
On Thu, Feb 24, 2011 at 4:10 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Yup, this looks like the super tool that jay was talking of earlier (odd too, since that's something I'm using accused of being) I kind of like it as well, since it permits swift, nova and glance to have their own client tools, but fit within the larger umbrella (and tab-completion/hints work ;) We just need to make sure each toolset shares a common infrastructure so it can plug in. That said, for now I'm going to move novatools into nova, rename to oscompute and get on with my life. Unless anyone screams, I'll put it in nova/clients/python/oscompute I'd prefer os-computer over oscomputer, but that's a nit... The way we structured it in Glance is that /glance/client.py contains the client that speaks the Glance REST API. Tools go into bin/, including CLI tools. So, bin/ contains not just the servers (glance-api and glance-registry), but also the daemon control tool (glance-control, similar to swift's bin/swift-init) and now CLI tools like glance-admin and glance-upload. Just a thought, jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ... where to place in /nova/?
Hmm, that's a little tricky since oscompute will be contain the cmdline tool and the client tool to the REST API (cmdline is just a shell interface over the client). It would mean splitting things up and the setup.py would get complicated. To Eric's point .../clients/python/* .../clients/ruby/* ... Yes? -S From: Jay Pipes [jaypi...@gmail.com] I'd prefer os-computer over oscomputer, but that's a nit... The way we structured it in Glance is that /glance/client.py contains the client that speaks the Glance REST API. Tools go into bin/, including CLI tools. So, bin/ contains not just the servers (glance-api and glance-registry), but also the daemon control tool (glance-control, similar to swift's bin/swift-init) and now CLI tools like glance-admin and glance-upload. Just a thought, jay Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
On Thu, Feb 24, 2011 at 4:45 PM, John Purrier john.purr...@rackspace.com wrote: We all knew you would come around, Jay! No-one wants you to lose your mind... Easy to do around here ;) -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
++ On Thu, Feb 24, 2011 at 02:33:42PM -0800, Devin Carlen wrote: This is a bit nitpicky but I'd rather see it called just nova, as in: nova describe images Who has strong opinions? On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote: On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote: On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). ++ We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
I agree the 'os' designation is ambiguous and likely to cause some confusion. On 02/24/2011 04:36 PM, Eric Day wrote: ++ On Thu, Feb 24, 2011 at 02:33:42PM -0800, Devin Carlen wrote: This is a bit nitpicky but I'd rather see it called just nova, as in: nova describe images Who has strong opinions? On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote: On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote: On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). ++ We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
I'd also like to see it called 'nova'. On Thu, Feb 24, 2011 at 4:41 PM, Rick Clark rick.cl...@rackspace.comwrote: I agree the 'os' designation is ambiguous and likely to cause some confusion. On 02/24/2011 04:36 PM, Eric Day wrote: ++ On Thu, Feb 24, 2011 at 02:33:42PM -0800, Devin Carlen wrote: This is a bit nitpicky but I'd rather see it called just nova, as in: nova describe images Who has strong opinions? On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote: On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote: On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). ++ We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
What about an interactive shell like IOS, vyatta, python shell, irb, etc $ novashell novashell show instances novashell stop instance foo novashell set instance foo memory 2048 novashell start instance foo Then wrap it in SSHD and you can embed nova into hardware, manage it like a switch, router, netapp, etc. You can always break out of the shell and get into the guts if you wanted to dig deeper. Down the road maybe you can introduce the concept of commits and rollbacks. -JC On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote: On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote: On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). ++ We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
On 02/24/2011 04:53 PM, JC Smith wrote: What about an interactive shell like IOS, vyatta, python shell, irb, etc $ novashell novashell show instances novashell stop instance foo novashell set instance foo memory 2048 novashell start instance foo Then wrap it in SSHD and you can embed nova into hardware, manage it like a switch, router, netapp, etc. You can always break out of the shell and get into the guts if you wanted to dig deeper. Down the road maybe you can introduce the concept of commits and rollbacks. Beautiful, I love it. -JC On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote: On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote: On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). ++ We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
This thread seems to be radically messed up, but from where I am sitting it certainly doesn't seem like everybody is agreeing, so far it appears that most people disagree about most things. On Thu, Feb 24, 2011 at 2:33 PM, Trey Morris trey.mor...@rackspace.comwrote: sounds like we agree then. Each service has it's own tool set, and services which are made up of sub-services will have a tool set which can make calls translating through the tool sets of its sub-services. On Thu, Feb 24, 2011 at 3:30 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote: On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). ++ We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
(by radically messed up i mean i am getting up to 4 copies of each message and the ordering has been non-chronological) On Thu, Feb 24, 2011 at 3:36 PM, Andy Smith andys...@gmail.com wrote: This thread seems to be radically messed up, but from where I am sitting it certainly doesn't seem like everybody is agreeing, so far it appears that most people disagree about most things. On Thu, Feb 24, 2011 at 2:33 PM, Trey Morris trey.mor...@rackspace.comwrote: sounds like we agree then. Each service has it's own tool set, and services which are made up of sub-services will have a tool set which can make calls translating through the tool sets of its sub-services. On Thu, Feb 24, 2011 at 3:30 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote: On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). ++ We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
I guess I will be the odd man out, but using the project name for compute as the command line tool name makes no sense. As we add more projects and services it makes less sense to drive them from a tool called 'nova'. For example, today swift has a tool called st to manipulate its rest api. Are we saying that it is logical to run 'nova list container'? I would prefer to use 'openstack' and then let people alias it to something shorter. I do like the idea of having an interactive shell, as well as direct api calls in the tool. /nitpick John -Original Message- From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Devin Carlen Sent: Thursday, February 24, 2011 4:34 PM To: Jay Pipes Cc: Josh Kearney; so...@openstack.org; Andy Smith; openstack@lists.launchpad.net; John Purrier; Rick Clark Subject: Re: [Openstack] Novatools ... This is a bit nitpicky but I'd rather see it called just nova, as in: nova describe images Who has strong opinions? On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote: On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote: On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). ++ We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ... where to place in /nova/?
Unless the mailing lists are being even crazier than I think, I don't believe anybody has addressed any of the concerns I brought up in the novatools thread. Am I missing a set of emails or have you? --andy On Thu, Feb 24, 2011 at 2:16 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, Feb 24, 2011 at 4:39 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Hmm, that's a little tricky since oscompute will be contain the cmdline tool and the client tool to the REST API (cmdline is just a shell interface over the client). It would mean splitting things up and the setup.py would get complicated. Why are they together? To Eric's point .../clients/python/* .../clients/ruby/* Why have ruby clients in the Nova package? -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
Hi John, I think the super tool should be named openstack, I don't think anyone was proposing we call that nova. Each individual project can use whatever name it likes, for example: nova create instance glance describe images openstack create cluster netowork imaage count The last one would use the nova/glance/network APIs/tools to actually do the work, it's just a thin wrapper around service specific tools. -Eric On Thu, Feb 24, 2011 at 05:49:43PM -0600, John Purrier wrote: I guess I will be the odd man out, but using the project name for compute as the command line tool name makes no sense. As we add more projects and services it makes less sense to drive them from a tool called 'nova'. For example, today swift has a tool called st to manipulate its rest api. Are we saying that it is logical to run 'nova list container'? I would prefer to use 'openstack' and then let people alias it to something shorter. I do like the idea of having an interactive shell, as well as direct api calls in the tool. /nitpick John -Original Message- From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Devin Carlen Sent: Thursday, February 24, 2011 4:34 PM To: Jay Pipes Cc: Josh Kearney; so...@openstack.org; Andy Smith; openstack@lists.launchpad.net; John Purrier; Rick Clark Subject: Re: [Openstack] Novatools ... This is a bit nitpicky but I'd rather see it called just nova, as in: nova describe images Who has strong opinions? On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote: On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote: On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). ++ We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
I'd like to go on record as saying that anything related to nova or openstack that doesn't allow you to configure which public API you're consuming shouldn't bear the name nova or openstack. If you look at http://nova.openstack.org/ you see API Compatibility in bold as one of our design guidelines. This agnosticism should apply to clients as well. If I use something called 'nova' or 'openstack', I expect it to run against my installation regardless of my particular configuration is. It is now (with paste.deploy) trivial to run one API (ec2) and not the other (cloudservers). If we're writing a tool that only uses the cloudservers api, it clearly doesn't run against any openstack installation, so shouldn't have the names nova or openstack associated with it. I'm glad novatools exists and we're getting a library that consumes one of our APIs, but lets not call it 'nova' or 'os'. We could in fact just keep calling it 'cloudservers' as that is the API it exercises. -todd[1] On Thu, Feb 24, 2011 at 7:17 PM, John Purrier j...@openstack.org wrote: Sounds good. John -Original Message- From: Eric Day [mailto:e...@oddments.org] Sent: Thursday, February 24, 2011 6:17 PM To: John Purrier Cc: 'Devin Carlen'; 'Jay Pipes'; 'Josh Kearney'; so...@openstack.org; 'Andy Smith'; openstack@lists.launchpad.net; 'Rick Clark'; 'John Purrier' Subject: Re: [Openstack] Novatools ... Hi John, I think the super tool should be named openstack, I don't think anyone was proposing we call that nova. Each individual project can use whatever name it likes, for example: nova create instance glance describe images openstack create cluster netowork imaage count The last one would use the nova/glance/network APIs/tools to actually do the work, it's just a thin wrapper around service specific tools. -Eric On Thu, Feb 24, 2011 at 05:49:43PM -0600, John Purrier wrote: I guess I will be the odd man out, but using the project name for compute as the command line tool name makes no sense. As we add more projects and services it makes less sense to drive them from a tool called 'nova'. For example, today swift has a tool called st to manipulate its rest api. Are we saying that it is logical to run 'nova list container'? I would prefer to use 'openstack' and then let people alias it to something shorter. I do like the idea of having an interactive shell, as well as direct api calls in the tool. /nitpick John -Original Message- From: openstack-bounces+john=openstack@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of Devin Carlen Sent: Thursday, February 24, 2011 4:34 PM To: Jay Pipes Cc: Josh Kearney; so...@openstack.org; Andy Smith; openstack@lists.launchpad.net; John Purrier; Rick Clark Subject: Re: [Openstack] Novatools ... This is a bit nitpicky but I'd rather see it called just nova, as in: nova describe images Who has strong opinions? On Feb 24, 2011, at 1:30 PM, Jay Pipes wrote: On Thu, Feb 24, 2011 at 4:06 PM, Eric Day e...@oddments.org wrote: On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. Completely agree. :) Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. Yup, agree. Also keep in mind that some operations may be duplicates across services, just with a different context. For example, in a deployment where you use glance backed by swift for nova, os-compute describe image id may be the same as os-image describe id or os-object describe id (swift), but the os-compute is in the context of instances so it could have more metadata. This will mirror the dependency tree we see between services (especially as they are split out). ++ We want to make sure there are tools so services can stand alone as needed (for example, os-image if you run glance standalone). Services that combine other services (like nova) should aggregate these into context-specific commands so you don't *need* to use the underlying service tools for most things. This allows you to control nova use one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https
Re: [Openstack] Novatools ... where to place in /nova/?
Looking at https://lists.launchpad.net/openstack/threads.html I see a few posts from you, but they all complain about the list missing messages from you. Not sure what the issue is. Seems replies from everyone but you are working just fine. -jay On Thu, Feb 24, 2011 at 7:03 PM, Andy Smith andys...@gmail.com wrote: Unless the mailing lists are being even crazier than I think, I don't believe anybody has addressed any of the concerns I brought up in the novatools thread. Am I missing a set of emails or have you? --andy On Thu, Feb 24, 2011 at 2:16 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, Feb 24, 2011 at 4:39 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Hmm, that's a little tricky since oscompute will be contain the cmdline tool and the client tool to the REST API (cmdline is just a shell interface over the client). It would mean splitting things up and the setup.py would get complicated. Why are they together? To Eric's point .../clients/python/* .../clients/ruby/* Why have ruby clients in the Nova package? -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith andys...@gmail.com wrote: Well, my previous reply somehow isn't going through to the list... so... here it is again: I've got some objections so far: 1. relying on python-cloudservers is a good metric by which to judge your compatibility with the rackspace cloud, once jacob has accepted the changes to support changing the auth endpoint. My opinion is that this project should be a fork of python-cloudservers with the same name and whose intention is not to add additional features at this time. Why? As much as I like JKM, I don't think relying on someone who has no interaction with the OpenStack community to accept patches from the OpenStack community is a good idea. That's not at all what I said. You have two tasks here, the one described in (1) is make minimal changes to python-cloudservers such that you can point it at a nova deployment and test compat with existing cloudservers implementations. The second task is described in (1a) make extensions to that to support your immediate needs that are beyond the cloudservers compatibility. 1a. To support your additional features for the very short term you should be writing extensions to python-cloudservers (possibly with your minor compat modifications) via actual python extension mechanisms (import, inherit and extend). Again, why? With python-novatools we have complete control over the code and don't need to push it back to python-cloudservers, which is not OpenStack-based, it's specific to Rackspace Cloud Servers. One of your needs is to provide something that is compatible with cloudservers so that you can migrate without breaking existing customers. 2. the existing spec for openstack api 1.1 is still contested, so basing the tool chain going forward off of something that is made for compat with cloudservers is possibly misguided at this point. Only if you hamstring it by saying that the changes should be pushed back upstream. I don't see what changes or upstream you are referring to, I was stating that there is not agreement over what the openstack api should be and basing plans heavily upon the existing proposal may be premature. 3. i'm not sure there need to be separate tools/libraries to interact with each service, but i do like the idea of each being able ot provide a piece of a web dashboard. I'm not sure I understand what #3 has to do with novatools being separate from python-cloudservers. Could you explain? I was responding to John Purrier's statements. --andy -jay On Thu, Feb 24, 2011 at 11:20 AM, Thierry Carrez thie...@openstack.org wrote: Eric Day wrote: For copyright headers, just add a new Copyright 2011 OpenStack, LLC. line for existing files under the old copyright line. You can add a new license for new code for existing files, but that gets messy. For new files, just do as we usually do for new files (copyright + license brief). You can also add new files under a different license (Apache instead of BSD) if you like, but I'd probably keep it the same within one project for simplicity. Note that this is only suitable since it's BSD, if it were GPL (or some other viral license), it would be a bit different. In fact, the current files do not have any copyright header. Should we invent the copyright line that should have been there, and add to it ? -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ... where to place in /nova/?
Please ignore the first clause of that email as it appears the message was indeed received. I still feel there is discussion about this (novatools) going on in the novatools thread. --andy On Thu, Feb 24, 2011 at 5:41 PM, Jay Pipes jaypi...@gmail.com wrote: Looking at https://lists.launchpad.net/openstack/threads.html I see a few posts from you, but they all complain about the list missing messages from you. Not sure what the issue is. Seems replies from everyone but you are working just fine. -jay On Thu, Feb 24, 2011 at 7:03 PM, Andy Smith andys...@gmail.com wrote: Unless the mailing lists are being even crazier than I think, I don't believe anybody has addressed any of the concerns I brought up in the novatools thread. Am I missing a set of emails or have you? --andy On Thu, Feb 24, 2011 at 2:16 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, Feb 24, 2011 at 4:39 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Hmm, that's a little tricky since oscompute will be contain the cmdline tool and the client tool to the REST API (cmdline is just a shell interface over the client). It would mean splitting things up and the setup.py would get complicated. Why are they together? To Eric's point .../clients/python/* .../clients/ruby/* Why have ruby clients in the Nova package? -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
Some great discussion going on here folks but, in an attempt to prevent this turning into a full-on Painting the Bike Shed debate, here are the assumptions I'm proceeding with: 1. Eventually there will be a super tool to aggregate the various services. It will be built/named later by someone. 2. Consensus seems to prefer nova as the Compute tool name. Based on this I'm keeping the package as python-novatools (the cmdline tool will be nova). Someone high up can put their foot down if this is wrong. 3. I'm going to move it from github to LP under Nova, fix the headers and apply co-BSD/Apache license. 4. There are lots of good ideas about ways to expand this tool, but right now it is what it is and I need it in trunk to keep Zones moving ahead for Cactus. (2 weeks left till Feature Freeze!!) If someone wants to change it after, merge-props are always welcome. Thanks everyone for your input. -Sandy Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
On Thu, Feb 24, 2011 at 9:05 PM, Andy Smith andys...@gmail.com wrote: On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith andys...@gmail.com wrote: Well, my previous reply somehow isn't going through to the list... so... here it is again: I've got some objections so far: 1. relying on python-cloudservers is a good metric by which to judge your compatibility with the rackspace cloud, once jacob has accepted the changes to support changing the auth endpoint. My opinion is that this project should be a fork of python-cloudservers with the same name and whose intention is not to add additional features at this time. Why? As much as I like JKM, I don't think relying on someone who has no interaction with the OpenStack community to accept patches from the OpenStack community is a good idea. That's not at all what I said. You have two tasks here, the one described in (1) is make minimal changes to python-cloudservers such that you can point it at a nova deployment and test compat with existing cloudservers implementations. The second task is described in (1a) make extensions to that to support your immediate needs that are beyond the cloudservers compatibility. OK, we're clearly not communicating properly here. This is the original quote from Sandy that I was trying to address why your (1) above isn't working: The reality is we need a place where we can push changes quickly and not be hogtied waiting for merge. Without this, we end up pointing the community to our local branch anyway. If jacobian wants to regain control of this branch, we need assurances of timely responses. Sandy *has* tried to make minimal changes to python-cloudservers and have those changes merged. No response from JKM yet, according to Sandy. 1a. To support your additional features for the very short term you should be writing extensions to python-cloudservers (possibly with your minor compat modifications) via actual python extension mechanisms (import, inherit and extend). Again, why? With python-novatools we have complete control over the code and don't need to push it back to python-cloudservers, which is not OpenStack-based, it's specific to Rackspace Cloud Servers. One of your needs is to provide something that is compatible with cloudservers so that you can migrate without breaking existing customers. *If* Sandy's minimal changes were merged, then python-cloudservers would be that something that is compatible with cloudservers (and nova) that you talk about above. But JKM has not been responsive. Again, Sandy needs to do something... not wait for JKM to get back in touch. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ... where to place in /nova/?
On Thu, Feb 24, 2011 at 9:19 PM, Andy Smith andys...@gmail.com wrote: Please ignore the first clause of that email as it appears the message was indeed received. I still feel there is discussion about this (novatools) going on in the novatools thread. Yes, no doubt. Both of these threads are about novatools. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ... where to place in /nova/?
I, mistakingly, changed the subject so I could focus on the install directory. Sorry for creating a rift. Hopefully, I'm going to move it in such a way that we don't need to mess with the python path for nova and a user can still install it if desired. -S Yes, no doubt. Both of these threads are about novatools. -jay Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
Thanks Jay. Yes, to the best of my knowledge nothing should have changed to keep novatools from working with cloudservers/RS API. This was the situation right up to the rebranding. Now, a merge would be much harder. -S *If* Sandy's minimal changes were merged, then python-cloudservers would be that something that is compatible with cloudservers (and nova) that you talk about above. But JKM has not been responsive. Again, Sandy needs to do something... not wait for JKM to get back in touch. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
On Thu, Feb 24, 2011 at 6:25 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, Feb 24, 2011 at 9:05 PM, Andy Smith andys...@gmail.com wrote: On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith andys...@gmail.com wrote: Well, my previous reply somehow isn't going through to the list... so... here it is again: I've got some objections so far: 1. relying on python-cloudservers is a good metric by which to judge your compatibility with the rackspace cloud, once jacob has accepted the changes to support changing the auth endpoint. My opinion is that this project should be a fork of python-cloudservers with the same name and whose intention is not to add additional features at this time. Why? As much as I like JKM, I don't think relying on someone who has no interaction with the OpenStack community to accept patches from the OpenStack community is a good idea. That's not at all what I said. You have two tasks here, the one described in (1) is make minimal changes to python-cloudservers such that you can point it at a nova deployment and test compat with existing cloudservers implementations. The second task is described in (1a) make extensions to that to support your immediate needs that are beyond the cloudservers compatibility. OK, we're clearly not communicating properly here. This is the original quote from Sandy that I was trying to address why your (1) above isn't working: The reality is we need a place where we can push changes quickly and not be hogtied waiting for merge. Without this, we end up pointing the community to our local branch anyway. If jacobian wants to regain control of this branch, we need assurances of timely responses. Sandy *has* tried to make minimal changes to python-cloudservers and have those changes merged. No response from JKM yet, according to Sandy. 1a. To support your additional features for the very short term you should be writing extensions to python-cloudservers (possibly with your minor compat modifications) via actual python extension mechanisms (import, inherit and extend). Again, why? With python-novatools we have complete control over the code and don't need to push it back to python-cloudservers, which is not OpenStack-based, it's specific to Rackspace Cloud Servers. One of your needs is to provide something that is compatible with cloudservers so that you can migrate without breaking existing customers. *If* Sandy's minimal changes were merged, then python-cloudservers would be that something that is compatible with cloudservers (and nova) that you talk about above. But JKM has not been responsive. Again, Sandy needs to do something... not wait for JKM to get back in touch. My original suggestion is that renaming it to novatools is not required for that, renaming makes it that much less likely that jkm will be interested in merging the changes, and pulling the code directly into nova as the other novatools thread suggests makes that process even harder. My suggestion is to simply fork the project on github and make the minimal changes there (and clone to launchpad and make PPAs if that helps for testing in the meantime). Also per JKM responsiveness, I poked him: 02:16 jacobkm termie: going back a bit, but patches welcome. I'm working on a light refactoring to support multiple providers (so it'll work with openstack, etc.) and a few other cleanups, but send me stuff and I'll integrate it. So we have perhaps a decent chance of getting things rolling there? I think it is worth pursuing. --andy -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Novatools ...
But will he continue to pull merges on a rapidly changing series of patches up to RC on April 14th and beyond? -S So we have perhaps a decent chance of getting things rolling there? I think it is worth pursuing. --andy Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
