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

2017-10-26 Thread 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

2017-10-16 Thread 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 <mriede...@gmail.com> 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] [ironic] Proposing Shivanand Tendulker for ironic-core

2017-10-02 Thread Nisha Agarwal
+1

Regards
Nisha

On Mon, Oct 2, 2017 at 11:13 PM, Loo, Ruby  wrote:

> +1, Thx Dmitry for the proposal and Shiv for doing all the work :D
>
>
>
> --ruby
>
>
>
> *From: *Dmitry Tantsur 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Monday, October 2, 2017 at 10:17 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [ironic] Proposing Shivanand Tendulker for
> ironic-core
>
>
>
> Hi all!
>
> I would like to propose Shivanand (stendulker) to the core team.
>
> His stats have been consistently high [1]. He has given a lot of
> insightful reviews recently, and his expertise in the iLO driver is also
> very valuable for the team.
>
> As usual, please respond with your comments and objections.
>
> Thanks,
>
> Dmitry
>
>
> [1] http://stackalytics.com/report/contribution/ironic-group/90
>
> __
> 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

2017-09-11 Thread 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 <agarwalnisha1...@gmail.com>
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 <mriede...@gmail.com>
> 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

2017-09-07 Thread 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 <mriede...@gmail.com> 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


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

2017-09-07 Thread 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


Re: [openstack-dev] [ironic][nova] Suggestion required on pci_device inventory addition to ironic and its subsequent changes in nova

2017-04-11 Thread Nisha Agarwal
Hi Jay, Dmitry,

>I strongly challenge the assertion made here that inspection is only
useful in scheduling contexts.
Ok i agree that scheduling is not the only purpose of inspection but it is
one of the main aspect of inspection.

>There are users who simply want to know about their hardware, and read the
results as posted to swift.
This is true only for ironic-inspector. If we say all the features of
ironic-inspector is "OK" for ironic, then why OOB inspection not allowed to
discover same things or do same things what ironic-inspector already does.
Ironic-inspector already discovers the pci-device data in the format nova
supports. Why the features supported by ironic-inspector doesnt has to go
through ironic review for capabilities review etc. ironic-inspector does
has its own review process but doesnt centralize its approach(atleast
fields/attributes names) for ironic which is and should be a common thing
between inband inspection and out-of-band inspection.

All above is said just to emphasize that ironic-inspector is not the only
way of inspection in ironic.

> Inspection also handles discovery of new nodes when given basic
information about them.
Applies only to ironic-inspector.

> Also ironic-inspector is useful for automatically defining resource
classes on nodes, so I'm not sure about this purpose being defeated as well.
I wasnt aware that the creation of custom resource class is already
automated by ironic-inspector. If it is already there , it should be done
by ironic instead of ironic-inspector because thats required even by OOB
inspection. If the solution is there in ironic OOB inspection can also use
that for scheduling.

Regards
Nisha

