Rick Clark wrote:
In Bexar was a feature release. We pushed lots of new features. The
focus of Nova development in Cactus is going to be testing and
stabilization.
I wonder if we shouldn't say consistency, testing and stabilization.
Feature work should be concentrated in areas where the
Hello,
I wonder that deferred project has to submit new blueprint or just changing
Series goal described the below URL.
https://blueprints.launchpad.net/nova/+spec/bexar-migration-live
Please let me know what I should do...
Regards,
Kei Masumoto
-Original Message-
From:
masumo...@nttdata.co.jp wrote:
I wonder that deferred project has to submit new blueprint or just changing
Series goal described the below URL.
https://blueprints.launchpad.net/nova/+spec/bexar-migration-live
Please let me know what I should do...
You should just use the existing deferred
Hello,
We, NTT DATA, also agree with majority of folks.
It's realistic shooting for the the Diablo time frame to have
the new network service.
Here are my suggestions:
- I know that there were several documents on the new network service issue
that were locally exchanged so far.
Why not
I will collect the documents together as you suggest, and I agree that we need
to get the requirements laid out again.
Please subscribe to the blueprint on Launchpad -- that way you will be notified
of updates.
https://blueprints.launchpad.net/nova/+spec/bexar-network-service
Thanks,
Ewan.
In order to bring this discussion to a close and get everyone on the same page
for Cactus development, here is where we have landed:
1. We will *not* be separating the network and volume controllers and API
servers from the Nova project.
2. On-going work to extend the Nova
This has my support. For our time frame and the goal of robustness and
stability for the upcoming release, this is the most reasonable course of
action.
Devin
On Jan 31, 2011, at 10:40 AM, John Purrier wrote:
In order to bring this discussion to a close and get everyone on the same
On Mon, Jan 31, 2011 at 1:42 PM, Devin Carlen devin.car...@gmail.com wrote:
This has my support. For our time frame and the goal of robustness and
stability for the upcoming release, this is the most reasonable course of
action.
Seconded.
-jay
+1
On Jan 31, 2011, at 10:40 AM, John Purrier wrote:
In order to bring this discussion to a close and get everyone on the same
page for Cactus development, here is where we have landed:
1. We will *not* be separating the network and volume controllers and
API servers from the Nova
I would suggest that the theme(s) for the Cactus release be:
a. Deployability. This includes consistent packaging and deployment tools
support; but also includes good consistent documentation, approachability to
the project (how quickly can a novice get a running system going for proof
of
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.
On Mon, Jan 31, 2011 at 10:40 AM, John Purrier j...@openstack.org wrote:
In order to bring this discussion to a close and get everyone on the same
page for Cactus development, here is where we have landed:
1. We will **not** be separating the network and volume controllers
and API
John,
I would agree with putting deployability at the top of the list. Right now, it
is operational from a developers point of view. I think a true operations team
would struggle supporting it at scale.
A change I might suggest in priority is moving the API up in the list. While
the OS API is
13 matches
Mail list logo
