Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Nisha Agarwal]

Hi John,

>@Nisha I think that should largely allow you to construct the same
behavior you have today, or am I totally missing what you are wanting to do?

Yes, i agree that qualitative capabilities are covered by your spec and
will give us the behaviour as its today with your spec implemented.


Regards
Nisha

On Fri, Oct 27, 2017 at 8:12 AM, Ed Leafe  wrote:

> On Oct 26, 2017, at 6:57 PM, Wan-yen Hsu  wrote:
>
> > In Nisha's message, "capabilities" refers to
> "ComputeCapabilitiesFilter".   "capabilities" provides a lot of flexibility
> for scheduling.  It supports qualitative as well as quantitative
> attributes.  It supports a variety of operators such as ">=", "<", "=",
> etc.   For instance, with "capabilities", one can create a flavor for
> "GPU_Count >=2".  Quantity matters for workloads.  A workload may require
> at least 2GPUs or at least certain amount of SSD capacity to meet the
> performance requirements.   Trait will help but it only supports
> qualitative attributes.  Therefore, we still need "capabilities".
>
> In your example, you would create a resource class that specifies the
> number of GPUs. If there is a machine with no GPU, it would be a different
> resource class than a machine with a GPU. Likewise, a machine with 2 GPUs
> would be a different class. This gives you the ability to match the request
> to the need. Saying you need a machine with at least 2 GPUs means that you
> could end up with a machine with 100 GPUs - ok, I know that's not
> realistic, but it illustrates my point. Each hardware combination is a
> separate resource class. If your workload requires 2 GPUs and SSD, there
> are a finite number of hardware combinations available. You pick the flavor
> (i.e., resource class) that matches your need.
>
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Ed Leafe]

On Oct 26, 2017, at 6:57 PM, Wan-yen Hsu  wrote:

> In Nisha's message, "capabilities" refers to "ComputeCapabilitiesFilter".   
> "capabilities" provides a lot of flexibility for scheduling.  It supports 
> qualitative as well as quantitative attributes.  It supports a variety of 
> operators such as ">=", "<", "=", etc.   For instance, with "capabilities", 
> one can create a flavor for "GPU_Count >=2".  Quantity matters for workloads. 
>  A workload may require at least 2GPUs or at least certain amount of SSD 
> capacity to meet the performance requirements.   Trait will help but it only 
> supports qualitative attributes.  Therefore, we still need "capabilities".

In your example, you would create a resource class that specifies the number of 
GPUs. If there is a machine with no GPU, it would be a different resource class 
than a machine with a GPU. Likewise, a machine with 2 GPUs would be a different 
class. This gives you the ability to match the request to the need. Saying you 
need a machine with at least 2 GPUs means that you could end up with a machine 
with 100 GPUs - ok, I know that's not realistic, but it illustrates my point. 
Each hardware combination is a separate resource class. If your workload 
requires 2 GPUs and SSD, there are a finite number of hardware combinations 
available. You pick the flavor (i.e., resource class) that matches your need.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Wan-yen Hsu]

In Nisha's message, "capabilities" refers to "ComputeCapabilitiesFilter".
 "capabilities" provides a lot of flexibility for scheduling.  It supports
qualitative as well as quantitative attributes.  It supports a variety of
operators such as ">=", "<", "=", etc.   For instance, with "capabilities",
one can create a flavor for "GPU_Count >=2".  Quantity matters for
workloads.  A workload may require at least 2GPUs or at least certain
amount of SSD capacity to meet the performance requirements.   Trait will
help but it only supports qualitative attributes.  Therefore, we still need
"capabilities".

Standard Resource Class represents quantitative things but it 's not
available for Ironic.   Ironic currently can only use one single
CUSTOM_Resource_class with exact match.  Prior to Pike, Ironic customers
can use  non-exact match filter to support the use case of "at least this
amount of quantitative things on a bare metal node" but it's not supported
by Ironic Custom_resource_class.  Therefore it is a regression and will
cause issues for those who are depending on it.

