Bug 1411544 - [RFE] [Intel OSP12] Create RSD-specific filters using RSD-specific flavors "tagged" by Ironic
Summary: [RFE] [Intel OSP12] Create RSD-specific filters using RSD-specific flavors "t...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo
Version: 12.0 (Pike)
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: James Slagle
QA Contact: Arik Chernetsky
URL:
Whiteboard:
Depends On:
Blocks: epic-rsd 1419948 1422243
TreeView+ depends on / blocked
 
Reported: 2017-01-10 00:11 UTC by Krish Raghuram
Modified: 2017-11-06 16:00 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-20 10:00:04 UTC
Target Upstream Version:


Attachments (Terms of Use)

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

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


Note You need to log in before you can comment on or make changes to this bug.