Bug 1468011 - [Intel OSP17][RSD] Sushy driver extensions for RSD storage (Swordfish)
Summary: [Intel OSP17][RSD] Sushy driver extensions for RSD storage (Swordfish)
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: 17.0 (Wallaby)
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: ---
Assignee: Angus Thomas
QA Contact: Amit Ugol
URL:
Whiteboard:
Depends On:
Blocks: 1636092 epmosp17features, epmosp17rfe epic-rsd
TreeView+ depends on / blocked
 
Reported: 2017-07-05 18:54 UTC by Krish Raghuram
Modified: 2019-03-15 12:58 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-15 12:58:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Krish Raghuram 2017-07-05 18:54:51 UTC
Description of feature:
The existing Sushy driver used by Ironic to control RSD nodes should be extended to support the emerging Swordfish API for storage 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

4. Expected results:
- Admin composes a node on a RSD rack with the required storage resources
- TripleO then deploys the composed node in the overcloud
- Ironic or Cinder (or other OpenStack module like Swift) interfaces with the RSD node using the Sushy driver extension for storage

Additional info:

Comment 1 Dmitry Tantsur 2017-07-19 08:31:08 UTC
Hi!

Thanks for your request. Ironic does not manage storage stuff directly, we only call into Cinder for that. We don't interface with Swift for vendor-specific stuff at all. I'm moving this RFE to a more generic component for evaluation by storage folks.

Comment 2 Ramon Acedo 2017-10-27 16:42:34 UTC
Hi Krish, 

Is this RFE still relevant? 

If it is, is there any code upstream to track? By the description, it looks like this is something the python-rsdclient would be able to do using rsd-lib by interacting with the RSD APIs instead of with Sushy. Is this assumption right? 

Thanks!

Comment 3 Joe Donohue 2017-10-30 18:49:01 UTC
Adding need_info for Krish per comment #2.

Comment 4 Krish Raghuram 2017-10-31 19:28:43 UTC
(In reply to Ramon Acedo from comment #2)
> Hi Krish, 
> 
> Is this RFE still relevant? 
> 
> If it is, is there any code upstream to track? By the description, it looks
> like this is something the python-rsdclient would be able to do using
> rsd-lib by interacting with the RSD APIs instead of with Sushy. Is this
> assumption right? 
> 
> Thanks!

Yes, that's correct. We can push this out to RH OSP14. It will become relevant when we want to compose nodes with storage volumes, and attach/detach volumes later. We expect that to become part of a future spec

Comment 5 Ramon Acedo 2017-11-01 15:41:30 UTC
Thank you. Please, let's submit the RFE for OSP 14 then, along with details like the spec to be written.

Comment 6 Paul von Behren 2017-12-19 14:22:10 UTC
Re-opening this RFE, Intel is planning to implement this feature for OSP14. 

Answering a previous question, this will be implemented with rsd-lib. The plan is to support the subset of Swordfish applicable to RSD's Storage Service.

Comment 7 Krish Raghuram 2018-02-26 17:22:23 UTC
(In reply to Joe Donohue from comment #3)
> Adding need_info for Krish per comment #2.
I believe Paul has addressed this in comment 6

Comment 8 Paul von Behren 2018-03-19 15:50:48 UTC
This RFE is a priority for RSD and OSP 14.  This RFE includes updating and extending the "Discovering Remote Storage Services APIs" for rsd-lib (see https://github.com/openstack/rsd-lib/blob/master/doc/source/reference/usage.rst) to use standards-based Swordfish APIS to communicate with external storage solutions.  

Swordfish extends Redfish to support a variety of external storage sources. Swordfish standards and related documents are available here: https://www.snia.org/forums/smi/swordfish

Comment 9 Ramon Acedo 2018-03-22 16:46:14 UTC
Could you add the patches upstream? Thanks.

Comment 10 Sean Merrow 2018-07-19 17:30:55 UTC
Hi Paul,

Are there upstream patches that need to be pulled into OSP? If so, can you please  add the links to them?

Thanks,
Sean

Comment 11 Pavan Chavva 2018-10-15 17:29:59 UTC
Hi paul,

is there any update on this?

Best,
Pavan.

Comment 12 Pavan Chavva 2018-10-16 14:18:43 UTC
Hi krish/Paul,

Are there any patches upstream with respect to this effort?

Best,
Pavan.

Comment 13 Krish Raghuram 2018-10-18 19:17:11 UTC
(In reply to Pavan Chavva from comment #12)
> Hi krish/Paul,
> 
> Are there any patches upstream with respect to this effort?
> 
> Best,
> Pavan.

Pavan, note that Paul has retired :))

We can put this RFE on hold for now. Cinder is using rsd-lib (Intel's RSD repo that has been packaged into RDO) for create/delete and attach/detach volume functions on an RSD node. The former commands are part of Swordfish but the latter are not. 

We recommend re-visiting this RFE after all RSD functions have been merged into Redfish and Swordfish, at which point it makes sense to update Sushy and retire rsd-lib

Comment 14 Pragyan Pathi 2018-10-18 20:07:39 UTC
Pavan based on Krish Comment 13 let us move this to OSP16.
Thanks

Comment 15 Pavan Chavva 2019-02-26 18:35:10 UTC
Moving to OSP 17 based on feedback from Intel.

Comment 16 Pragyan Pathi 2019-02-28 00:29:55 UTC
Upstream Code will not be ready for Train Release. This feature can be moved to RH OSP17

Comment 17 Pavan Chavva 2019-03-14 19:37:28 UTC
Hi Krish/Pragyan,

Would it make sense to close this and re-open it when all the pieces land as described in the below comment?

Let me know.

Best,
Pavan.


(In reply to Krish Raghuram from comment #13)
> (In reply to Pavan Chavva from comment #12)
> > Hi krish/Paul,
> > 
> > Are there any patches upstream with respect to this effort?
> > 
> > Best,
> > Pavan.
> 
> Pavan, note that Paul has retired :))
> 
> We can put this RFE on hold for now. Cinder is using rsd-lib (Intel's RSD
> repo that has been packaged into RDO) for create/delete and attach/detach
> volume functions on an RSD node. The former commands are part of Swordfish
> but the latter are not. 
> 
> We recommend re-visiting this RFE after all RSD functions have been merged
> into Redfish and Swordfish, at which point it makes sense to update Sushy
> and retire rsd-lib

Comment 18 Krish Raghuram 2019-03-14 21:42:28 UTC
(In reply to Pavan Chavva from comment #17)
> Hi Krish/Pragyan,
> 
> Would it make sense to close this and re-open it when all the pieces land as
> described in the below comment?
> 
> Let me know.
> 
> Best,
> Pavan.
> 
> 
> (In reply to Krish Raghuram from comment #13)
> > (In reply to Pavan Chavva from comment #12)
> > > Hi krish/Paul,
> > > 
> > > Are there any patches upstream with respect to this effort?
> > > 
> > > Best,
> > > Pavan.
> > 
> > Pavan, note that Paul has retired :))
> > 
> > We can put this RFE on hold for now. Cinder is using rsd-lib (Intel's RSD
> > repo that has been packaged into RDO) for create/delete and attach/detach
> > volume functions on an RSD node. The former commands are part of Swordfish
> > but the latter are not. 
> > 
> > We recommend re-visiting this RFE after all RSD functions have been merged
> > into Redfish and Swordfish, at which point it makes sense to update Sushy
> > and retire rsd-lib

Agreed

Comment 19 Pavan Chavva 2019-03-15 12:58:43 UTC
Based on previous comments closing this for now.

Will re-open when all the code lands upstream in openstack.org


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