On 19 October 2017 at 15:38, Jay Pipes  wrote:

> On 10/16/2017 05:31 AM, Nisha Agarwal wrote:
>
>> Hi Matt,
>>
>> As i understand John's spec https://review.openstack.org/#/c/507052/ <
>> https://review.openstack.org/#/c/507052/>, it is actually a replacement
>> for capabilities(qualitative only) for ironic. It doesnt cover the
>> quantitative capabilities as 'traits' are meant only for qualitative
>> capabilities. Quantitative capabilities are covered by resource classes in
>> Nova. We have few (one or two) quantitative capabilities already supported
>> in ironic.
>>
>
> Hi Nisha,
>
> This may be a case of mixed terminology. We do not refer to anything
> quantitative as a "capability". Rather, we use the term "resource class"
> (or sometimes just "resource") to represent quantitative things that may be
> consumed by the instance.
>
> Traits, on the other hand, are qualitative. They represent a binary on/off
> capability that the compute host (or baremetal node in the case of Ironic)
> exposes.
>
> There's no limit on the number of traits that may be associated with a
> particular Ironic baremetal node. However, for Ironic baremetal nodes, if
> the node.resource_class attribute is set, the Nova Ironic virt driver will
> create a single inventory record for the node containing a quantity of 1
> and a resource class equal to whatever is in the node.resource_class
> attribute. This resource class is auto-created by Nova as a custom resource
> class.
>

Just to follow up on this one...

I hope my traits spec will replace the need for the non-exact filters.

Consider two flavors Gold and Gold_Plus. Lets say Gold_plus gives you a
slightly newer CPU, or something.

Consider this setup:

* both GOLD and GOLD_PLUS ironic nodes have Resource Class: CUSTOM_GOLD
* but you can have some have trait: GOLD_REGULAR and some with GOLD_PLUS

Now you can have the flavors:

* GOLD flavor requests resources:CUSTOM_GOLD=1
* GOLD_PLUS flavor also has resources:CUSTOM_GOLD=1 but also
trait:GOLD_PLUS:requires

Now eventually we could modify the GOLD flavor to say:

* resources:CUSTOM_GOLD=1 and trait:GOLD_REGULAR:prefer

@Nisha I think that should largely allow you to construct the same behavior
you have today, or am I totally missing what you are wanting to do?

On Thu, Oct 19, 2017 at 8:37 AM, John Garbutt  wrote:

> On 19 October 2017 at 15:38, Jay Pipes  wrote:
>
>> On 10/16/2017 05:31 AM, Nisha Agarwal wrote:
>>
>>> Hi Matt,
>>>
>>> As i understand John's spec https://review.openstack.org/#/c/507052/ <
>>> https://review.openstack.org/#/c/507052/>, it is actually a replacement
>>> for capabilities(qualitative only) for ironic. It doesnt cover the
>>> quantitative capabilities as 'traits' are meant only for qualitative
>>> capabilities. Quantitative capabilities are covered by resource classes in
>>> Nova. We have few (one or two) quantitative capabilities already supported
>>> in ironic.
>>>
>>
>> Hi Nisha,
>>
>> This may be a case of mixed terminology. We do not refer to anything
>> quantitative as a "capability". Rather, we use the term "resource class"
>> (or sometimes just "resource") to represent quantitative things that may be
>> consumed by the instance.
>>
>> Traits, on the other hand, are qualitative. They represent a binary
>> on/off capability that the compute host (or baremetal node in the case of
>> Ironic) exposes.
>>
>> There's no limit on the number of traits that may be associated with a
>> particular Ironic baremetal node. However, for Ironic baremetal nodes, if
>> the node.resource_class attribute is set, the Nova Ironic virt driver will
>> create a single inventory record for the node containing a quantity of 1
>> and a resource class equal to whatever is in the node.resource_class
>> attribute. This resource class is auto-created by Nova as a custom resource
>> class.
>>
>
> Just to 

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[John Garbutt]

