Bug 1468013 - [RFE][Intel OSP13] Sushy driver extensions for RSD networking
[RFE][Intel OSP13] Sushy driver extensions for RSD networking
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
13.0 (Queens)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Angus Thomas
Amit Ugol
: FutureFeature, OtherQA
Depends On:
Blocks: epic-rsd 1476900 1501923
  Show dependency treegraph
 
Reported: 2017-07-05 15:00 EDT by Krish Raghuram
Modified: 2018-03-19 10:12 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-03-17 20:26:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Krish Raghuram 2017-07-05 15:00:06 EDT
Description of feature:
The existing Sushy driver used by Ironic to control RSD nodes should be extended to support the emerging networking APIs being worked in the Redfish community

Version-Release number of selected component (if applicable):
Sushy driver in OpenStack Queens 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?
   New platforms based on RSD architecture
  c) Is this hardware on-board in a system (eg, LOM) or an add-on card? 
  RSD nodes are disaggregated (CPU, memory, storage, accelerators etc.)
  d) Business impact? N/A
  
  e) Other business drivers: N/A

3. Primary contact at Partner, email, phone (chat)
  Mrittika Ganguli - mrittika.ganguli@intel.com

4. Expected results:
- Admin composes a node on a RSD rack with the required network resources
- TripleO then deploys the composed node in the overcloud
- Ironic or Nova or Neutron interfaces with the RSD node using the Sushy driver extension for networking to assign to appropriate VLAN, subnet etc.

Additional info:
Comment 1 Dmitry Tantsur 2017-07-19 04:29:44 EDT
Hi!

Thanks for your request. Ironic does not manage networking stuff directly, we only call into Neutron for that. I'm moving this RFE to a more generic component for evaluation by networking folks.

Meanwhile, do you plan on a new ML2 driver, or an extension to e.g. networking-generic-switch?
Comment 2 Lin Yang 2017-08-01 17:22:32 EDT
(In reply to Dmitry Tantsur from comment #1)
> Hi!
> 
> Thanks for your request. Ironic does not manage networking stuff directly,
> we only call into Neutron for that. I'm moving this RFE to a more generic
> component for evaluation by networking folks.
> 
> Meanwhile, do you plan on a new ML2 driver, or an extension to e.g.
> networking-generic-switch?

Hi Dmitry,

The new extension in networking-generic-switch to integrate RSD networking functionality sounds perfect to me, we also considered this approach before. For this ticket, we proposed to add corresponding networking interfaces in sushy library, so it can be used by other projects, like networking-generic-switch. Make sense?
Comment 3 Nir Yechiel 2017-10-18 02:42:28 EDT
We have reviewed this feature request and we won't be able to prioritize it for RHOSP 13 due to other priorities.
Comment 4 Paul von Behren 2017-12-19 09:09:25 EST
This feature is being deferred to after OSP14. Implementing this requires adequate coverage of switch management functionality in standard YANG models; at this time, standardization of several key functions (for example, VLAN and LAG management) is still TBD.
Comment 5 Nir Yechiel 2018-03-17 20:26:51 EDT
It does not seem like this RFE is actionable right now. Please re-open once the request is more concrete.
Comment 6 Paul von Behren 2018-03-19 10:12:23 EDT
It's okay to close this.  The related standards work has been delayed and may not re-appear as originally planned.

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