On Tue, Apr 11, 2017 at 9:34 PM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> On 04/11/2017 05:28 PM, Jay Faulkner wrote:
>
>>
>> On Apr 11, 2017, at 12:54 AM, Nisha Agarwal <agarwalnisha1...@gmail.com>
>>> wrote:
>>>
>>> Hi John,
>>>
>>> With ironic I thought everything is "passed through" by default,
>>>> because there is no virtualization in the way. (I am possibly
>>>> incorrectly assuming no BIOS tricks to turn off or re-assign PCI
>>>> devices dynamically.)
>>>>
>>>
>>> Yes with ironic everything is passed through by default.
>>>
>>> So I am assuming this is purely a scheduling concern. If so, why are
>>>> the new custom resource classes not good enough? "ironic_blue" could
>>>> mean two GPUs and two 10Gb nics, "ironic_yellow" could mean one GPU
>>>> and one 1Gb nic, etc.
>>>> Or is there something else that needs addressing here? Trying to
>>>> describe what you get with each flavor to end users?
>>>>
>>> Yes this is purely from scheduling perspective.
>>> Currently how ironic works is we discover server attributes and populate
>>> them into node object. These attributes are then used for further
>>> scheduling of the node from nova scheduler using ComputeCapabilities
>>> filter. So this is something automated on ironic side, like we do
>>> inspection of the node properties/attributes and user need to create the
>>> flavor of their choice and the node which meets the user need is scheduled
>>> for ironic deploy.
>>> With resource class name in place in ironic, we ask user to do a manual
>>> step i.e. create a resource class name based on the hardware attributes and
>>> this need to be done on per node basis. For this user need to know the
>>> server hardware properties in advance before assigning the resource class
>>> name to the node(s) and then assign the resource class name manually to the
>>> node.
>>> In a broad way if i say, if we want to support scheduling based on
>>> quantity for ironic nodes there is no way we can do it through current
>>> resource class structure(actually just a tag) in ironic. A  user may want
>>> to schedule ironic nodes on different resources and each resource should be
>>> a different resource class (IMO).
>>>
>>> Are you needing to aggregating similar hardware in a different way to
>>>> the above
>>>> resource class approach?
>>>>
>>> i guess no but the above resource class approach takes away the
>>> automation on the ironic side and the whole purpose of inspection is
>>> defeated.
>>>
>>>
>> I strongly challenge the assertion made here that inspection is only
>> useful in scheduling contexts. There are users who simply want to know
>> about their hardware, and read the results as posted to swift. Inspection
>> also handles discovery of new nodes

Re: [openstack-dev] [ironic][nova] Suggestion required on pci_device inventory addition to ironic and its subsequent changes in nova

2017-04-11 Thread Nisha Agarwal
Hi John,

>With ironic I thought everything is "passed through" by default,
>because there is no virtualization in the way. (I am possibly
>incorrectly assuming no BIOS tricks to turn off or re-assign PCI
>devices dynamically.)

Yes with ironic everything is passed through by default.

>So I am assuming this is purely a scheduling concern. If so, why are
>the new custom resource classes not good enough? "ironic_blue" could
>mean two GPUs and two 10Gb nics, "ironic_yellow" could mean one GPU
>and one 1Gb nic, etc.
>Or is there something else that needs addressing here? Trying to
>describe what you get with each flavor to end users?
Yes this is purely from scheduling perspective.
Currently how ironic works is we discover server attributes and populate
them into node object. These attributes are then used for further
scheduling of the node from nova scheduler using ComputeCapabilities
filter. So this is something automated on ironic side, like we do
inspection of the node properties/attributes and user need to create the
flavor of their choice and the node which meets the user need is scheduled
for ironic deploy.
With resource class name in place in ironic, we ask user to do a manual
step i.e. create a resource class name based on the hardware attributes and
this need to be done on per node basis. For this user need to know the
server hardware properties in advance before assigning the resource class
name to the node(s) and then assign the resource class name manually to the
node.
In a broad way if i say, if we want to support scheduling based on quantity
for ironic nodes there is no way we can do it through current resource
class structure(actually just a tag) in ironic. A  user may want to
schedule ironic nodes on different resources and each resource should be a
different resource class (IMO).

>Are you needing to aggregating similar hardware in a different way to the
above
>resource class approach?
i guess no but the above resource class approach takes away the automation
on the ironic side and the whole purpose of inspection is defeated.

Regards
Nisha


On Mon, Apr 10, 2017 at 4:29 PM, John Garbutt <j...@johngarbutt.com> wrote:

