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 <[email protected]> On Behalf Of Robert Varga
Sent: Thursday, September 5, 2019 11:49 PM
To: Anil Vishnoi <[email protected]>
Cc: [email protected]; [email protected];
[email protected]; [email protected];
[email protected]
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: [email protected]
Unsubscribe: https://lists.opendaylight.org/g/controller-dev/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
