[controller-dev] Migrating inventory/topology models
Hello everyone, as it currently stands, then only projects which are using opendaylight-{inventory,topology}*.yang models are OpenFlow-specific projects (openflowplugin, genius, sfc (in sfc-genius-utils), netvirt), plus a soon-to-be-deprecated component in controller/netconf. These models have been deemed as deprecated a long time (3+ years) ago, but the effort to migrate off of them has never materialized, which has left us in a sorry state, where the usage of those models incurs deprecation warnings (all over the place) and there is no target to transition to. We have https://git.opendaylight.org/gerrit/q/+I1e3d27374ffba0e584f194d468cebcfa9cecfe81 merged on master, which will be followed by all other branches. This will alleviate the deprecation pain downstream. As for the next steps, I think we need to migrate these models to openflowplugin, where they can be maintained, as that world is the only place that really uses them. Any objections? Thanks, Robert signature.asc Description: OpenPGP digital signature ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] Migrating inventory/topology models
On Thu, Sep 5, 2019 at 8:56 AM Robert Varga wrote: > Hello everyone, > > as it currently stands, then only projects which are using > opendaylight-{inventory,topology}*.yang models are OpenFlow-specific > projects (openflowplugin, genius, sfc (in sfc-genius-utils), netvirt), > plus a soon-to-be-deprecated component in controller/netconf. > > These models have been deemed as deprecated a long time (3+ years) ago, > but the effort to migrate off of them has never materialized, which has > left us in a sorry state, where the usage of those models incurs > deprecation warnings (all over the place) and there is no target to > transition to. > > We have > > https://git.opendaylight.org/gerrit/q/+I1e3d27374ffba0e584f194d468cebcfa9cecfe81 > merged on master, which will be followed by all other branches. This > will alleviate the deprecation pain downstream. > +1 > > As for the next steps, I think we need to migrate these models to > openflowplugin, where they can be maintained, as that world is the only > place that really uses them. > As far as upstream OpenDaylight is concern this make sense to me, but we need to be careful about the downstream consumer. Downstream user who just use core ODL projects (Controller, yangtools, mdsal,aaa) to develop their standalone application might be using these models, so this movement will break them and to solve this they will have to put dependency on openflowpluing, which they might not want. > > Any objections? > > Thanks, > Robert > > ___ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev > -- Thanks Anil ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] Migrating inventory/topology models
[+ discuss, mdsal-dev] On 05/09/2019 19:24, Anil Vishnoi wrote: > As for the next steps, I think we need to migrate these models to > openflowplugin, where they can be maintained, as that world is the only > place that really uses them. > > As far as upstream OpenDaylight is concern this make sense to me, but we > need to be careful about the downstream consumer. Downstream user who > just use core ODL projects (Controller, yangtools, mdsal,aaa) to develop > their standalone application might be using these models, so this > movement will break them and to solve this they will have to put > dependency on openflowpluing, which they might not want. That is a valid concern, yes. The answer really lies in packaging, as if you are using karaf, you will have openflowplugin-features added to you distribution. Those would not be installed, but will bloat the distro & confuse the users. On the other hand, every feature we build is a separate repository, so while you'd depend on openflowplugin-artifacts, you do not have to depend on openflowplugin-features -- I think. Without Karaf, you depend on whatever you like, so yeah, you get tied up with OFP release cycle, but other than that there should not be a problem. As far as those models are concerned, platform (mdsal/controller/netc) position on them can be summed up as: Migrate to using ietf-network(-topology), which are shipped from MD-SAL for a year now. There are RFC8345 standard and are not expected to make in the foreseeable future. As a further note, while performing that migration, also move away from using yang-ext.yang routed RPCs by switching to YANG 1.1 actions. Such models are not supported by legacy RESTCONF (which itself is deprecated), but are fully supported by RFC8040 RESTCONF (which is the only actively supported version). On a related note, this discussion will also be coming up with relation to: ietf-packet-fields ietf-access-control-list ietf-lisp-address-types ietf-ted ietf-topology ietf-topology-isis ietf-topology-l3-unicast-igp ietf-topology-ospf as MD-SAL will be gradually dropping at least those, which have been superseded by RFCs. Regards, Robert signature.asc Description: OpenPGP digital signature ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] [OpenDaylight Discuss] Migrating inventory/topology models
I think in the case of OFP the work can be split in 2: - Update topology model to last RFC (same as other projects in ODL). To me the sooner we can do this the better. This also may have reduced impact in OFP apps because the topology model contains very few data (e.g. no specific OFP extensions were added to original topology model) - Migrate OFP inventory to topology. This will be more work and have more impact for sure because most (if not all) OFP apps look at the inventory for anything to do with OpenFlow. Now I am not sure what is the hurry here because inventory model is only used by OFP in ODL so at least there is no ODL integration concern AFAICT. BR/Luis > On Sep 5, 2019, at 11:19 AM, Robert Varga wrote: > > [+ discuss, mdsal-dev] > > On 05/09/2019 19:24, Anil Vishnoi wrote: >>As for the next steps, I think we need to migrate these models to >>openflowplugin, where they can be maintained, as that world is the only >>place that really uses them. >> >> As far as upstream OpenDaylight is concern this make sense to me, but we >> need to be careful about the downstream consumer. Downstream user who >> just use core ODL projects (Controller, yangtools, mdsal,aaa) to develop >> their standalone application might be using these models, so this >> movement will break them and to solve this they will have to put >> dependency on openflowpluing, which they might not want. > > That is a valid concern, yes. > > The answer really lies in packaging, as if you are using karaf, you will > have openflowplugin-features added to you distribution. Those would not > be installed, but will bloat the distro & confuse the users. > > On the other hand, every feature we build is a separate repository, so > while you'd depend on openflowplugin-artifacts, you do not have to > depend on openflowplugin-features -- I think. > > Without Karaf, you depend on whatever you like, so yeah, you get tied up > with OFP release cycle, but other than that there should not be a problem. > > As far as those models are concerned, platform (mdsal/controller/netc) > position on them can be summed up as: > > Migrate to using ietf-network(-topology), which are shipped from MD-SAL > for a year now. There are RFC8345 standard and are not expected to make > in the foreseeable future. > As a further note, while performing that migration, also move away from > using yang-ext.yang routed RPCs by switching to YANG 1.1 actions. Such > models are not supported by legacy RESTCONF (which itself is > deprecated), but are fully supported by RFC8040 RESTCONF (which is the > only actively supported version). > > On a related note, this discussion will also be coming up with relation to: > > ietf-packet-fields > ietf-access-control-list > ietf-lisp-address-types > ietf-ted > ietf-topology > ietf-topology-isis > ietf-topology-l3-unicast-igp > ietf-topology-ospf > > as MD-SAL will be gradually dropping at least those, which have been > superseded by RFCs. > > Regards, > Robert > > ___ > Discuss mailing list > disc...@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/discuss ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev