Thanks Thierry for summarizing the concerns.
I have a new version in https://github.com/rackspace/python-novatools
This does the following:
1. Renames the cmdline tool to nova. The package is still python-novatools
2. Ups the version # to 2.1
3. Changes the license to Apache for 2.1+. Prior versi
+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 wrote:
> Thierry Car
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 h
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 tha
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
On Thu, Feb 24, 2011 at 6:25 PM, Jay Pipes wrote:
> On Thu, Feb 24, 2011 at 9:05 PM, Andy Smith wrote:
> > On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes wrote:
> >> On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith wrote:
> >> > Well, my previous reply somehow isn't going through to the list...
> so...
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
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
_
On Thu, Feb 24, 2011 at 9:19 PM, Andy Smith 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
On Thu, Feb 24, 2011 at 9:05 PM, Andy Smith wrote:
> On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes wrote:
>> On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith 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:
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.
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 wrote:
> Looking at https://lists.launchpad.net/openstack/thre
On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes wrote:
> On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith 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
On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith 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,
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 wrote:
stack.org; Andy Smith;
> openstack@lists.launchpad.net; Rick Clark; John Purrier
> Subject: 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
&g
-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.launc
unchpad.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:
n
rom: 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.l
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 wrote:
> On Thu, Feb 24, 2011 at 4:39 PM, Sa
.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 D
(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 wrote:
> This thread seems to be radically messed up, but from where I am sitting it
> certainly doesn't seem like everybody is agre
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 wrote:
> sounds like we agree then. Each service has it's own
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 y
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, r
I'd also like to see it called 'nova'.
On Thu, Feb 24, 2011 at 4:41 PM, Rick Clark wrote:
> 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:
> >>
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
>>
>>
++
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 wr
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 wrote:
>> On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote:
>>> I just don't
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 wrote:
> On Thu, Feb 24, 2011 at 4:06 PM, Eric
On Thu, Feb 24, 2011 at 4:45 PM, John Purrier
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.launch
On Thu, Feb 24, 2011 at 4:39 PM, Sandy Walsh 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
> complica
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/
On Thu, Feb 24, 2011 at 4:06 PM, Eric Day 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
>>
On Thu, Feb 24, 2011 at 4:10 PM, Sandy Walsh 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
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 wor
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 i
unces+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 ...
>
>
On Thu, Feb 24, 2011 at 2:48 PM, Eric Day 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 all
ervices 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+jo
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
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
> 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;
> opensta
Hi Sandy,
This depends on how you deploy client tools. From a package
repo/PPA/PyPi, you can install standalone (this is a packaging
concern). If you want to deploy trunk's version, you'd pull lp:nova
and install just clients/python (or something like that).
I want to make sure folks decouple pac
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 + lic
ark
Subject: Re: [Openstack] Novatools ...
On Thu, Feb 24, 2011 at 1:00 PM, Eric Day 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 euc
On Thu, Feb 24, 2011 at 1:49 PM, Sandy Walsh 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
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
On Thu, Feb 24, 2011 at 1:00 PM, Eric Day 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 utt
+10 for lowercase.
On Thu, Feb 24, 2011 at 12:00 PM, Eric Day 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.
> >Obj
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.
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
>
> -
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
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 als
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
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,
56 matches
Mail list logo
