<div dir="ltr"><div>Hi Jay, Dmitry,</div><div><br></div>><span style="font-size:12.8px">I strongly challenge the assertion made here that inspection is only useful in scheduling contexts. </span><div><span style="font-size:12.8px">Ok i agree that scheduling is not the only purpose of inspection but it is one of the main aspect of inspection.</span></div><div><span style="font-size:12.8px"><br></span><div><span style="font-size:12.8px">>There are users who simply want to know about their hardware, and read the results as posted to swift.</span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">All above is said just to emphasize that ironic-inspector is not the only way of inspection in ironic. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> Inspection also handles discovery of new nodes when given basic information about them.</span></div></div><div><span style="font-size:12.8px">Applies only to ironic-inspector. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">Also ironic-inspector is useful for automatically defining resource classes on nodes, so I'm not sure about this purpose being defeated as well.</span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Regards</span></div><div><span style="font-size:12.8px">Nisha</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 11, 2017 at 9:34 PM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/11/2017 05:28 PM, Jay Faulkner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Apr 11, 2017, at 12:54 AM, Nisha Agarwal <<a href="mailto:agarwalnisha1980@gmail.com" target="_blank">agarwalnisha1980@gmail.com</a>> wrote:<br>
<br>
Hi John,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With ironic I thought everything is "passed through" by default,<br>
because there is no virtualization in the way. (I am possibly<br>
incorrectly assuming no BIOS tricks to turn off or re-assign PCI<br>
devices dynamically.)<br>
</blockquote>
<br>
Yes with ironic everything is passed through by default.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I am assuming this is purely a scheduling concern. If so, why are<br>
the new custom resource classes not good enough? "ironic_blue" could<br>
mean two GPUs and two 10Gb nics, "ironic_yellow" could mean one GPU<br>
and one 1Gb nic, etc.<br>
Or is there something else that needs addressing here? Trying to<br>
describe what you get with each flavor to end users?<br>
</blockquote>
Yes this is purely from scheduling perspective.<br>
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.<br>
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.<br>
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).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are you needing to aggregating similar hardware in a different way to the above<br>
resource class approach?<br>
</blockquote>
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.<br>
<br>
</blockquote>
<br>
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 when given basic information about them.<br>
</blockquote>
<br></span>
Also ironic-inspector is useful for automatically defining resource classes on nodes, so I'm not sure about this purpose being defeated as well.<br>
<br>
/me makes a note to provide a few examples of such approach in ironic-inspector docs<br>
<br>
Not sure about OOB inspection though.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-<br>
Jay Faulkner<br>
OSIC<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regards<br>
Nisha<br>
<br>
<br>
On Mon, Apr 10, 2017 at 4:29 PM, John Garbutt <<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>> wrote:<br>
On 10 April 2017 at 11:31,  <<a href="mailto:sfinucan@redhat.com" target="_blank">sfinucan@redhat.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 2017-04-10 at 11:50 +0530, Nisha Agarwal wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi team,<br>
<br>
Please could you pour in your suggestions on the mail?<br>
<br>
I raised a blueprint in Nova for this <a href="https://blueprints.launchpad.ne" rel="noreferrer" target="_blank">https://blueprints.launchpad.n<wbr>e</a><br>
t/nova/+spec/pci-passthorugh-f<wbr>or-ironic and two RFEs at ironic side h<br>
ttps://<a href="http://bugs.launchpad.net/ironic/+bug/1680780" rel="noreferrer" target="_blank">bugs.launchpad.net/iron<wbr>ic/+bug/1680780</a> and <a href="https://bugs.launch" rel="noreferrer" target="_blank">https://bugs.launch</a><br>
<a href="http://pad.net/ironic/+bug/1681320" rel="noreferrer" target="_blank">pad.net/ironic/+bug/1681320</a> for the discussion topic.<br>
</blockquote>
<br>
If I understand you correctly, you want to be able to filter ironic<br>
hosts by available PCI device, correct? Barring any possibility that<br>
resource providers could do this for you yet, extending the nova ironic<br>
driver to use the PCI passthrough filter sounds like the way to go.<br>
</blockquote>
<br>
With ironic I thought everything is "passed through" by default,<br>
because there is no virtualization in the way. (I am possibly<br>
incorrectly assuming no BIOS tricks to turn off or re-assign PCI<br>
devices dynamically.)<br>
<br>
So I am assuming this is purely a scheduling concern. If so, why are<br>
the new custom resource classes not good enough? "ironic_blue" could<br>
mean two GPUs and two 10Gb nics, "ironic_yellow" could mean one GPU<br>
and one 1Gb nic, etc.<br>
<br>
Or is there something else that needs addressing here? Trying to<br>
describe what you get with each flavor to end users? Are you needing<br>
to aggregating similar hardware in a different way to the above<br>
resource class approach?<br>
<br>
Thanks,<br>
johnthetubaguy<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
<br>
<br>
--<br>
The Secret Of Success is learning how to use pain and pleasure, instead<br>
of having pain and pleasure use you. If You do that you are in control<br>
of your life. If you don't life controls you.<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">The Secret Of Success is learning how to use pain and pleasure, instead<br>of having pain and pleasure use you. If You do that you are in control<br>of your life. If you don't life controls you.</div>
</div>