On 19 October 2017 at 15:38, Jay Pipes  wrote:

> On 10/16/2017 05:31 AM, Nisha Agarwal wrote:
>
>> Hi Matt,
>>
>> As i understand John's spec https://review.openstack.org/#/c/507052/ <
>> https://review.openstack.org/#/c/507052/>, it is actually a replacement
>> for capabilities(qualitative only) for ironic. It doesnt cover the
>> quantitative capabilities as 'traits' are meant only for qualitative
>> capabilities. Quantitative capabilities are covered by resource classes in
>> Nova. We have few (one or two) quantitative capabilities already supported
>> in ironic.
>>
>
> Hi Nisha,
>
> This may be a case of mixed terminology. We do not refer to anything
> quantitative as a "capability". Rather, we use the term "resource class"
> (or sometimes just "resource") to represent quantitative things that may be
> consumed by the instance.
>
> Traits, on the other hand, are qualitative. They represent a binary on/off
> capability that the compute host (or baremetal node in the case of Ironic)
> exposes.
>
> There's no limit on the number of traits that may be associated with a
> particular Ironic baremetal node. However, for Ironic baremetal nodes, if
> the node.resource_class attribute is set, the Nova Ironic virt driver will
> create a single inventory record for the node containing a quantity of 1
> and a resource class equal to whatever is in the node.resource_class
> attribute. This resource class is auto-created by Nova as a custom resource
> class.
>

Just to follow up on this one...

I hope my traits spec will replace the need for the non-exact filters.

Consider two flavors Gold and Gold_Plus. Lets say Gold_plus gives you a
slightly newer CPU, or something.

Consider this setup:

* both GOLD and GOLD_PLUS ironic nodes have Resource Class: CUSTOM_GOLD
* but you can have some have trait: GOLD_REGULAR and some with GOLD_PLUS

Now you can have the flavors:

* GOLD flavor requests resources:CUSTOM_GOLD=1
* GOLD_PLUS flavor also has resources:CUSTOM_GOLD=1 but also
trait:GOLD_PLUS:requires

Now eventually we could modify the GOLD flavor to say:

* resources:CUSTOM_GOLD=1 and trait:GOLD_REGULAR:prefer

@Nisha I think that should largely allow you to construct the same behavior
you have today, or am I totally missing what you are wanting to do?

Thanks,
John
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Jay Pipes]

On 10/16/2017 05:31 AM, Nisha Agarwal wrote:

Hi Matt,

As i understand John's spec https://review.openstack.org/#/c/507052/ 
, it is actually a replacement 
for capabilities(qualitative only) for ironic. It doesnt cover the 
quantitative capabilities as 'traits' are meant only for qualitative 
capabilities. Quantitative capabilities are covered by resource classes 
in Nova. We have few (one or two) quantitative capabilities already 
supported in ironic.


Hi Nisha,

This may be a case of mixed terminology. We do not refer to anything 
quantitative as a "capability". Rather, we use the term "resource class" 
(or sometimes just "resource") to represent quantitative things that may 
be consumed by the instance.


Traits, on the other hand, are qualitative. They represent a binary 
on/off capability that the compute host (or baremetal node in the case 
of Ironic) exposes.


There's no limit on the number of traits that may be associated with a 
particular Ironic baremetal node. However, for Ironic baremetal nodes, 
if the node.resource_class attribute is set, the Nova Ironic virt driver 
will create a single inventory record for the node containing a quantity 
of 1 and a resource class equal to whatever is in the 
node.resource_class attribute. This resource class is auto-created by 
Nova as a custom resource class.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Nisha Agarwal]

Hi Matt,

