[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: [release] [controller-dev] Migrating inventory/topology models
Robert, Sorry if I have missed some part of this discussion. As these models are having heavy impact on netvirt and genius, just curious. https://git.opendaylight.org/gerrit/#/c/controller/+/84251/1/opendaylight/model/model-inventory/src/main/yang/opendaylight-inventory.yang The patch is talking only about removal of the deprecated status. Is that the only change we are talking about? Or are we really doing the migration in openflowplugin, which was the initial decision years back? Thanks, Faseela -Original Message- From: release On Behalf Of Robert Varga Sent: Thursday, September 5, 2019 11:49 PM To: Anil Vishnoi Cc: disc...@lists.opendaylight.org; controller-dev@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; openflowplugin-...@lists.opendaylight.org; rele...@lists.opendaylight.org Subject: Re: [release] [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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14886): https://lists.opendaylight.org/g/controller-dev/message/14886 Mute This Topic: https://lists.opendaylight.org/mt/34101877/21656 Group Owner: controller-dev+ow...@lists.opendaylight.org Unsubscribe: https://lists.opendaylight.org/g/controller-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
