[NETCONF-328] Deprecate odl-netconf-topology in Carbon Created: 09/Dec/16 Updated: 15/Mar/19 Resolved: 10/Oct/17 |
|
| Status: | Resolved |
| Project: | netconf |
| Component/s: | netconf |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Vratko Polak | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 7334 |
| Description |
|
Or make odl-netconf-topology compatible with odl-netconf-clustered-topology somehow. Currently the two features are incompatible, i.e. causing CSIT failures when installed together. Currently the failures are prevented by removing both features from odl-integration-compatible-with-all, which means CSIT Feature odl-netconf-topology may offer a slight preformance improvement in 1node setups, but other ODL projects may have cluster-compatible functionalities which would benefit from odl-netconf-clustered-topology. Deprecating odl-netconf-topology would allow for odl-netconf-cluster-topology moving back to odl-integration-compatible-with-all. |
| Comments |
| Comment by Jakub Morvay [ 13/Dec/16 ] |
|
Hi Vratko, It's a good idea, but I think this should discussed more in detail. If we deprecate (and eventually remove) odl-netconf-topology, we will loose ability to spawn "non-clustered" NETCONF connections. Are we sure that this is something unnecessary? Also the odl-netconf-topology is better documented, tested and supports more functionality than odl-netconf-clustered-topology does (currently, notification support for example). Making these two features compatible would require some API changes in YANG models, but maybe this is better option than deprecating and removing odl-netconf-topology completely. |
| Comment by Vratko Polak [ 13/Dec/16 ] |
|
> supports more functionality than odl-netconf-clustered-topology does Oh, I was not aware of that. |
| Comment by Alexis de Talhouët [ 16/Dec/16 ] |
|
> Making these two features compatible would require some API changes in YANG models Jakub, can you say more about those API changes in YANG models? Do you have a well defined idea of where this should be done? Or at least where to look at? With a little a guidance, I'm willing to look into this. |
| Comment by Tomas Cere [ 10/Oct/17 ] |
|
I dont think we should get rid of the nonclustered one, there are valid use cases which might want explicit nonclustered connectors, we should however make the list which is used for the config/oper data configurable or have each implementation govern its own list. |
| Comment by Vratko Polak [ 10/Oct/17 ] |
|
> valid use cases which might want explicit nonclustered connectors Is there a design proposal on how that should work (in cluster)? I do not believe current odl-netconf-topology cluster behavior fits any reasonable proposal. Another issue is that users might want to use both local-member and cluster-wide connectors at the same time, which is currently not possible as both features listen to the same topology-netconf data. I would imagine an extension to odl-netconf-clustered-topology can be implemented, which would allow users to specify list of members allowed to handle the connection. Would it be possible to develop a unified design (and then deprecate the current behavior) in Oxygen? |