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
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.
Let me know if there are any questions I didn't answer thoroughly enough.
Looks like a fun project Eric. I only got caught up on the ML this weekend and
I'm behind again already.
Some questions that I jotted down from the previous discussions were:
1. Will broadcast queues be supported?
2.
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
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/*
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.
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
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
I'll throw my hat in the ring for core if deemed worthy.
Soren's point about 1 review day per # core developers was refreshing. I had
previously held back from applying because I was afraid all my time would be
tied up with reviews.
?
From:
I'd like to help out on the review process as per
http://wiki.openstack.org/Governance/Approved/CoreDevProcess
I like quiet walks in the park and black and white movies.
-Sandy
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the
Hi y'all
Like they say The devil is in the details. I'm at the stage where the parent
zones will talk to the child zones and there are some interesting
implementation issues:
Problem 1. I'd like to pass the incoming HTTP Request object along to the
Scheduler so I don't have to remarshall the
Quick question ...
For multi-cluster/zones I have a bunch of commands that need to be exposed to
administrators:
1. CRUD child zones
2. CRUD hosts to a zone
3. CRUD zone host capabilities to a zone
Do you think these belong in the admin-only OpenStack API or only available via
nova-manage?
+1
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of
Eric Day [e...@oddments.org]
Sent: Monday, February 07, 2011 1:35 AM
To: Jay Pipes
Cc:
] on behalf of
Sandy Walsh [sandy.wa...@rackspace.com]
Sent: Monday, January 31, 2011 3:26 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] Multi Clusters in a Region ...
Hi y'all,
Now that the Network and API discussions have settled down a little I thought
I'd kick up the dust again.
I'm
There's no good reason for Nova to have to model an organization internally;
it certainly wouldn't match all the possible org structures available.
+1
From: Devin Carlen devin.car...@gmail.commailto:devin.car...@gmail.com
Date: Thu, 3 Feb 2011 12:02:38 -0800
To: Monsyne Dragon
Hi y'all,
Now that the Network and API discussions have settled down a little I thought
I'd kick up the dust again.
I'm slated to work on the Multi Cluster in a Region BP for Cactus. This also
touches on Zone/Host Capabilities and Distributed Scheduler, so feedback is
important.
, it is currently the Rackspace Cloud API.
Version 1.1 of that API (in Cactus) should have an Openstack namespace
and extensibility.
[...]
Developing an Open Stack Cloud System-level CLI might be a good start ...
As part of the above spec, Sandy Walsh has a new python-cloudservers
library (and accompanying
The nice folks at JetBrains were kind enough to grant OpenStack developers a
free license to PyCharm.
So, if you care to give it a try ...
-S
IMPORTANT: THIS IS TO CERTIFY THE RIGHT TO USE THE JETBRAINS SOFTWARE PRODUCT,
GRANTED BY JETBRAINS S.R.O. UNDER THE TERMS AND CONDITIONS OF THE
201 - 219 of 219 matches
Mail list logo
