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
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 painte
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 t
On Thu, Sep 04, 2014 at 05:27:06PM +, Alessandro Pilotti wrote:
> This means that if we reach a point in which we agree to spin off the drivers
> in
> separate core projects, we need to consider how driver related CIs will be
> still
> included in the Nova review process, possibly with voting
On Wed, Sep 10, 2014 at 12:41:44PM -0700, Vishvananda Ishaya wrote:
>
> On Sep 5, 2014, at 4:12 AM, Sean Dague 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 mayb
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 Sep 5, 2014, at 4:12 AM, Sean Dague 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 we n
On Sep 4, 2014, at 8:33 AM, Daniel P. Berrange 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 why we nee
On Sep 4, 2014, at 3: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 lo
On 9/8/14, 7:23 PM, "Sylvain Bauza" 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 :
>>
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
wrote:
[Heavy snip
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
wrote:
[Heavy snipping because of length]
The radical (?) sol
>> 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 bonk
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 re
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
a
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
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 rev
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
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 mak
, September 5, 2014 8:07 AM
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 urgen
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, auto
> 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, 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 ment
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 scheduler
>
>
> - 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 fee
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
> -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
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
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
wrote:
[Heavy snipping because of length]
The radical (?) solution to the nova core team bottleneck is thus
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 schedul
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).
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 da
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 wro
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
On Fri, 5 Sep 2014, Daniel P. Berrange wrote:
I venture to suggest that the reason we care so much about those kind
of things is precisely because of our policy of pulling them in the
tree. Having them in tree means their quality (or not) reflects directly
on the project as a whole. Separate the
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 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
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" wrote:
> >>>
> >>> - A fairly significant amount o
On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
> On 09/04/2014 12:24 PM, 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 ta
On Fri, Sep 05, 2014 at 12:40:59PM +0200, Nikola Đipanov wrote:
> On 09/04/2014 12:24 PM, Daniel P. Berrange 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 o
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" wrote:
>>>
>>> - A fairly significant amount of nova code would need to be
>>>considered semi-stable API. Certainl
On Fri, Sep 05, 2014 at 11:29:43AM +0100, John Garbutt wrote:
> On 4 September 2014 23:48, Russell Bryant 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 be better of
On 09/04/2014 07:22 PM, Michael Still wrote:
> On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange
> 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
>> pr
On 09/05/2014 01:26 AM, Jay Pipes 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 between Dan's propo
On 5 September 2014 00:26, Jay Pipes 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 between Dan
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
>> wrote:
>>
>> [Heavy snipping because of length]
>>
>>> The radical (?) solution to the nova core team bottleneck is thus to
>>> follow this lead a
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
> 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
On 09/04/2014 12:24 PM, 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 4 September 2014 23:48, 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
>> steps are no
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" wrote:
> >
> > - A fairly significant amount of nova code would need to be
> >considered semi-stable API. Certainly everything under nova/virt
> >and any object wh
On Thu, 4 Sep 2014 12:57:57 -0700
Joe Gordon 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 any rough number
On Thu, 4 Sep 2014 11:24:29 +0100
"Daniel P. Berrange" 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 APIs would h
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
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
> wrote:
> > Proposal / solution
> > ===
> >
> > In the past Nova has spun out its volume layer to form the cinder
> > project. The Neutron project started as an attempt
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 mov
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
> wrote:
> > Proposal / solution
> > ===
> >
> > In the past Nova has spun out its volume layer to form the cinder
> > project. The Neutron project started as an atte
Le 05/09/2014 01:22, Michael Still a écrit :
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange 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 deleg
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 th
On Thu, Sep 4, 2014 at 4:32 PM, Jay Pipes wrote:
>
>
> 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 t
- 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..
>
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
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 featu
On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange 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 new dedicated tea
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 r
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 Thu, Sep 4, 2014 at 3: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
On Thu, Sep 4, 2014 at 5: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 l
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 cohesion
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 having
On Thu, Sep 04, 2014 at 05:11:22PM +0100, Duncan Thomas wrote:
> On 4 September 2014 16:00, Solly Ross 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
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 4 September 2014 16:00, Solly Ross 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 particu
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
:19 AM
To: OpenStack 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
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
+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 having a more focused teams.
IMO, we will stiil have to
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
>
D Dugger"
To: "Daniel P. Berrange" , "OpenStack Development Mailing List
(not for usage questions)"
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 s
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 t
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
Large Crisis'. A large crisis requires a large
> plan.
Ha!
- Original Message -
> From: "Donald D Dugger"
> To: "Daniel P. Berrange" , "OpenStack Development
> Mailing List (not for usage questions)"
>
> Sent: Thursday, September 4, 201
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 the time to read & give feedback
> My only ques
ct: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt
drivers
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
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 p
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.
bility.
> > -Original Message-
> > From: Daniel P. Berrange [mailto:berra...@redhat.com]
> > Sent: 04 September 2014 11:24
> > To: OpenStack Development
> > Subject: [openstack-dev] [nova] Averting the Nova crisis by splitting out
> > virt
> > drivers
>
ember 2014 11:24
> To: OpenStack Development
> Subject: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt
> drivers
>
> Position statement
> ==
>
> Over the past year I've increasingly come to the conclusion that Nova is
> heading for (or
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 non-trivial amount of talent, both regular code contributors an
88 matches
Mail list logo
