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
+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
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,
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:
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
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
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
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.
+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.
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
@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
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
=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
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
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
=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
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
@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
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,
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
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
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/*
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
++
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
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
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
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,
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
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.
(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
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
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,
@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
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
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
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
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
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.
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
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
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
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
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
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
44 matches
Mail list logo
