On Thu, Sep 11, 2014 at 02:02:00PM -0400, Dan Prince wrote:
I've always referred to the virt/driver.py API as an internal API
meaning there are no guarantees about it being preserved across
releases. I'm not saying this is correct... just that it is what we've
got. While OpenStack attempts to
On Wed, Sep 10, 2014 at 12:41:44PM -0700, Vishvananda Ishaya wrote:
On Sep 5, 2014, at 4:12 AM, Sean Dague s...@dague.net wrote:
On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
Just some things to think about with regards to the whole idea, by no
means exhaustive.
So maybe the
On Thu, 2014-09-04 at 11:24 +0100, Daniel P. Berrange wrote:
Position statement
==
Over the past year I've increasingly come to the conclusion that
Nova is heading for (or probably already at) a major crisis. If
steps are not taken to avert this, the project is likely to
On 09/11/2014 12:02 PM, Dan Prince wrote:
Maybe I'm impatient (I totally am!) but I see much of the review
slowdown as a result of the feedback loop times increasing over the
years. OpenStack has some really great CI and testing but I think our
focus on not breaking things actually has us
On Sep 4, 2014, at 3:24 AM, Daniel P. Berrange berra...@redhat.com wrote:
Position statement
==
Over the past year I've increasingly come to the conclusion that
Nova is heading for (or probably already at) a major crisis. If
steps are not taken to avert this, the project
On Sep 4, 2014, at 8:33 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Sep 04, 2014 at 01:36:04PM +, Gary Kotton wrote:
Hi,
I do not think that Nova is in a death spiral. I just think that the
current way of working at the moment is strangling the project. I do not
understand
On Sep 5, 2014, at 4:12 AM, Sean Dague s...@dague.net wrote:
On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
Just some things to think about with regards to the whole idea, by no
means exhaustive.
So maybe the better question is: what are the top sources of technical
debt in Nova that
On 2014-09-10 12:19:08 -0700 (-0700), Vishvananda Ishaya wrote:
I don’t think this is a viable option for us, but if we were going
to do it, we would probably be better off using
https://code.google.com/p/rietveld/ as a base, since it is
actually written in python.
The proposal floated in
On 9/8/14, 7:23 PM, Sylvain Bauza sba...@redhat.com wrote:
Le 08/09/2014 18:06, Steven Dake a écrit :
On 09/05/2014 06:10 AM, Sylvain Bauza wrote:
Le 05/09/2014 12:48, Sean Dague a écrit :
On 09/05/2014 03:02 AM, Sylvain Bauza wrote:
Le 05/09/2014 01:22, Michael Still a écrit :
On Thu,
The last few days have been interesting as I watch FFEs come through.
People post explaining their feature, its importance, and the risk
associated with it. Three cores sign on for review. All of the ones
I've looked at have received active review since being posted. Would
it be bonkers to
Le 08/09/2014 18:06, Steven Dake a écrit :
On 09/05/2014 06:10 AM, Sylvain Bauza wrote:
Le 05/09/2014 12:48, Sean Dague a écrit :
On 09/05/2014 03:02 AM, Sylvain Bauza wrote:
Le 05/09/2014 01:22, Michael Still a écrit :
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange
berra...@redhat.com
Le 05/09/2014 01:26, Jay Pipes a écrit :
On 09/04/2014 10:33 AM, Dugger, Donald D wrote:
Basically +1 with what Daniel is saying (note that, as mentioned, a
side effect of our effort to split out the scheduler will help but
not solve this problem).
The difference between Dan's proposal and
Le 05/09/2014 01:22, Michael Still a écrit :
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange berra...@redhat.com wrote:
[Heavy snipping because of length]
The radical (?) solution to the nova core team bottleneck is thus to
follow this lead and split the nova virt drivers out into
On Thu, Sep 04, 2014 at 02:56:04PM -0500, Kyle Mestery wrote:
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange berra...@redhat.com
wrote:
Proposal / solution
===
In the past Nova has spun out its volume layer to form the cinder
project. The Neutron project started as
On Thu, Sep 04, 2014 at 10:44:17PM -0600, John Griffith wrote:
Just some thoughts and observations I've had regarding this topic in Cinder
the past couple of years. I realize this is a Nova thread so hopefully
some of this can be applied in a more general context.
TLDR:
1. I think moving
On Thu, Sep 04, 2014 at 12:57:57PM -0700, Joe Gordon wrote:
On Thu, Sep 4, 2014 at 3:24 AM, Daniel P. Berrange berra...@redhat.com
wrote:
Proposal / solution
===
In the past Nova has spun out its volume layer to form the cinder
project. The Neutron project started as an
On Thu, Sep 04, 2014 at 06:48:33PM -0400, Russell Bryant wrote:
On 09/04/2014 06:24 AM, Daniel P. Berrange wrote:
Position statement
==
Over the past year I've increasingly come to the conclusion that
Nova is heading for (or probably already at) a major crisis. If
On Thu, 4 Sep 2014 11:24:29 +0100
Daniel P. Berrange berra...@redhat.com wrote:
- A fairly significant amount of nova code would need to be
considered semi-stable API. Certainly everything under nova/virt
and any object which is passed in/out of the virt driver API.
Changes to such
On Thu, 4 Sep 2014 12:57:57 -0700
Joe Gordon joe.gord...@gmail.com wrote:
Overall I do think we need to re-think how the review burden is
distributed. That being said, this is a nice proposal but I am not
sure if it moves the review burden around enough or is the right
approach. Do you have
On Fri, Sep 05, 2014 at 07:31:50PM +0930, Christopher Yeoh wrote:
On Thu, 4 Sep 2014 11:24:29 +0100
Daniel P. Berrange berra...@redhat.com wrote:
- A fairly significant amount of nova code would need to be
considered semi-stable API. Certainly everything under nova/virt
and any
On 4 September 2014 23:48, Russell Bryant rbry...@redhat.com wrote:
On 09/04/2014 06:24 AM, Daniel P. Berrange wrote:
Position statement
==
Over the past year I've increasingly come to the conclusion that
Nova is heading for (or probably already at) a major crisis. If
steps
On Thu, Sep 04, 2014 at 06:22:18PM -0500, Michael Still wrote:
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange berra...@redhat.com
wrote:
[Heavy snipping because of length]
The radical (?) solution to the nova core team bottleneck is thus to
follow this lead and split the nova virt
On 5 September 2014 00:26, Jay Pipes jaypi...@gmail.com wrote:
On 09/04/2014 10:33 AM, Dugger, Donald D wrote:
Basically +1 with what Daniel is saying (note that, as mentioned, a
side effect of our effort to split out the scheduler will help but
not solve this problem).
The difference
On Fri, Sep 05, 2014 at 11:29:43AM +0100, John Garbutt wrote:
On 4 September 2014 23:48, Russell Bryant rbry...@redhat.com wrote:
On 09/04/2014 06:24 AM, Daniel P. Berrange wrote:
If we ignored gerrit for a moment, is rapid increase in splitting out
components the ideal workflow? Would we
On 09/05/2014 06:22 AM, Daniel P. Berrange wrote:
On Fri, Sep 05, 2014 at 07:31:50PM +0930, Christopher Yeoh wrote:
On Thu, 4 Sep 2014 11:24:29 +0100
Daniel P. Berrange berra...@redhat.com wrote:
- A fairly significant amount of nova code would need to be
considered semi-stable API.
On Fri, Sep 05, 2014 at 07:00:44AM -0400, Sean Dague wrote:
On 09/05/2014 06:22 AM, Daniel P. Berrange wrote:
On Fri, Sep 05, 2014 at 07:31:50PM +0930, Christopher Yeoh wrote:
On Thu, 4 Sep 2014 11:24:29 +0100
Daniel P. Berrange berra...@redhat.com wrote:
- A fairly significant amount
On Fri, Sep 05, 2014 at 07:12:37AM -0400, Sean Dague wrote:
On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
A handy example of this I can think of is the currently granted FFE for
serial consoles - consider how much of the code went into the common
part vs. the libvirt specific part, I would
On 09/05/2014 07:26 AM, Daniel P. Berrange wrote:
On Fri, Sep 05, 2014 at 07:00:44AM -0400, Sean Dague wrote:
On 09/05/2014 06:22 AM, Daniel P. Berrange wrote:
On Fri, Sep 05, 2014 at 07:31:50PM +0930, Christopher Yeoh wrote:
On Thu, 4 Sep 2014 11:24:29 +0100
Daniel P. Berrange
On 09/05/2014 07:40 AM, Daniel P. Berrange wrote:
On Fri, Sep 05, 2014 at 07:12:37AM -0400, Sean Dague wrote:
On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
A handy example of this I can think of is the currently granted FFE for
serial consoles - consider how much of the code went into the
On Fri, Sep 05, 2014 at 07:49:04AM -0400, Sean Dague wrote:
On 09/05/2014 07:26 AM, Daniel P. Berrange wrote:
On Fri, Sep 05, 2014 at 07:00:44AM -0400, Sean Dague wrote:
On 09/05/2014 06:22 AM, Daniel P. Berrange wrote:
On Fri, Sep 05, 2014 at 07:31:50PM +0930, Christopher Yeoh wrote:
On
Daniel P. Berrange wrote:
For a long time I've use the LKML 'subsystem maintainers' model as the
reference point for ideas. In a more LKML like model, each virt team
(or other subsystem team) would have their own separate GIT repo with
a complete Nova codebase, where they did they day to day
On 09/05/2014 02:59 AM, Sylvain Bauza wrote:
Le 05/09/2014 01:26, Jay Pipes a écrit :
On 09/04/2014 10:33 AM, Dugger, Donald D wrote:
Basically +1 with what Daniel is saying (note that, as mentioned, a
side effect of our effort to split out the scheduler will help but
not solve this problem).
Le 05/09/2014 14:48, Jay Pipes a écrit :
On 09/05/2014 02:59 AM, Sylvain Bauza wrote:
Le 05/09/2014 01:26, Jay Pipes a écrit :
On 09/04/2014 10:33 AM, Dugger, Donald D wrote:
Basically +1 with what Daniel is saying (note that, as mentioned, a
side effect of our effort to split out the
Le 05/09/2014 12:48, Sean Dague a écrit :
On 09/05/2014 03:02 AM, Sylvain Bauza wrote:
Le 05/09/2014 01:22, Michael Still a écrit :
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange
berra...@redhat.com wrote:
[Heavy snipping because of length]
The radical (?) solution to the nova core
On 09/05/2014 08:58 AM, Sylvain Bauza wrote:
Le 05/09/2014 14:48, Jay Pipes a écrit :
On 09/05/2014 02:59 AM, Sylvain Bauza wrote:
Le 05/09/2014 01:26, Jay Pipes a écrit :
On 09/04/2014 10:33 AM, Dugger, Donald D wrote:
Basically +1 with what Daniel is saying (note that, as mentioned, a
side
-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: 05 September 2014 11:49
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out
virt drivers
On 09/05/2014 03:02 AM, Sylvain Bauza wrote:
Ahem
Le 05/09/2014 15:11, Jay Pipes a écrit :
On 09/05/2014 08:58 AM, Sylvain Bauza wrote:
Le 05/09/2014 14:48, Jay Pipes a écrit :
On 09/05/2014 02:59 AM, Sylvain Bauza wrote:
Le 05/09/2014 01:26, Jay Pipes a écrit :
On 09/04/2014 10:33 AM, Dugger, Donald D wrote:
Basically +1 with what Daniel
- Each virt driver project gets its own core team and is responsible
for dealing with review, merge release of their codebase.
Note, I really do mean *all* virt drivers should be separate. I do
not want to see some virt drivers split out and others remain in tree
because I feel that
On 09/05/2014 06:29 AM, John Garbutt wrote:
Scheduler: I think we need to split out the scheduler with a similar
level of urgency. We keep blocking features on the split, because we
know we don't have the review bandwidth to deal with them. Right now I
am talking about a compute related
On Fri, 2014-09-05 at 10:26 +0100, Daniel P. Berrange wrote:
2. Removal of drivers other than the reference implementation for each
project could be the healthiest option
a. Requires transparent, public, automated 3'rd party CI
b. Requires a TRUE plugin architecture and mentality
I look at what we do with Ironic testing current as a guide here.
We have tempest job that runs against Nova, that validates changes
to nova don't break the separate Ironic git repo. So my thought
is that all our current tempest jobs would simply work in that
way. IOW changes to so called
On Fri, Sep 05, 2014 at 10:25:09AM -0500, Kevin L. Mitchell wrote:
On Fri, 2014-09-05 at 10:26 +0100, Daniel P. Berrange wrote:
2. Removal of drivers other than the reference implementation for each
project could be the healthiest option
a. Requires transparent, public, automated
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out
virt drivers
On 09/05/2014 06:29 AM, John Garbutt wrote:
Scheduler: I think we need to split out the scheduler with a similar
level of urgency. We keep blocking features on the split
On 09/05/2014 03:52 AM, Daniel P. Berrange wrote:
So my biggest fear with a model where each team had their own full
Nova tree and did large pull requests, is that we'd suffer major
pain during the merging of large pull requests, especially if any
of the merges touched common code. It could
On 09/05/2014 10:06 AM, Jay Pipes wrote:
On 09/05/2014 06:29 AM, John Garbutt wrote:
Scheduler: I think we need to split out the scheduler with a similar
level of urgency. We keep blocking features on the split, because we
know we don't have the review bandwidth to deal with them. Right now I
On 09/05/2014 03:01 PM, Russell Bryant wrote:
On 09/05/2014 10:06 AM, Jay Pipes wrote:
On 09/05/2014 06:29 AM, John Garbutt wrote:
Scheduler: I think we need to split out the scheduler with a similar
level of urgency. We keep blocking features on the split, because we
know we don't have the
On Fri, 2014-09-05 at 08:02 -0400, Sean Dague wrote:
On 09/05/2014 07:40 AM, Daniel P. Berrange wrote:
On Fri, Sep 05, 2014 at 07:12:37AM -0400, Sean Dague wrote:
On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
A handy example of this I can think of is the currently granted FFE for
serial
Daniel,
Thanks for the well thought out and thorough proposal to help Nova.
As an OpenStack operator/developer since Cactus time, it has definitely
gotten harder and harder to get fixes in Nova for small bugs that we find
running at scale with production systems. This forces us to maintain more
On Fri, 2014-09-05 at 14:14 +0200, Thierry Carrez wrote:
Daniel P. Berrange wrote:
For a long time I've use the LKML 'subsystem maintainers' model as the
reference point for ideas. In a more LKML like model, each virt team
(or other subsystem team) would have their own separate GIT repo
Hi Daniel,
Thanks for putting together such a thoughtful piece - I probably need to
re-read it few times to take in everything you're saying, but a couple of
thoughts that did occur to me:
- I can see how this could help where a change is fully contained within a virt
driver, but I wonder
On Thu, Sep 04, 2014 at 12:14:39PM +, Day, Phil wrote:
Hi Daniel,
Thanks for putting together such a thoughtful piece - I probably need to
re-read it few times to take in everything you're saying, but a couple
of thoughts that did occur to me:
- I can see how this could help where a
Like I mentioned before, I think the only way out of the Nova death
spiral is to split code and give control over it to smaller dedicated
review teams. This is one way to do it. Thanks Dan for pulling this
together :)
A couple comments inline:
Daniel P. Berrange wrote:
[...]
This is a crisis.
Hi,
I do not think that Nova is in a death spiral. I just think that the
current way of working at the moment is strangling the project. I do not
understand why we need to split drivers out of the core project. Why not
have the ability to provide Œcore review¹ status to people for reviewing
those
Basically +1 with what Daniel is saying (note that, as mentioned, a side effect
of our effort to split out the scheduler will help but not solve this problem).
My only question is about the need to separate out each virt driver into a
separate project, wouldn't you accomplish a lot of the
Dugger donald.d.dug...@intel.com
To: Daniel P. Berrange berra...@redhat.com, OpenStack Development
Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Thursday, September 4, 2014 10:33:27 AM
Subject: Re: [openstack-dev] [nova] Averting the Nova crisis by splitting
Le 04/09/2014 15:36, Gary Kotton a écrit :
Hi,
I do not think that Nova is in a death spiral. I just think that the
current way of working at the moment is strangling the project. I do not
understand why we need to split drivers out of the core project. Why not
have the ability to provide Œcore
On 9/4/2014 9:57 AM, Daniel P. Berrange wrote:
On Thu, Sep 04, 2014 at 02:33:27PM +, Dugger, Donald D wrote:
Basically +1 with what Daniel is saying (note that, as mentioned,
a side effect of our effort to split out the scheduler will help
but not solve this problem).
Thanks for taking
Mailing List
(not for usage questions)
openstack-dev@lists.openstack.org
Sent: Thursday, September 4, 2014 10:33:27 AM
Subject: Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out
virt drivers
Basically +1 with what Daniel is saying (note that, as mentioned, a side
effect of our
On Thu, Sep 04, 2014 at 10:18:04AM -0500, Matt Riedemann wrote:
- Changes submitted to nova common code would trigger running of CI
tests against the external virt drivers. Each virt driver core team
would decide whether they want their driver to be tested upon Nova
common
On Thu, Sep 04, 2014 at 01:36:04PM +, Gary Kotton wrote:
Hi,
I do not think that Nova is in a death spiral. I just think that the
current way of working at the moment is strangling the project. I do not
understand why we need to split drivers out of the core project. Why not
have the
Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out
virt drivers
Le 04/09/2014 17:00, Solly Ross a écrit :
My only question is about the need to separate out each virt driver
into a separate project, wouldn't you
On Thu, Sep 04, 2014 at 03:49:26PM +, Dugger, Donald D wrote:
Actually, I think Sylvain's point is even stronger as I don't think
splitting the virt drivers out of Nova is a complete fix. It may
solve the review latency for the virt driver area but, unless virt
drivers are the bulk of
On 4 September 2014 16:00, Solly Ross sr...@redhat.com wrote:
My only question is about the need to separate out each virt driver into a
separate project, wouldn't you
accomplish a lot of the benefit by creating a single virt project that
includes all of the drivers?
I don't think there's
Le 04/09/2014 17:57, Daniel P. Berrange a écrit :
On Thu, Sep 04, 2014 at 03:49:26PM +, Dugger, Donald D wrote:
Actually, I think Sylvain's point is even stronger as I don't think
splitting the virt drivers out of Nova is a complete fix. It may
solve the review latency for the virt driver
On Thu, Sep 04, 2014 at 05:11:22PM +0100, Duncan Thomas wrote:
On 4 September 2014 16:00, Solly Ross sr...@redhat.com wrote:
My only question is about the need to separate out each virt driver into a
separate project, wouldn't you
accomplish a lot of the benefit by creating a single virt
On 09/04/2014 11:32 AM, Vladik Romanovsky wrote:
+1
I very much agree with Dan's the propsal.
I am concerned about difficulties we will face with merging
patches that spreads accross various regions: manager, conductor, scheduler,
etc..
However, I think, this is a small price to pay for
Hi all,
This is an issue that has been discussed quite a few times. As I was fearing the
bottleneck effect is getting worse with each release.
Nova grew simply too much and even though features like networking and block
storage have been spun off at some point in time, it still lacks the
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange berra...@redhat.com wrote:
Position statement
==
Over the past year I've increasingly come to the conclusion that
Nova is heading for (or probably already at) a major crisis. If
steps are not taken to avert this, the project
On Thu, Sep 4, 2014 at 3:24 AM, Daniel P. Berrange berra...@redhat.com
wrote:
Position statement
==
Over the past year I've increasingly come to the conclusion that
Nova is heading for (or probably already at) a major crisis. If
steps are not taken to avert this, the project
On 09/04/2014 06:24 AM, Daniel P. Berrange wrote:
Position statement
==
Over the past year I've increasingly come to the conclusion that
Nova is heading for (or probably already at) a major crisis. If
steps are not taken to avert this, the project is likely to loose
a
On 09/04/2014 09:36 AM, Gary Kotton wrote:
Hi,
I do not think that Nova is in a death spiral. I just think that the
current way of working at the moment is strangling the project. I do not
understand why we need to split drivers out of the core project. Why not
have the ability to provide Œcore
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange berra...@redhat.com wrote:
[Heavy snipping because of length]
The radical (?) solution to the nova core team bottleneck is thus to
follow this lead and split the nova virt drivers out into separate
projects and delegate their maintainence to
On 09/04/2014 10:33 AM, Dugger, Donald D wrote:
Basically +1 with what Daniel is saying (note that, as mentioned, a
side effect of our effort to split out the scheduler will help but
not solve this problem).
The difference between Dan's proposal and the Gantt split is that Dan's
proposal
On 09/04/2014 12:11 PM, Duncan Thomas wrote:
I think that having a shared review team across all of the drivers
has definite benefits in terms of coherency and consistency - it is
very easy for experts on one technology to become tunnel-visioned on
some points and miss the wider, cross project
- Original Message -
On 09/04/2014 11:32 AM, Vladik Romanovsky wrote:
+1
I very much agree with Dan's the propsal.
I am concerned about difficulties we will face with merging
patches that spreads accross various regions: manager, conductor,
scheduler, etc..
However, I
75 matches
Mail list logo
