On 2014/03/02 00:21, Robert Collins wrote:
[snip]
However me and Robert, we look to have different opinions on what
'homogeneous' means in our context. I think we should clarify that.
So I think my point is more this:
- either this iteration is entirely limited to homogeneous hardware,
in
On 2014/03/02 12:23, Tomas Sedovic wrote:
My apologies for firing this off and then hiding under the FOSDEM rock.
In light of the points raised by Devananda and Robert, I no longer think
fiddling with the scheduler is the way to go.
Note this was never intended to break/confuse all TripleO use
Hello,
+1 to 'let's work towards having a single Node Profile (flavor)
associated with each Deployment Role (pages 12 & 13 of the latest
mockups[1])'
Good start.
We could have also more flavors per role now, user just would have to be
advised: "You are using one image for multiple hardware,
My apologies for firing this off and then hiding under the FOSDEM rock.
In light of the points raised by Devananda and Robert, I no longer think
fiddling with the scheduler is the way to go.
Note this was never intended to break/confuse all TripleO users -- I
considered it a cleaner equivalen
> On 1 February 2014 10:03, Tzu-Mainn Chen wrote:
> > So after reading the replies on this thread, it seems like I (and others
> > advocating
> > a custom scheduler) may have overthought things a bit. The reason this
> > route was
> > suggested was because of conflicting goals for Icehouse:
> >
>
On 3 February 2014 08:45, Jaromir Coufal wrote:
>
>> However, taking a step back, maybe the real answer is:
>>
>> a) homogeneous nodes
>> b) document. . .
>> - **unsupported** means of "demoing" Tuskar (set node attributes to
>> match flavors, hack
>> the scheduler, etc)
>
> Why are peo
Excerpts from Jaromir Coufal's message of 2014-02-02 11:19:25 -0800:
> On 2014/30/01 23:33, Devananda van der Veen wrote:
> > I was responding based on "Treat similar hardware configuration as
> > equal". When there is a very minor difference in hardware (eg, 1TB vs
> > 1.1TB disks), enrolling them
On 2014/31/01 22:03, Tzu-Mainn Chen wrote:
So after reading the replies on this thread, it seems like I (and others
advocating
a custom scheduler) may have overthought things a bit. The reason this route
was
suggested was because of conflicting goals for Icehouse:
a) homogeneous nodes (to si
On 2014/30/01 21:28, Robert Collins wrote:
On 30 January 2014 23:26, Tomas Sedovic wrote:
Hi all,
I've seen some confusion regarding the homogenous hardware support as the
first step for the tripleo UI. I think it's time to make sure we're all on
the same page.
Here's what I think is not cont
On 1 February 2014 10:03, Tzu-Mainn Chen wrote:
> So after reading the replies on this thread, it seems like I (and others
> advocating
> a custom scheduler) may have overthought things a bit. The reason this route
> was
> suggested was because of conflicting goals for Icehouse:
>
> a) homogene
On 2014/30/01 23:33, Devananda van der Veen wrote:
I was responding based on "Treat similar hardware configuration as
equal". When there is a very minor difference in hardware (eg, 1TB vs
1.1TB disks), enrolling them with the same spec (1TB disk) is sufficient
to solve all these issues and mask t
On 2014/30/01 19:29, Tzu-Mainn Chen wrote:
Wouldn't lying about the hardware specs when registering nodes be
problematic for upgrades? Users would have
to re-register their nodes.
+1 for problematic area here
One reason why a custom filter feels attractive is that it provides us
with a clear
On 2014/30/01 12:59, Ladislav Smola wrote:
> On 01/30/2014 12:39 PM, Jiří Stránský wrote:
>> On 01/30/2014 11:26 AM, Tomas Sedovic wrote:
[snip]
> I am for implementing support for Heterogeneous hardware properly,
> lifeless should post what he recommends soon, so I would rather discuss
> that.
On Fri, Jan 31, 2014 at 1:03 PM, Tzu-Mainn Chen wrote:
> So after reading the replies on this thread, it seems like I (and others
> advocating
> a custom scheduler) may have overthought things a bit. The reason this
> route was
> suggested was because of conflicting goals for Icehouse:
>
> a) ho
So after reading the replies on this thread, it seems like I (and others
advocating
a custom scheduler) may have overthought things a bit. The reason this route
was
suggested was because of conflicting goals for Icehouse:
a) homogeneous nodes (to simplify requirements)
b) support diverse hardwa
On 30/01/14 16:14 -0500, Tzu-Mainn Chen wrote:
Thanks for the reply! So if I understand correctly, the proposal is for:
Icehouse: one flavor per service role, so nodes are homogeneous per role
J: multiple flavors per service role
That sounds reasonable; the part that gives me pause is when yo
I was responding based on "Treat similar hardware configuration as equal". When
there is a very minor difference in hardware (eg, 1TB vs 1.1TB disks),
enrolling them with the same spec (1TB disk) is sufficient to solve all
these issues and mask the need for multiple flavors, and the hardware
wouldn
Wouldn't lying about the hardware specs when registering nodes be
problematic for upgrades? Users would have
to re-register their nodes.
This was my first impression too, the line "basically lie about the
hardware specs when enrolling them". It feels more wrong to have the
user provide false
- Original Message -
> On 30 January 2014 23:26, Tomas Sedovic wrote:
> > Hi all,
> >
> > I've seen some confusion regarding the homogenous hardware support as the
> > first step for the tripleo UI. I think it's time to make sure we're all on
> > the same page.
> >
> > Here's what I think
On 30 January 2014 23:26, Tomas Sedovic wrote:
> Hi all,
>
> I've seen some confusion regarding the homogenous hardware support as the
> first step for the tripleo UI. I think it's time to make sure we're all on
> the same page.
>
> Here's what I think is not controversial:
>
> 1. Build the UI and
Wouldn't lying about the hardware specs when registering nodes be problematic
for upgrades? Users would have
to re-register their nodes.
One reason why a custom filter feels attractive is that it provides us with a
clear upgrade path:
Icehouse
* nodes are registered with correct attributes
As far as nova-scheduler and Ironic go, I believe this is a solved problem.
Steps are:
- enroll hardware with proper specs (CPU, RAM, disk, etc)
- create flavors based on hardware specs
- scheduler filter matches requests exactly
There are, I suspect, three areas where this would fall short today:
On 30/01/14 15:53, Matt Wagner wrote:
On 1/30/14, 5:26 AM, Tomas Sedovic wrote:
Hi all,
I've seen some confusion regarding the homogenous hardware support as
the first step for the tripleo UI. I think it's time to make sure we're
all on the same page.
Here's what I think is not controversial:
On 1/30/14, 5:26 AM, Tomas Sedovic wrote:
> Hi all,
>
> I've seen some confusion regarding the homogenous hardware support as
> the first step for the tripleo UI. I think it's time to make sure we're
> all on the same page.
>
> Here's what I think is not controversial:
>
> 1. Build the UI and ev
On 01/30/2014 12:39 PM, Jiří Stránský wrote:
On 01/30/2014 11:26 AM, Tomas Sedovic wrote:
1.1 Treat similar hardware configuration as equal
The way I understand it is this: we use a scheduler filter that wouldn't
do a strict match on the hardware in Ironic. E.g. if our baremetal
flavour said 16
On 01/30/2014 11:26 AM, Tomas Sedovic wrote:
1.1 Treat similar hardware configuration as equal
The way I understand it is this: we use a scheduler filter that wouldn't
do a strict match on the hardware in Ironic. E.g. if our baremetal
flavour said 16GB ram and 1TB disk, it would also match a nod
Hi all,
I've seen some confusion regarding the homogenous hardware support as
the first step for the tripleo UI. I think it's time to make sure we're
all on the same page.
Here's what I think is not controversial:
1. Build the UI and everything underneath to work with homogenous
hardware in
27 matches
Mail list logo
