|
Raghurama Bhat <raghu.odl@...>
Hi,
If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving the non-core parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it.
Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components like Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.
However, I think the following Applications need to be more generic and protocol agnostic although the we only had an Openflow implementation until now. Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations? - forwardingrules-manager
- inventory-manager
- topology-manager
Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the home for generic services like Topology and LLDP Discovery and potentially renaming it to be more generic to reflect the true nature of its content.
BTW, Does the list below represent the complete picture of migrations like this or is there more? This might be a good topic for the TWS Call as well.
Thoughts?
Thanks,
—Raghu
Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.
Migration will take following steps: - copy corresponding projects from controller into openflowplugin
- change project and package names where necessary (without changing model content) (deadline:
09.01.2015)
- adapt downstream project in order to use those model projects (deadline: 16.01.2015)
- remove models from controller repository (deadline: 23.01.2015)
Models to migrate: - model/model-flow-base
- model/model-flow-service
- model/model-flow-statistics
Apps to migrate - statistics-manager
- forwardingrules-manager
- inventory-manager
- topology-lldp-discovery
- topology-manager
Donwstream projects (so far) - aaa
- l2switch
- ovsdb
- openflowplugin
- affinity
- packetcable
- grupbasedpolicy
If you have questions, contributions, comments then please feel free to respond.
The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development. And controller project plans to go more abstract/general way.
With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending on dataStore result of those applications.
There are no deadlines for applications yet but moving them together with models might spare us some renaming work.
Thank you.
Regards, Michal
|
|
|
Robert Varga -X (rovarga - Pantheon Technologies SRO@Cisco) <rovarga@...>
Hello Raghu,
I am a bit worried about „protocol-agnostic“ bit, as even if you factor the control protocol out, you have to
make assumptions about your model of the world (contrast OF vs. PCEP vs. SR). Generic applications can work only as long as those assumptions hold.
FRM is very much OF-specific, as it has the notion of a „flow“, at least now. Given where we are on the Lithium
trajectory, we can only do so much.
Inventory-manager is completely tied to OF, and the OFP design calls for its complete integration into the OFP
pipeline. Realistically, its functionality is tightly coupled with the lifecycle of the underlying protocol (we have fully-integrated equivalents in PCEP and NETCONF, and they work better). With the intetion to deprecate opendaylight-inventory model, the roles
of inventory-manager and topology-manager are largely the same (when we disregard the discovery piece, which again is technology-specific).
Bye,
Robert
From:
Raghurama Bhat [mailto:raghu.odl@...]
toggle quoted message
Show quoted text
Sent: Thursday, January 08, 2015 5:58 AM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...
Cc: openflowplugin-dev; aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; l2switch-dev@...; Jan
Medved (jmedved); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Ed Warnicke (eaw); Moiz Raja (moraja)
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo
If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving
the non-core parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it.
Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components
like Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.
However, I think the following Applications need to be more generic and protocol agnostic although the we only had
an Openflow implementation until now. Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations?
-
forwardingrules-manager
-
inventory-manager
-
topology-manager
Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the
home for generic services like Topology and LLDP Discovery and potentially renaming it to be more generic to reflect the true nature of its content.
BTW, Does the list below represent the complete picture of migrations like this or is there more? This might be a
good topic for the TWS Call as well.
Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.
Migration will take following steps:
-
copy corresponding projects from controller into openflowplugin
-
change project and package names where necessary (without changing model content) (deadline:
09.01.2015)
-
adapt downstream project in order to use those model projects (deadline: 16.01.2015)
-
remove models from controller repository (deadline:
23.01.2015)
Models to migrate:
-
model/model-flow-base
-
model/model-flow-service
-
model/model-flow-statistics
Apps to migrate
-
statistics-manager
-
forwardingrules-manager
-
inventory-manager
-
topology-lldp-discovery
-
topology-manager
Donwstream projects (so far)
-
aaa
-
l2switch
-
ovsdb
-
openflowplugin
-
affinity
-
packetcable
-
grupbasedpolicy
If you have questions, contributions, comments then please feel free to respond.
The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development.
And controller project plans to go more abstract/general way.
With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending
on dataStore result of those applications.
There are no deadlines for applications yet but moving them together with models might spare us some renaming work.
Thank you.
Regards,
Michal
_______________________________________________ L2switch-dev mailing list
L2switch-dev@...
https://lists.opendaylight.org/mailman/listinfo/l2switch-dev
|
|
|
On the one hand, I agree that the FRM is currently very OF-oriented, the idea that some of what we were calling "Network Service Functions" end up getting migrated to being inside a specific plugin does feel wrong.
As long as the parts that can be kept OF-independent can still be consumed and reimplemented by others, I guess it's fine to move them from the controller to the OpenFlow plugin project, but it does feel off.
--Colin On Thursday, January 8, 2015, Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) < rovarga@...> wrote:
Hello Raghu,
I am a bit worried about „protocol-agnostic“ bit, as even if you factor the control protocol out, you have to
make assumptions about your model of the world (contrast OF vs. PCEP vs. SR). Generic applications can work only as long as those assumptions hold.
FRM is very much OF-specific, as it has the notion of a „flow“, at least now. Given where we are on the Lithium
trajectory, we can only do so much.
Inventory-manager is completely tied to OF, and the OFP design calls for its complete integration into the OFP
pipeline. Realistically, its functionality is tightly coupled with the lifecycle of the underlying protocol (we have fully-integrated equivalents in PCEP and NETCONF, and they work better). With the intetion to deprecate opendaylight-inventory model, the roles
of inventory-manager and topology-manager are largely the same (when we disregard the discovery piece, which again is technology-specific).
Bye,
Robert
From:
Raghurama Bhat [mailto:raghu.odl@...]
Sent: Thursday, January 08, 2015 5:58 AM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...
Cc: openflowplugin-dev; aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; l2switch-dev@...; Jan
Medved (jmedved); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Ed Warnicke (eaw); Moiz Raja (moraja)
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo
If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving
the non-core parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it.
Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components
like Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.
However, I think the following Applications need to be more generic and protocol agnostic although the we only had
an Openflow implementation until now. Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations?
-
forwardingrules-manager
-
inventory-manager
-
topology-manager
Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the
home for generic services like Topology and LLDP Discovery and potentially renaming it to be more generic to reflect the true nature of its content.
BTW, Does the list below represent the complete picture of migrations like this or is there more? This might be a
good topic for the TWS Call as well.
Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.
Migration will take following steps:
-
copy corresponding projects from controller into openflowplugin
-
change project and package names where necessary (without changing model content) (deadline:
09.01.2015)
-
adapt downstream project in order to use those model projects (deadline: 16.01.2015)
-
remove models from controller repository (deadline:
23.01.2015)
Models to migrate:
-
model/model-flow-base
-
model/model-flow-service
-
model/model-flow-statistics
Apps to migrate
-
statistics-manager
-
forwardingrules-manager
-
inventory-manager
-
topology-lldp-discovery
-
topology-manager
Donwstream projects (so far)
-
aaa
-
l2switch
-
ovsdb
-
openflowplugin
-
affinity
-
packetcable
-
grupbasedpolicy
If you have questions, contributions, comments then please feel free to respond.
The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development.
And controller project plans to go more abstract/general way.
With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending
on dataStore result of those applications.
There are no deadlines for applications yet but moving them together with models might spare us some renaming work.
Thank you.
Regards,
Michal
_______________________________________________ L2switch-dev mailing list
L2switch-dev@...
https://lists.opendaylight.org/mailman/listinfo/l2switch-dev
|
|
|
On the one hand, I agree that the FRM is currently very OF-oriented, the idea that some of what we were calling "Network Service Functions" end up getting migrated to being inside a specific plugin does feel wrong.
As long as the parts that can be kept OF-independent can still be consumed and reimplemented by others, I guess it's fine to move them from the controller to the OpenFlow plugin project, but it does feel off.
--Colin On Thursday, January 8, 2015, Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) < rovarga@...> wrote:
Hello Raghu,
I am a bit worried about „protocol-agnostic“ bit, as even if you factor the control protocol out, you have to
make assumptions about your model of the world (contrast OF vs. PCEP vs. SR). Generic applications can work only as long as those assumptions hold.
FRM is very much OF-specific, as it has the notion of a „flow“, at least now. Given where we are on the Lithium
trajectory, we can only do so much.
Inventory-manager is completely tied to OF, and the OFP design calls for its complete integration into the OFP
pipeline. Realistically, its functionality is tightly coupled with the lifecycle of the underlying protocol (we have fully-integrated equivalents in PCEP and NETCONF, and they work better). With the intetion to deprecate opendaylight-inventory model, the roles
of inventory-manager and topology-manager are largely the same (when we disregard the discovery piece, which again is technology-specific).
Bye,
Robert
From:
Raghurama Bhat [mailto:raghu.odl@...]
Sent: Thursday, January 08, 2015 5:58 AM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...
Cc: openflowplugin-dev; aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; l2switch-dev@...; Jan
Medved (jmedved); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Ed Warnicke (eaw); Moiz Raja (moraja)
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo
If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving
the non-core parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it.
Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components
like Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.
However, I think the following Applications need to be more generic and protocol agnostic although the we only had
an Openflow implementation until now. Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations?
-
forwardingrules-manager
-
inventory-manager
-
topology-manager
Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the
home for generic services like Topology and LLDP Discovery and potentially renaming it to be more generic to reflect the true nature of its content.
BTW, Does the list below represent the complete picture of migrations like this or is there more? This might be a
good topic for the TWS Call as well.
Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.
Migration will take following steps:
-
copy corresponding projects from controller into openflowplugin
-
change project and package names where necessary (without changing model content) (deadline:
09.01.2015)
-
adapt downstream project in order to use those model projects (deadline: 16.01.2015)
-
remove models from controller repository (deadline:
23.01.2015)
Models to migrate:
-
model/model-flow-base
-
model/model-flow-service
-
model/model-flow-statistics
Apps to migrate
-
statistics-manager
-
forwardingrules-manager
-
inventory-manager
-
topology-lldp-discovery
-
topology-manager
Donwstream projects (so far)
-
aaa
-
l2switch
-
ovsdb
-
openflowplugin
-
affinity
-
packetcable
-
grupbasedpolicy
If you have questions, contributions, comments then please feel free to respond.
The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development.
And controller project plans to go more abstract/general way.
With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending
on dataStore result of those applications.
There are no deadlines for applications yet but moving them together with models might spare us some renaming work.
Thank you.
Regards,
Michal
_______________________________________________ L2switch-dev mailing list
L2switch-dev@...
https://lists.opendaylight.org/mailman/listinfo/l2switch-dev
|
|
|
On the one hand, I agree that the FRM is currently very OF-oriented, the idea that some of what we were calling "Network Service Functions" end up getting migrated to being inside a specific plugin does feel wrong.
As long as the parts that can be kept OF-independent can still be consumed and reimplemented by others, I guess it's fine to move them from the controller to the OpenFlow plugin project, but it does feel off.
--Colin On Thursday, January 8, 2015, Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) < rovarga@...> wrote:
Hello Raghu,
I am a bit worried about „protocol-agnostic“ bit, as even if you factor the control protocol out, you have to
make assumptions about your model of the world (contrast OF vs. PCEP vs. SR). Generic applications can work only as long as those assumptions hold.
FRM is very much OF-specific, as it has the notion of a „flow“, at least now. Given where we are on the Lithium
trajectory, we can only do so much.
Inventory-manager is completely tied to OF, and the OFP design calls for its complete integration into the OFP
pipeline. Realistically, its functionality is tightly coupled with the lifecycle of the underlying protocol (we have fully-integrated equivalents in PCEP and NETCONF, and they work better). With the intetion to deprecate opendaylight-inventory model, the roles
of inventory-manager and topology-manager are largely the same (when we disregard the discovery piece, which again is technology-specific).
Bye,
Robert
From:
Raghurama Bhat [mailto:raghu.odl@...]
Sent: Thursday, January 08, 2015 5:58 AM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...
Cc: openflowplugin-dev; aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; l2switch-dev@...; Jan
Medved (jmedved); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Ed Warnicke (eaw); Moiz Raja (moraja)
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo
If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving
the non-core parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it.
Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components
like Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.
However, I think the following Applications need to be more generic and protocol agnostic although the we only had
an Openflow implementation until now. Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations?
-
forwardingrules-manager
-
inventory-manager
-
topology-manager
Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the
home for generic services like Topology and LLDP Discovery and potentially renaming it to be more generic to reflect the true nature of its content.
BTW, Does the list below represent the complete picture of migrations like this or is there more? This might be a
good topic for the TWS Call as well.
Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.
Migration will take following steps:
-
copy corresponding projects from controller into openflowplugin
-
change project and package names where necessary (without changing model content) (deadline:
09.01.2015)
-
adapt downstream project in order to use those model projects (deadline: 16.01.2015)
-
remove models from controller repository (deadline:
23.01.2015)
Models to migrate:
-
model/model-flow-base
-
model/model-flow-service
-
model/model-flow-statistics
Apps to migrate
-
statistics-manager
-
forwardingrules-manager
-
inventory-manager
-
topology-lldp-discovery
-
topology-manager
Donwstream projects (so far)
-
aaa
-
l2switch
-
ovsdb
-
openflowplugin
-
affinity
-
packetcable
-
grupbasedpolicy
If you have questions, contributions, comments then please feel free to respond.
The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development.
And controller project plans to go more abstract/general way.
With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending
on dataStore result of those applications.
There are no deadlines for applications yet but moving them together with models might spare us some renaming work.
Thank you.
Regards,
Michal
_______________________________________________ L2switch-dev mailing list
L2switch-dev@...
https://lists.opendaylight.org/mailman/listinfo/l2switch-dev
|
|
|
On the one hand, I agree that the FRM is currently very OF-oriented, the idea that some of what we were calling "Network Service Functions" end up getting migrated to being inside a specific plugin does feel wrong.
As long as the parts that can be kept OF-independent can still be consumed and reimplemented by others, I guess it's fine to move them from the controller to the OpenFlow plugin project, but it does feel off.
--Colin On Thursday, January 8, 2015, Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) < rovarga@...> wrote:
Hello Raghu,
I am a bit worried about „protocol-agnostic“ bit, as even if you factor the control protocol out, you have to
make assumptions about your model of the world (contrast OF vs. PCEP vs. SR). Generic applications can work only as long as those assumptions hold.
FRM is very much OF-specific, as it has the notion of a „flow“, at least now. Given where we are on the Lithium
trajectory, we can only do so much.
Inventory-manager is completely tied to OF, and the OFP design calls for its complete integration into the OFP
pipeline. Realistically, its functionality is tightly coupled with the lifecycle of the underlying protocol (we have fully-integrated equivalents in PCEP and NETCONF, and they work better). With the intetion to deprecate opendaylight-inventory model, the roles
of inventory-manager and topology-manager are largely the same (when we disregard the discovery piece, which again is technology-specific).
Bye,
Robert
From:
Raghurama Bhat [mailto:raghu.odl@...]
Sent: Thursday, January 08, 2015 5:58 AM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...
Cc: openflowplugin-dev; aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; l2switch-dev@...; Jan
Medved (jmedved); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Ed Warnicke (eaw); Moiz Raja (moraja)
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo
If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving
the non-core parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it.
Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components
like Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.
However, I think the following Applications need to be more generic and protocol agnostic although the we only had
an Openflow implementation until now. Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations?
-
forwardingrules-manager
-
inventory-manager
-
topology-manager
Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the
home for generic services like Topology and LLDP Discovery and potentially renaming it to be more generic to reflect the true nature of its content.
BTW, Does the list below represent the complete picture of migrations like this or is there more? This might be a
good topic for the TWS Call as well.
Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.
Migration will take following steps:
-
copy corresponding projects from controller into openflowplugin
-
change project and package names where necessary (without changing model content) (deadline:
09.01.2015)
-
adapt downstream project in order to use those model projects (deadline: 16.01.2015)
-
remove models from controller repository (deadline:
23.01.2015)
Models to migrate:
-
model/model-flow-base
-
model/model-flow-service
-
model/model-flow-statistics
Apps to migrate
-
statistics-manager
-
forwardingrules-manager
-
inventory-manager
-
topology-lldp-discovery
-
topology-manager
Donwstream projects (so far)
-
aaa
-
l2switch
-
ovsdb
-
openflowplugin
-
affinity
-
packetcable
-
grupbasedpolicy
If you have questions, contributions, comments then please feel free to respond.
The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development.
And controller project plans to go more abstract/general way.
With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending
on dataStore result of those applications.
There are no deadlines for applications yet but moving them together with models might spare us some renaming work.
Thank you.
Regards,
Michal
_______________________________________________ L2switch-dev mailing list
L2switch-dev@...
https://lists.opendaylight.org/mailman/listinfo/l2switch-dev
|
|
|
Michal Rehak -X (mirehak - Pantheon Technologies SRO@Cisco) <mirehak@...>
Hi Colin,
there was already discussion about renaming those apps so we do not block some good general name (like NSF).
And yes - we might later come up with some more general modeling here which would be shareable by multiple protocols or at least apps. And then we would definitely play with the idea of pulling those models up to separate project so that controller models will
stay protocol agnostic.
Now Abhijit got this idea regarding where is the best place to move OF-specific apps:
Those apps depend on ofplugin but it seems they do not depend on l2switch. Are there any dependencies of those apps pointing on l2switch services?
Regards,
Michal
toggle quoted message
Show quoted text
From: Colin Dixon [colin@...]
Sent: Monday, January 12, 2015 19:47
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco)
Cc: Raghurama Bhat; Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...; openflowplugin-dev; Moiz Raja (moraja); aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...;
affinity-dev@...; Jan Medved (jmedved); Ed Warnicke (eaw); l2switch-dev@...
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo
On the one hand, I agree that the FRM is currently very OF-oriented, the idea that some of what we were calling "Network Service Functions" end up getting migrated to being inside a specific plugin does feel wrong.
As long as the parts that can be kept OF-independent can still be consumed and reimplemented by others, I guess it's fine to move them from the controller to the OpenFlow plugin project, but it does feel off.
--Colin
On Thursday, January 8, 2015, Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) < rovarga@...> wrote:
Hello Raghu,
I am a bit worried about „protocol-agnostic“ bit, as even if you factor the control protocol out, you have to make assumptions
about your model of the world (contrast OF vs. PCEP vs. SR). Generic applications can work only as long as those assumptions hold.
FRM is very much OF-specific, as it has the notion of a „flow“, at least now. Given where we are on the Lithium trajectory,
we can only do so much.
Inventory-manager is completely tied to OF, and the OFP design calls for its complete integration into the OFP pipeline.
Realistically, its functionality is tightly coupled with the lifecycle of the underlying protocol (we have fully-integrated equivalents in PCEP and NETCONF, and they work better). With the intetion to deprecate opendaylight-inventory model, the roles of inventory-manager
and topology-manager are largely the same (when we disregard the discovery piece, which again is technology-specific).
Bye,
Robert
From:
Raghurama Bhat [mailto:raghu.odl@...]
Sent: Thursday, January 08, 2015 5:58 AM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco);
release@...
Cc: openflowplugin-dev;
aaa-dev@...;
ovsdb-dev@...;
groupbasedpolicy-dev@...;
affinity-dev@...;
l2switch-dev@...; Jan Medved (jmedved); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Ed Warnicke (eaw); Moiz Raja (moraja)
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo
If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving the non-core
parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it.
Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components like
Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.
However, I think the following Applications need to be more generic and protocol agnostic although the we only had an Openflow
implementation until now. Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations?
- forwardingrules-manager
- inventory-manager
- topology-manager
Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the home
for generic services like Topology and LLDP Discovery and potentially renaming it to be more generic to reflect the true nature of its content.
BTW, Does the list below represent the complete picture of migrations like this or is there more? This might be a good topic
for the TWS Call as well.
Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.
Migration will take following steps:
- copy corresponding projects from controller into openflowplugin
- change project and package names where necessary (without changing model content) (deadline:
09.01.2015)
- adapt downstream project in order to use those model projects (deadline: 16.01.2015)
- remove models from controller repository (deadline:
23.01.2015)
Models to migrate:
- model/model-flow-base
- model/model-flow-service
- model/model-flow-statistics
Apps to migrate
- statistics-manager
- forwardingrules-manager
- inventory-manager
- topology-lldp-discovery
- topology-manager
Donwstream projects (so far)
- aaa
- l2switch
- ovsdb
- openflowplugin
- affinity
- packetcable
- grupbasedpolicy
If you have questions, contributions, comments then please feel free to respond.
The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development.
And controller project plans to go more abstract/general way.
With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending on
dataStore result of those applications.
There are no deadlines for applications yet but moving them together with models might spare us some renaming work.
Thank you.
Regards,
Michal
_______________________________________________ L2switch-dev mailing list
L2switch-dev@...
https://lists.opendaylight.org/mailman/listinfo/l2switch-dev
|
|
|