> On 10 April 2017 at 11:31,  <sfinu...@redhat.com> wrote:
> > On Mon, 2017-04-10 at 11:50 +0530, Nisha Agarwal wrote:
> >> Hi team,
> >>
> >> Please could you pour in your suggestions on the mail?
> >>
> >> I raised a blueprint in Nova for this https://blueprints.launchpad.ne
> >> t/nova/+spec/pci-passthorugh-for-ironic and two RFEs at ironic side h
> >> ttps://bugs.launchpad.net/ironic/+bug/1680780 and https://bugs.launch
> >> pad.net/ironic/+bug/1681320 for the discussion topic.
> >
> > If I understand you correctly, you want to be able to filter ironic
> > hosts by available PCI device, correct? Barring any possibility that
> > resource providers could do this for you yet, extending the nova ironic
> > driver to use the PCI passthrough filter sounds like the way to go.
>
> With ironic I thought everything is "passed through" by default,
> because there is no virtualization in the way. (I am possibly
> incorrectly assuming no BIOS tricks to turn off or re-assign PCI
> devices dynamically.)
>
> So I am assuming this is purely a scheduling concern. If so, why are
> the new custom resource classes not good enough? "ironic_blue" could
> mean two GPUs and two 10Gb nics, "ironic_yellow" could mean one GPU
> and one 1Gb nic, etc.
>
> Or is there something else that needs addressing here? Trying to
> describe what you get with each flavor to end users? Are you needing
> to aggregating similar hardware in a different way to the above
> resource class approach?
>
> Thanks,
> johnthetubaguy
>
> __
> 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] [ironic][nova] Suggestion required on pci_device inventory addition to ironic and its subsequent changes in nova

2017-04-10 Thread Nisha Agarwal
Hi team,

Please could you pour in your suggestions on the mail?

I raised a blueprint in Nova for this
https://blueprints.launchpad.net/nova/+spec/pci-passthorugh-for-ironic and
two RFEs at ironic side https://bugs.launchpad.net/ironic/+bug/1680780 and
https://bugs.launchpad.net/ironic/+bug/1681320 for the discussion topic.

Regards
Nisha

On Wed, Apr 5, 2017 at 11:03 PM, Nisha Agarwal <agarwalnisha1...@gmail.com>
wrote:

> Hi,
>
> I suggested to add few pci devices related attributes to ironic
> inspection(out-of-band as well inband). https://review.
> openstack.org/#/c/338138.
>
> I got the suggestion to convert them to standard pci device format which
> nova understands. For example( as given in Nova code):
> [{"count": 5, "vendor_id": "8086", "product_id": "1520",
>  "extra_info":'{}'}],
>
> For above to be supported for ironic scheduling, we will require changes
> at two places:
> 1. nova - This should require a small code changes as pci_passthrough
> filter already exists in nova. The ironic virt driver should be able to
> consume the pci_device structure from ironic node/database and pass it on
> to scheduler for scheduling and it should add pci_passthrough filter in
> ironic nodes filter list.
> 2. ironic - this definitely needs a spec which will suggest to add the
> pci_device data structure to ironic node.
>
>
> The ironic side work may take some time but Nova side looks to be a small
> change. IMO we can have the nova side changes and ironic database changes
> (to add pci_device field) parallely.
> Inspection can populate that new pci_device field for the node to get
> scheduled.
>
> AFAIK, ironic-inspector already has the plugin to discover pci devices in
> the format nova has it today. If we get the scheduling enabled based on
> pci_devices for ironic nodes, then inspector can write this data to ironic
> node object by default.
>
> What do you people think on this idea? Does it make sense? If its worth to
> do this way i can own up this work.
>
> Regards
> Nisha
>
> --
> 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


[openstack-dev] [ironic][nova] Suggestion required on pci_device inventory addition to ironic and its subsequent changes in nova

2017-04-05 Thread Nisha Agarwal
Hi,

I suggested to add few pci devices related attributes to ironic
inspection(out-of-band as well inband).
https://review.openstack.org/#/c/338138.

I got the suggestion to convert them to standard pci device format which
nova understands. For example( as given in Nova code):
[{"count": 5, "vendor_id": "8086", "product_id": "1520",
 "extra_info":'{}'}],

