Hide Forgot
1. Description of feature: OpenStack Ironic is made aware of composed RSD nodes and their attributes by the RSD software, which it then uses to create flavor tags. These tags need to be used by TripleO to create RSD-specific filters for consumption by Nova when scheduling workloads Version-Release number of selected component (if applicable): TripleO version in OpenStack Pike release 2. Business Justification: a) Why is this feature needed? RSD is a new architecture that realizes an agile infrastructure where the hardware resources can be pooled according to application needs. It also enables a more easily scaled infrastructure, so CPU, memory, network and storage resources can be added as needed, without the need to do complete replacements of nodes b) What hardware does this enable? RSD Server c) Is this hardware on-board in a system (eg, LOM) or an add-on card? N/A d) Business impact? N/A e) Other business drivers: N/A 3. Primary contact at Partner, email, phone (chat) Priyank Durugkar priyank.durugkar@intel.com 4. Expected results: - DC admin logs into TripleO - TripleO displays RSD-specific tags (surfaced by Ironic) - DC admin creates new flavor and associates it with RSD filters based on these tags - DC admin provisions a node using the new flavor Additional info:
Can we be more specific on what is the output of this RFE (set of tagging policies?)? Isn't it only documentation effort in the end? Since the mechanism for such use-case is available. Who is expected to work on this feature? Who is expected to test it?
Hi Krish, Could you respond to the questions raised in comment #1? Thanks, Joe
(In reply to Joe Donohue from comment #2) > Hi Krish, > > Could you respond to the questions raised in comment #1? > > Thanks, > Joe (In reply to Jaromir Coufal from comment #1) > Can we be more specific on what is the output of this RFE (set of tagging > policies?)? Isn't it only documentation effort in the end? Since the > mechanism for such use-case is available. Who is expected to work on this > feature? Who is expected to test it? I'll have to hold off on an answer until our architects prepare an updated architecture doc. There's been some confusion about how the RSD-specific flavors and filters are created. TripleO may have to use the Valence (controller) APIs to discover and provision nodes (BZ 1397204) and then create the filters (just my initial understanding which may be wrong)
RSD nodes used for the Overcloud shouldn't be an exception to any other type of hardware since they have an Redfish interface to be controlled. TripleO doesn't need to add any special treatment and the workflow should look like this: a. operator composes RSD logical nodes with OSC (via the python-rsdclient plug-in) b. operator registers nodes to TripleO/director using their Redfish interface c. operator deploys Overcloud on the composed RSD logical nodes Based on that I suggest to close this RFE as NEXTRELEASE since we expect the above workflow to be possible by OSP 13 with the inclusion of python-rsdclient and Redfish. Feel free to reopen if you feel we are not understanding the request.
(In reply to Ramon Acedo from comment #6) > RSD nodes used for the Overcloud shouldn't be an exception to any other type > of hardware since they have an Redfish interface to be controlled. TripleO > doesn't need to add any special treatment and the workflow should look like > this: > > a. operator composes RSD logical nodes with OSC (via the python-rsdclient > plug-in) > b. operator registers nodes to TripleO/director using their Redfish > interface > c. operator deploys Overcloud on the composed RSD logical nodes > > Based on that I suggest to close this RFE as NEXTRELEASE since we expect the > above workflow to be possible by OSP 13 with the inclusion of > python-rsdclient and Redfish. Feel free to reopen if you feel we are not > understanding the request. Ramon, I agree with this disposition. The RFE is pretty old and predates our OSC plug-in approach
Krish, Do you want me to track this against OSP14? Based on the comments it sounds like this is not needed.
(In reply to Joe Donohue from comment #8) > Krish, > > Do you want me to track this against OSP14? Based on the comments it sounds > like this is not needed. Joe, we can close this, and generate a new one if it's determined later that we need some Nova filter enhancements to specifically recognize RSD nodes