As i understand John's spec https://review.openstack.org/#/c/507052/, it is
actually a replacement for capabilities(qualitative only) for ironic. It
doesnt cover the quantitative capabilities as 'traits' are meant only for
qualitative capabilities. Quantitative capabilities are covered by resource
classes in Nova. We have few (one or two) quantitative capabilities already
supported in ironic.

Regards
Nisha

On Thu, Oct 5, 2017 at 9:09 PM, Matt Riedemann  wrote:

> On 9/7/2017 2:48 PM, Nisha Agarwal wrote:
>
>> Hi Ironic Operators,
>>
>>  From Pike, ironic nodes get scheduled based on just the resource class
>> from nova. Do you guys see any concerns over this "rigid resource class
>> only ironic scheduling"?
>>
>> To be more specific, at your datacentre/production environment what all
>> filters are configured in nova.conf (configuration file for nova) for
>> scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in
>> the "use_baremetal_filters" for ironic nodes scheduling from nova?
>>
>> Thanks and Regards
>> Nisha
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> Bringing this back up.
>
> Does this nova spec from John Garbutt help you?
>
> https://review.openstack.org/#/c/507052/
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Matt Riedemann]

On 9/7/2017 2:48 PM, Nisha Agarwal wrote:

Hi Ironic Operators,

 From Pike, ironic nodes get scheduled based on just the resource class 
from nova. Do you guys see any concerns over this "rigid resource class 
only ironic scheduling"?


To be more specific, at your datacentre/production environment what all 
filters are configured in nova.conf (configuration file for nova) for 
scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in 
the "use_baremetal_filters" for ironic nodes scheduling from nova?


Thanks and Regards
Nisha



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Bringing this back up.

Does this nova spec from John Garbutt help you?

https://review.openstack.org/#/c/507052/

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Wan-yen Hsu]

>>* Nisha is raising the question about whether or not we're making
*>>* incorrect assumptions about how people are using nova/ironic and they
*>>* want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as
*>>* far as I have ever heard is not recommended/supported upstream as it can
*>>* lead to resource tracking issues in Nova that eventually lead to
*>>* scheduling failures later because of the scheduler thinking a node is
*>>* available for more than one instance when it's really not.
*
>This came up in the Nova PTG room yesterday and I wanted to reply on the
>thread with what I understood about it, for those who weren't in the
>session. In general, it's recommended to use the exact filters (1 flavor
>per Ironic node hardware config) as there's no concept of partially
>claiming a baremetal node.

>But, with the old non-exact filters, you _could_ get away with creating
>fewer flavors than you have hardware configs and get "fuzzy matching" on
>Ironic nodes, to get nodes whose configs are "close enough" but not
>exact. This might be helpful in situations where you have some oddball
>configs you don't want to have separate flavors for.
>I was thinking, if it's possible to assign more than one resource class
>to an Ironic node, maybe you could get similar behavior to the old
>non-exact filters. So if you have an oddball config, you could tag it as
>multiple resource classes that it's "close enough" to for a match. But
>I'm not sure whether it's possible for an Ironic node to be tagged with
>more than one resource class.


>* Nisha is raising the question about whether or not we're making
*>* incorrect assumptions about how people are using nova/ironic and they
*>* want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as
*>* far as I have ever heard is not recommended/supported upstream as it can
*>* lead to resource tracking issues in Nova that eventually lead to
*>* scheduling failures later because of the scheduler thinking a node is
*>* available for more than one instance when it's really not.
*
 The concern I have with one single custom resource class for an
Ironic node is that it takes away some of the options that were
available before, such as scheduling based on resource quantity and
non-exact match filters (RamFilter, DiskFilter, and CoreFilter).  Nova
scheduling becomes too restrictive for Ironic.

  I know some users are using these options before Pike with no
