Vendor code split from horizon
Summary
=======
To clearly document and enable Horizon's policy regarding vendor plugins with the dashboard.
Motivation
=========
There is currently Cisco N1K specific code in the openstack_dashboard code and also in the 'router' dashboard. Additionally, there's Cisco CSR firewall and Cisco DFA plugin horizon code that is planned in addition to other Cisco vendor specific code. Given all these vendor specific additions, it is better to follow a model where-in the vendor specific portion be moved out of the common code base and into its own separate entity that can be 'plugged-in' as and when requited so as to allow for better code maintenance as well as better options for vendors and Horizon users to manage their dashboard. This will also ensure that vendor specific code doesn't reside in the common code repository making it easier to maintain common code as well.
Description
=========
This field should contain a detailed description of the feature to be added.
UX
===
The end user experience should be unaffected.
Wireframes, Mocks, Videos and UI Markup
-------
N/A
Testing
======
Documenting vendor plugin testing best practices will be included.
Each vendor panel/ workflow addition will need to include Unit tests specific to the new additions.
CI testing - TBD.
Outside Dependencies
==================
N/A
Requirements Update Required
=======
N/A
Doc Impact
=========
New documentation detailing vendor plugin policy in Horizon will be added.
Blueprint information
- Status:
- Complete
- Approver:
- Rob Cresswell
- Priority:
- Low
- Drafter:
- Abishek Subramanian
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Approved
- Series goal:
- Accepted for 12.0.0-pike
- Implementation:
-
Implemented
- Milestone target:
-
pike-1
- Started by
- Rob Cresswell
- Completed by
- Rob Cresswell
Related branches
Related bugs
Sprints
Whiteboard
[amotoki, Mar 1 2017] What blocks patches which drop cisco n1kv profile support?
If there are blockers, it is better to be mentioned here.
[mrunge, Mar 04 2015] I would argue, it makes more sense to separate by function, not by vendor name.
Esp. end users don't care, if the feature was added by vendor a or b.
[absubram, Mar 12 2015] mrunge: I would agree making it by function makes sense. However some functionality is vendor specific, in features like launch instance or create networks, or create firewalls. In such instances, I'm not sure how splitting by function will solve the problem. I need to investigate tuskar-ui more to see how that works, which I do think is based on functionality like you've mentioned, but maybe that may shed some light on fixing this problem.
Gerrit topic: https:/
Addressed by: https:/
Remove Router Dashboard
Addressed by: https:/
Remove N1K profile support
Addressed by: https:/
Remove N1K profile support
Addressed by: https:/
Removing cisco n1kv profile support
Addressed by: https:/
Remove router rules extension
Addressed by: https:/
Remove all remaining vendor specific code
