Bug 1411544

Summary: [RFE] [Intel OSP12] Create RSD-specific filters using RSD-specific flavors "tagged" by Ironic
Product: Red Hat OpenStack Reporter: Krish Raghuram <krishnan.raghuram>
Component: openstack-tripleoAssignee: James Slagle <jslagle>
Status: CLOSED NEXTRELEASE QA Contact: Arik Chernetsky <achernet>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 12.0 (Pike)CC: jcoufal, jdonohue, krishnan.raghuram, mburns, racedoro, rhel-osp-director-maint, robert.h.armstrong
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-10-20 10:00:04 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1414581, 1419948, 1422243    

Description Krish Raghuram 2017-01-10 00:11:25 UTC
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

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:

Comment 1 Jaromir Coufal 2017-01-24 20:31:20 UTC
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?

Comment 2 Joe Donohue 2017-01-24 21:03:15 UTC
Hi Krish,

Could you respond to the questions raised in comment #1?

Thanks,
Joe

Comment 3 Krish Raghuram 2017-02-03 17:39:51 UTC
(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)

Comment 6 Ramon Acedo 2017-10-20 10:00:04 UTC
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.

Comment 7 Krish Raghuram 2017-10-20 16:37:28 UTC
(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

Comment 8 Joe Donohue 2017-10-27 13:40:01 UTC
Krish,

Do you want me to track this against OSP14? Based on the comments it sounds like this is not needed.

Comment 9 Krish Raghuram 2017-11-06 16:00:25 UTC
(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