issues.   Therefore, it's a mystery to me whether the non-exact filter
for Ironic really has issues.  Even if it has problems, it seems to me
there are ways to address the problem. For instance, Ironic virt
driver can report a node is not available if it's in active state (if
it hasn't done so), or report all resources are consumed when a node
is claimed.   Alternatively, Nova scheduler can report all resources
are consumed for an Ironic node if Nova is willing to make such
change.  Thanks!



On Thu, Sep 7, 2017 at 12:48 PM, Nisha Agarwal 
wrote:

> Hi Ironic Operators,
>
> From Pike, ironic nodes get scheduled based on just the resource class
> from nova. Do you guys see any concerns over this "rigid resource class
> only ironic scheduling"?
>
> To be more specific, at your datacentre/production environment what all
> filters are configured in nova.conf (configuration file for nova) for
> scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in
> the "use_baremetal_filters" for ironic nodes scheduling from nova?
>
> Thanks and Regards
> Nisha
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[melanie witt]

On Thu, 7 Sep 2017 14:57:24 -0500, Matt Riedemann wrote:

Some more background information is in the ironic spec here:

https://review.openstack.org/#/c/500429/

Also, be aware of these release notes for Pike related to baremetal 
scheduling:


http://docs-draft.openstack.org/77/501477/1/check/gate-nova-releasenotes/1dc7513//releasenotes/build/html/unreleased.html#id2 



In Pike, nova is using a combination of VCPU/MEMORY_MB/DISK_GB resource 
class amounts from the flavor during scheduling as it always has, but it 
will also check for the custom resource_class which comes from the 
ironic node. The custom resource class is optional in Pike but will be a 
hard requirement in Queens, or at least that was the plan. The idea 
being that long-term we'd stop consulting VCPU/MEMORY_MB/DISK_GB from 
the flavor during scheduling and just use the atomic node.resource_class 
since we want to allocate a nova instance to an entire ironic node, and 
this is also why the Exact* filters were used too.


There are more details on using custom resource classes for scheduling 
here:


https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/custom-resource-classes-in-flavors.html 



Nisha is raising the question about whether or not we're making 
incorrect assumptions about how people are using nova/ironic and they 
want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as 
far as I have ever heard is not recommended/supported upstream as it can 
lead to resource tracking issues in Nova that eventually lead to 
scheduling failures later because of the scheduler thinking a node is 
available for more than one instance when it's really not.


This came up in the Nova PTG room yesterday and I wanted to reply on the 
thread with what I understood about it, for those who weren't in the 
session. In general, it's recommended to use the exact filters (1 flavor 
per Ironic node hardware config) as there's no concept of partially 
claiming a baremetal node.


But, with the old non-exact filters, you _could_ get away with creating 
fewer flavors than you have hardware configs and get "fuzzy matching" on 
Ironic nodes, to get nodes whose configs are "close enough" but not 
exact. This might be helpful in situations where you have some oddball 
configs you don't want to have separate flavors for.
I was thinking, if it's possible to assign more than one resource class 
to an Ironic node, maybe you could get similar behavior to the old 
non-exact filters. So if you have an oddball config, you could tag it as 
multiple resource classes that it's "close enough" to for a match. But 
I'm not sure whether it's possible for an Ironic node to be tagged with 
more than one resource class.


-melanie

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Nisha Agarwal]

Hello Operators,

It will help to consider this change for Queens release if you could let us
know your opinion/concerns over this change done in Pike release.

Regards
Nisha

On Fri, Sep 8, 2017 at 1:36 AM, Nisha Agarwal 
wrote:

