[RFE] Enhance ilo drivers to do inband inspection along with OOB inspection

Copy of whiteboard:

Gerrit topic: https://review.openstack.org/#q,topic:bp/enhance-ilo-drivers-for-inband-discovery,n,z

Addressed by: https://review.openstack.org/201904
    Enhance ilo drivers to do inband inspection

Addressed by: https://review.openstack.org/214357
    WIP: inband discovery in ilo

Is this still needed?

Fix proposed to branch: master
Review: https://review.openstack.org/343577

Please could you reanalyse if the spec is really needed for this RFE.

Removed the tag myself so that it can be analyzed whether it needs spec or not. If spec is needed, its already raised and request reviewers to look at it.

Please don't remove a tag that was added. If you are unsure, then ask why.

rloo, please see the discussion here. I wasn't aware that I shud have added the discussion here. I removed the tag so it can be analyzed again as per discussion.
the link is : http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2016-11-09.log.html
---
Nisha_away jroll, other ironic members, i have a query. I wanted to understand when does a RFE require a spec.
Nisha_away I have heard that RFE can be approved without the spec also 15:29
vdrok Nisha_away: I think it's decided on case by case basis 15:30
vdrok Nisha_away: just file an rfe, if it needs a spec, you eill be told about that in the bug 15:30
Nisha_away vdrok, ok. i wanted to understand it for the existing RFE 15:30
jroll Nisha_away: yes, what vdrok said. anything that is a bit complex, changes API/RPC, affects upgrades, etc usually needs a spec 15:31
jroll Nisha_away: then ask about that RFE :) 15:31
Nisha_away vdrok, for instance https://bugs.launchpad.net/ironic/+bug/1526382 15:31
openstack Launchpad bug 1526382 in Ironic "[RFE] Enhance ilo drivers to do inband inspection along with OOB inspection" [Wishlist,In progress] - Assigned to Aparna (aparnavtce) 15:31
Nisha_away this actually requires https://review.openstack.org/305864 to be merged 15:31
patchbot patch 305864 - ironic-specs - Boot management for in-band inspection 15:32

Nisha_away and then when inspector start supporting virtual media as boot device, then ilo drivers just use that 15:32
Nisha_away to start supporting inband inspection 15:33
Nisha_away vdrok ^^^ 15:33
Nisha_away jroll ^^^ 15:35
vdrok Nisha_away: soo, the rfe bug you linked has needs-spec tag, which is pretty self-describing :) 15:35
jroll Nisha_away: to be approved without a spec, the RFE would need more details on the changes... since you already have the spec written I think we should just review that 15:35
vdrok yep, it needs the spec 15:35
jroll vdrok: I added that because it had a spec, to be honest 15:35
vdrok ah

@Nisha. I don't see anything in that irc discussion you pasted in comment #7 that indicates that you should have removed the needs-spec tag.

Also, as jroll mentions in that same irc discussion "to be approved without a spec, the RFE would need more details on the changes".

I am not that familiar with the state of ilo in ironic. How is oob inspection done currently with ilo, how will in-band inspection be done with ilo (how will the user choose whether to do oob or in-band)? w/o knowing those two, I don't know if your proposed oob_inspection_only config is a good choice. What group/section of the config file were you proposing to add that config? Why obb first, then inband second? Why not inband first, then oob second?

Given the questions I have above, I am still inclined to leave the needs-spec tag unless you can clearly describe in this rfe, the scope of work, etc.

Lastly, w/o the inband inspection spec being approved, it seems premature to be spending time on this spec. If the inband inspection spec changes, that would affect this spec.

By the way, in case you haven't seen our documentation about the RFE process: http://docs.openstack.org/developer/ironic/dev/code-contribution-guide.html#adding-new-features

Change abandoned by Nisha Agarwal (<email address hidden>) on branch: master
Review: https://review.opendev.org/201904

At this point, moving to won't fix. I actually think this was done, in part, but realistically given the move among vendors to standards based interfaces, I just don't see additional functionality going in such as this.