For above to be supported for ironic scheduling, we will require changes at
two places:
1. nova - This should require a small code changes as pci_passthrough
filter already exists in nova. The ironic virt driver should be able to
consume the pci_device structure from ironic node/database and pass it on
to scheduler for scheduling and it should add pci_passthrough filter in
ironic nodes filter list.
2. ironic - this definitely needs a spec which will suggest to add the
pci_device data structure to ironic node.


The ironic side work may take some time but Nova side looks to be a small
change. IMO we can have the nova side changes and ironic database changes
(to add pci_device field) parallely.
Inspection can populate that new pci_device field for the node to get
scheduled.

AFAIK, ironic-inspector already has the plugin to discover pci devices in
the format nova has it today. If we get the scheduling enabled based on
pci_devices for ironic nodes, then inspector can write this data to ironic
node object by default.

What do you people think on this idea? Does it make sense? If its worth to
do this way i can own up this work.

Regards
Nisha

-- 
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


[openstack-dev] Exception request : [stable] Ironic doesn't use cacert while talking to Swift ( https://review.openstack.org/#/c/253460/)

2016-01-17 Thread Nisha Agarwal
Hello Team,

This patch got approval long back(Jan 6)  but due to Jenkins failure in the
merge pipeline of the Kilo branch, this patch was not merged.

Hence I request for an exception for this patch as  this was not merged due
to Jenkins issue.

Regards
Nisha

-- 
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] FFE request for passing capabilities in the flavor to ironic

2015-02-08 Thread Nisha Agarwal
Hi wanyen and Nova team,

I support wanyen for this FFE. The code changes are very small and harmless
to Nova. They just provide a way to ironic to comsume inputs given at
flavor.

Regards
Nisha

On Sat, Feb 7, 2015 at 12:33 AM, Hsu, Wan-Yen wan-yen@hp.com wrote:

  Hi,



I would like to ask for a feature freeze exception for passing
 capabilities in the flavor to Ironic:




 https://blueprints.launchpad.net/nova/+spec/pass-flavor-capabilities-to-ironic-virt-driver

 Addressed by: https://review.openstack.org/136104
 Pass on the capabilities in the flavor to the ironic

Addressed by: https://review.openstack.org/141012
Pass on the capabilities to instance_info

 several Ironic Kilo features including secure boot, trusted boot, and
 local boot support with partition image are depending on this feature.  It
 also has impact on Ironic vendor driver’s hardware property introspection
 feature.



  Code changes to support this spec in Nova ironic virt driver is very
 small-

 only 31 lines of code (including comments) in
 nova/virt/ironic/patcher.py,  and 22 lines of code in test_patcher.py.



Please consider approving this FFE.  Thanks!



 Regards,

 wanyen



 __
 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


[openstack-dev] FFE request for https://review.openstack.org/#/c/141012 https://blueprints.launchpad.net/openstack/?searchtext=pass-flavor-capabilities-to-ironic-virt-driver

2015-02-05 Thread Nisha Agarwal
Hi,

FFE request for the patch https://review.openstack.org/#/c/141012.

This is required by other items in ironic namely:
https://review.openstack.org/#/c/135228/6/specs/kilo/uefi-secure-boot.rst.


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-dev] https://review.openstack.org/#/c/141012/ Pass the capabilities to ironic node instance_info

2015-01-24 Thread Nisha Agarwal
Hi,


The jenkins fail but the failure is not related to the patch. The
hypervisor creation fails, but thats not the functionality this patch
touches.

Regards
Nisha

-- 
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


[openstack-dev] Requesting Exception/Review for Compute-Capabilities spec

2015-01-12 Thread Nisha Agarwal
Hi,

The ironic needs this feature from nova to implement Firmware settings.
The code also has been proposed for the same.

Spec link: https://review.openstack.org/133534
Code link: https://review.openstack.org/141010

Regards
Nisha
-- 
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