> >>Nisha is raising the question about whether or not we're making
> incorrect assumptions >>about how people are using nova/ironic and they
> want to use the non-Exact filters for >>VCPU/MEMORY_MB/DISK_GB, which as
> far as I have ever heard is not >>recommended/supported upstream as it can
> lead to resource tracking issues in Nova that >>eventually lead to
> scheduling failures later because of the scheduler thinking a node is
> >>available for more than one instance when it's really not.
>
> Just to clarify, I havent heard about this issue lately when we use
> non-Exact filters. (before Pike release).
>
> Regards
> Nisha
>
>
> On Fri, Sep 8, 2017 at 1:27 AM, Matt Riedemann 
> wrote:
>
>> On 9/7/2017 2:48 PM, Nisha Agarwal wrote:
>>
>>> Hi Ironic Operators,
>>>
>>>  From Pike, ironic nodes get scheduled based on just the resource class
>>> from nova. Do you guys see any concerns over this "rigid resource class
>>> only ironic scheduling"?
>>>
>>> To be more specific, at your datacentre/production environment what all
>>> filters are configured in nova.conf (configuration file for nova) for
>>> scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter
>>> in the "use_baremetal_filters" for ironic nodes scheduling from nova?
>>>
>>> Thanks and Regards
>>> Nisha
>>>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> Some more background information is in the ironic spec here:
>>
>> https://review.openstack.org/#/c/500429/
>>
>> Also, be aware of these release notes for Pike related to baremetal
>> scheduling:
>>
>> http://docs-draft.openstack.org/77/501477/1/check/gate-nova-
>> releasenotes/1dc7513//releasenotes/build/html/unreleased.html#id2
>>
>> In Pike, nova is using a combination of VCPU/MEMORY_MB/DISK_GB resource
>> class amounts from the flavor during scheduling as it always has, but it
>> will also check for the custom resource_class which comes from the ironic
>> node. The custom resource class is optional in Pike but will be a hard
>> requirement in Queens, or at least that was the plan. The idea being that
>> long-term we'd stop consulting VCPU/MEMORY_MB/DISK_GB from the flavor
>> during scheduling and just use the atomic node.resource_class since we want
>> to allocate a nova instance to an entire ironic node, and this is also why
>> the Exact* filters were used too.
>>
>> There are more details on using custom resource classes for scheduling
>> here:
>>
>> https://specs.openstack.org/openstack/nova-specs/specs/pike/
>> approved/custom-resource-classes-in-flavors.html
>>
>> Nisha is raising the question about whether or not we're making incorrect
>> assumptions about how people are using nova/ironic and they want to use the
>> non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as far as I have ever
>> heard is not recommended/supported upstream as it can lead to resource
>> tracking issues in Nova that eventually lead to scheduling failures later
>> because of the scheduler thinking a node is available for more than one
>> instance when it's really not.
>>
>> --
>>
>> Thanks,
>>
>> Matt
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> The Secret Of Success is learning how to use pain and pleasure, instead
> of having pain and pleasure use you. If You do that you are in control
> of your life. If you don't life controls you.
>



-- 
The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Nisha Agarwal]

>>Nisha is raising the question about whether or not we're making incorrect
assumptions >>about how people are using nova/ironic and they want to use
the non-Exact filters for >>VCPU/MEMORY_MB/DISK_GB, which as far as I have
ever heard is not >>recommended/supported upstream as it can lead to
resource tracking issues in Nova that >>eventually lead to scheduling
failures later because of the scheduler thinking a node is >>available for
more than one instance when it's really not.

Just to clarify, I havent heard about this issue lately when we use
non-Exact filters. (before Pike release).

Regards
Nisha


On Fri, Sep 8, 2017 at 1:27 AM, Matt Riedemann  wrote:

