Ian Wienand writes:
> On 06/19/2014 01:18 AM, James E. Blair wrote:
>> (This requires tracking a bit more state across allocation runs).
>
> This seems to be the crux of the matter; once we have some state all
> sorts of things become possible.
>
> I've made a proposal in which seems like the mos
On 06/19/2014 01:18 AM, James E. Blair wrote:
(This requires tracking a bit more state across allocation runs).
This seems to be the crux of the matter; once we have some state all
sorts of things become possible.
I've made a proposal in which seems like the most simple place to
start; track i
> On 06/18/2014 03:10 PM, Clark Boylan wrote:
> > We are working on Trusty honest (I just got nodepool to build our
> > first Trusty images), and that solves this problem. There is a bigger
> > underlying issue in that projects should not depend on things like
> > mongodb versions which are not a
- Original Message -
> On Wed, Jun 18, 2014 at 2:44 PM, Eoghan Glynn wrote:
> >
> >
> >> >> >>> If we were to use f20 more widely in the gate (not to entirely
> >> >> >>> supplant precise, more just to split the load more evenly) then
> >> >> >>> would the problem observed tend to natura
On 06/18/2014 03:10 PM, Clark Boylan wrote:
> We are working on Trusty honest (I just got nodepool to build our
> first Trusty images), and that solves this problem. There is a bigger
> underlying issue in that projects should not depend on things like
> mongodb versions which are not available on
On Wed, Jun 18, 2014 at 2:44 PM, Eoghan Glynn wrote:
>
>
>> >> >>> If we were to use f20 more widely in the gate (not to entirely
>> >> >>> supplant precise, more just to split the load more evenly) then
>> >> >>> would the problem observed tend to naturally resolve itself?
>> >> >>
>> >> >> I wou
> >> >>> If we were to use f20 more widely in the gate (not to entirely
> >> >>> supplant precise, more just to split the load more evenly) then
> >> >>> would the problem observed tend to naturally resolve itself?
> >> >>
> >> >> I would be happy to see that, having spent some time on the Fedora
On Wed, Jun 18, 2014 at 9:48 AM, Eoghan Glynn wrote:
>
>
>> On 06/18/2014 05:45 AM, Eoghan Glynn wrote:
>> >
>> >
>> >> On 06/18/2014 06:46 PM, Eoghan Glynn wrote:
>> >>> If we were to use f20 more widely in the gate (not to entirely
>> >>> supplant precise, more just to split the load more evenly
> On 06/18/2014 05:45 AM, Eoghan Glynn wrote:
> >
> >
> >> On 06/18/2014 06:46 PM, Eoghan Glynn wrote:
> >>> If we were to use f20 more widely in the gate (not to entirely
> >>> supplant precise, more just to split the load more evenly) then
> >>> would the problem observed tend to naturally re
Ian Wienand writes:
> but eventually, at 30:1, the fedora node gets dropped
I think the formula at work for deciding if a single marginal node
should be allocated as a precise node is:
(demand_for_precise / total_demand) * available_nodes
Eg, round(20/40*1) = 1 so it's allocated as precise;
On 06/18/2014 05:45 AM, Eoghan Glynn wrote:
>
>
>> On 06/18/2014 06:46 PM, Eoghan Glynn wrote:
>>> If we were to use f20 more widely in the gate (not to entirely
>>> supplant precise, more just to split the load more evenly) then
>>> would the problem observed tend to naturally resolve itself?
>>
> On 06/18/2014 06:46 PM, Eoghan Glynn wrote:
> > If we were to use f20 more widely in the gate (not to entirely
> > supplant precise, more just to split the load more evenly) then
> > would the problem observed tend to naturally resolve itself?
>
> I would be happy to see that, having spent som
On 06/18/2014 06:46 PM, Eoghan Glynn wrote:
> If we were to use f20 more widely in the gate (not to entirely
> supplant precise, more just to split the load more evenly) then
> would the problem observed tend to naturally resolve itself?
I would be happy to see that, having spent some time on the
Hi infra-ninjas,
I missed this thread originally, not previously having been
subscribed to os-infra ML.
So I just wanted to throw out onto the table a (possibly naïve)
alternative way of looking at this issue.
The core problem seems to be that the node allocation algorithm
has a tendency to ske
On 06/18/2014 11:32 AM, Dan Prince wrote:
> Would this fix (or something similar) help nodepool to allocate things
> more efficiently?
>
> https://review.openstack.org/#/c/88223/
That's an interesting approach. Just looping around the same little
test from [1] with 20 nodes across two providers,
On Tue, 2014-06-17 at 17:05 -0400, Sean Dague wrote:
> On 06/17/2014 04:16 PM, Ian Wienand wrote:
> > Hi,
> >
> > I added an item to today's meeting but we didn't get to it.
> >
> > I'd like to bring up the disablement of the F20 based job, disabled in
> > [1] with some discussion in [2].
> >
>
On 06/18/2014 07:05 AM, Sean Dague wrote:
> Because this is the way this degrades when we are using all our quota,
> I'm really wary of adding these back until we discuss the expectations
> here
This seems fair
> We actually had 0 nodes in use or ready of the type at the time.
Firstly I'm trying
On 2014-06-17 17:05:05 -0400 (-0400), Sean Dague wrote:
[...]
> If nodepool (conceptually) filled the longest outstanding requests with
> higher priority, I'd be uber happy. This would also help with more fully
> using our capacity, because the mix of nodes that we need any given hour
> kind of cha
On 06/17/2014 04:16 PM, Ian Wienand wrote:
> Hi,
>
> I added an item to today's meeting but we didn't get to it.
>
> I'd like to bring up the disablement of the F20 based job, disabled in
> [1] with some discussion in [2].
>
> It's unclear to me why there are insufficient Fedora nodes. Is the
>
Hi,
I added an item to today's meeting but we didn't get to it.
I'd like to bring up the disablement of the F20 based job, disabled in
[1] with some discussion in [2].
It's unclear to me why there are insufficient Fedora nodes. Is the
problem that Fedora is booting too slowly compared to other
20 matches
Mail list logo