> On 9/7/2017 2:48 PM, Nisha Agarwal wrote:
>
>> Hi Ironic Operators,
>>
>>  From Pike, ironic nodes get scheduled based on just the resource class
>> from nova. Do you guys see any concerns over this "rigid resource class
>> only ironic scheduling"?
>>
>> To be more specific, at your datacentre/production environment what all
>> filters are configured in nova.conf (configuration file for nova) for
>> scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in
>> the "use_baremetal_filters" for ironic nodes scheduling from nova?
>>
>> Thanks and Regards
>> Nisha
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> Some more background information is in the ironic spec here:
>
> https://review.openstack.org/#/c/500429/
>
> Also, be aware of these release notes for Pike related to baremetal
> scheduling:
>
> http://docs-draft.openstack.org/77/501477/1/check/gate-nova-
> releasenotes/1dc7513//releasenotes/build/html/unreleased.html#id2
>
> In Pike, nova is using a combination of VCPU/MEMORY_MB/DISK_GB resource
> class amounts from the flavor during scheduling as it always has, but it
> will also check for the custom resource_class which comes from the ironic
> node. The custom resource class is optional in Pike but will be a hard
> requirement in Queens, or at least that was the plan. The idea being that
> long-term we'd stop consulting VCPU/MEMORY_MB/DISK_GB from the flavor
> during scheduling and just use the atomic node.resource_class since we want
> to allocate a nova instance to an entire ironic node, and this is also why
> the Exact* filters were used too.
>
> There are more details on using custom resource classes for scheduling
> here:
>
> https://specs.openstack.org/openstack/nova-specs/specs/pike/
> approved/custom-resource-classes-in-flavors.html
>
> Nisha is raising the question about whether or not we're making incorrect
> assumptions about how people are using nova/ironic and they want to use the
> non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as far as I have ever
> heard is not recommended/supported upstream as it can lead to resource
> tracking issues in Nova that eventually lead to scheduling failures later
> because of the scheduler thinking a node is available for more than one
> instance when it's really not.
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Matt Riedemann]

On 9/7/2017 2:48 PM, Nisha Agarwal wrote:

Hi Ironic Operators,

 From Pike, ironic nodes get scheduled based on just the resource class 
from nova. Do you guys see any concerns over this "rigid resource class 
only ironic scheduling"?


To be more specific, at your datacentre/production environment what all 
filters are configured in nova.conf (configuration file for nova) for 
scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in 
the "use_baremetal_filters" for ironic nodes scheduling from nova?


Thanks and Regards
Nisha



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Some more background information is in the ironic spec here:

https://review.openstack.org/#/c/500429/

Also, be aware of these release notes for Pike related to baremetal 
scheduling:


http://docs-draft.openstack.org/77/501477/1/check/gate-nova-releasenotes/1dc7513//releasenotes/build/html/unreleased.html#id2

In Pike, nova is using a combination of VCPU/MEMORY_MB/DISK_GB resource 
class amounts from the flavor during scheduling as it always has, but it 
will also check for the custom resource_class which comes from the 
ironic node. The custom resource class is optional in Pike but will be a 
hard requirement in Queens, or at least that was the plan. The idea 
being that long-term we'd stop consulting VCPU/MEMORY_MB/DISK_GB from 
the flavor during scheduling and just use the atomic node.resource_class 
since we want to allocate a nova instance to an entire ironic node, and 
this is also why the Exact* filters were used too.


There are more details on using custom resource classes for scheduling here:

https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/custom-resource-classes-in-flavors.html

Nisha is raising the question about whether or not we're making 
incorrect assumptions about how people are using nova/ironic and they 
want to use the non-Exact filters for VCPU/MEMORY_MB/DISK_GB, which as 
far as I have ever heard is not recommended/supported upstream as it can 
lead to resource tracking issues in Nova that eventually lead to 
scheduling failures later because of the scheduler thinking a node is 
available for more than one instance when it's really not.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][ironic] Concerns over rigid resource class-only ironic scheduling

[Nisha Agarwal]

Hi Ironic Operators,

>From Pike, ironic nodes get scheduled based on just the resource class from
nova. Do you guys see any concerns over this "rigid resource class only
ironic scheduling"?

To be more specific, at your datacentre/production environment what all
filters are configured in nova.conf (configuration file for nova) for
scheduling an ironic node? Do you use RamFilter/DiskFilter/CoreFilter in
the "use_baremetal_filters" for ironic nodes scheduling from nova?

Thanks and Regards
Nisha
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev