Re: [controller-dev] Problems in master doing a PUT to restconf/config/opendaylight-inventory:nodes/node/openflow:1

[Brady Allen Johnson]

Awesome, thanks!!

Brady


On 08/08/16 16:45, Tomas Cere -X (tcere - PANTHEON TECHNOLOGIES at 
Cisco) wrote:


There was an issue with Restconf’s ensureParents not working with 
augmentations,


the fix was merged a few moments ago.

https://bugs.opendaylight.org/show_bug.cgi?id=6358

Tomas

*From:*controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] *On Behalf Of 
*Brady Allen Johnson

*Sent:* Monday, August 08, 2016 16:26
*To:* groupbasedpolicy-...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org; 
openflowplugin-...@lists.opendaylight.org
*Subject:* [controller-dev] Problems in master doing a PUT to 
restconf/config/opendaylight-inventory:nodes/node/openflow:1


+openflow plugin

On 08/08/16 16:05, Brady Allen Johnson wrote:

Hello,

I think there is a problem with the Openflow plugin or mdsal in
master. I originally got this error with a GBP distribution that I
built locally, so to eliminate possible problems with my local
setup, I tried with this distro from Monday, August 8 from Nexus:


https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/groupbasedpolicy/distribution-karaf/0.4.0-SNAPSHOT/distribution-karaf-0.4.0-20160808.101440-223.tar.gz

The same problem described below works with this distro from
Wednesday, August 3:


https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/groupbasedpolicy/distribution-karaf/0.4.0-SNAPSHOT/distribution-karaf-0.4.0-20160803.220738-221.tar.gz


_The problem:_

When trying to run the GBP-SFC demo, I get the following error:

sending tunnel
PUT

http://192.168.50.1:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1
{
"node": [
{
"id": "openflow:1",
"ofoverlay:tunnel": [
{
"ip": "192.168.50.70",
"node-connector-id": "openflow:1:1",
"port": 6633,
"tunnel-type": "overlay:tunnel-type-vxlan-gpe"
},
{
"ip": "192.168.50.70",
"node-connector-id": "openflow:1:2",
"port": 4789,
"tunnel-type": "overlay:tunnel-type-vxlan"
}
]
}
]
}

{"errors":{"error":[{"error-type":"application","error-tag":"operation-failed","error-message":"Problem
while PUT operations"}]}}
Traceback (most recent call last):
  File "./demo-symmetric-chain/rest.py", line 713, in 
put(controller, DEFAULT_PORT, get_tunnel_uri_1(),
get_tunnel_data_1(), True)
  File "./demo-symmetric-chain/rest.py", line 39, in put
r.raise_for_status()
  File "/usr/lib/python2.7/dist-packages/requests/models.py", line
773, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 500 Server Error: Server Error


I also get these errors on the karaf console:

opendaylight-user@root>Exception in thread "CommitFutures-5"
org.opendaylight.netconf.sal.restconf.impl.RestconfDocumentedException:
errors: [RestconfError [error-type: application, error-tag:
operation-failed, error-message: Data did not pass validation.,
error-info: TransactionCommitFailedException{message=Data did not
pass validation., errorList=[RpcError [message=Data did not pass
validation., severity=ERROR, errorType=APPLICATION,
tag=operation-failed, applicationTag=null, info=null,

cause=org.opendaylight.yangtools.yang.data.api.schema.tree.ModifiedNodeDoesNotExistException:
Node /(urn:opendaylight:inventory?revision=2013-08-19)nodes/node
does not exist. Cannot apply modification to its children.]]}
at

org.opendaylight.controller.cluster.datastore.ShardDataTree.processNextTransaction(ShardDataTree.java:340)
at

org.opendaylight.controller.cluster.datastore.ShardDataTree.startCanCommit(ShardDataTree.java:360)
at

org.opendaylight.controller.cluster.datastore.SimpleShardDataTreeCohort.canCommit(SimpleShardDataTreeCohort.java:85)
at

org.opendaylight.controller.cluster.datastore.CohortEntry.canCommit(CohortEntry.java:98)
at

org.opendaylight.controller.cluster.datastore.ShardCommitCoordinator.handleCanCommit(ShardCommitCoordinator.java:237)
at

org.opendaylight.controller.cluster.datastore.ShardCommitCoordinator.handleReadyLocalTransaction(ShardCommitCoordinator.java:201)
at

org.opendaylight.controller.cluster.datastore.Shard.handleReadyLocalTransaction(Shard.java:438)
at

[controller-dev] Problems in master doing a PUT to restconf/config/opendaylight-inventory:nodes/node/openflow:1

[Brady Allen Johnson]

Hello,

I think there is a problem with the Openflow plugin or mdsal in master. 
I originally got this error with a GBP distribution that I built 
locally, so to eliminate possible problems with my local setup, I tried 
with this distro from Monday, August 8 from Nexus:


https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/groupbasedpolicy/distribution-karaf/0.4.0-SNAPSHOT/distribution-karaf-0.4.0-20160808.101440-223.tar.gz

The same problem described below works with this distro from Wednesday, 
August 3:


https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/groupbasedpolicy/distribution-karaf/0.4.0-SNAPSHOT/distribution-karaf-0.4.0-20160803.220738-221.tar.gz


_The problem:_

When trying to run the GBP-SFC demo, I get the following error:

   sending tunnel
   PUT
   
http://192.168.50.1:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1
   {
"node": [
{
"id": "openflow:1",
"ofoverlay:tunnel": [
{
"ip": "192.168.50.70",
"node-connector-id": "openflow:1:1",
"port": 6633,
"tunnel-type": "overlay:tunnel-type-vxlan-gpe"
},
{
"ip": "192.168.50.70",
"node-connector-id": "openflow:1:2",
"port": 4789,
"tunnel-type": "overlay:tunnel-type-vxlan"
}
]
}
]
   }
   
{"errors":{"error":[{"error-type":"application","error-tag":"operation-failed","error-message":"Problem
   while PUT operations"}]}}
   Traceback (most recent call last):
  File "./demo-symmetric-chain/rest.py", line 713, in 
put(controller, DEFAULT_PORT, get_tunnel_uri_1(),
   get_tunnel_data_1(), True)
  File "./demo-symmetric-chain/rest.py", line 39, in put
r.raise_for_status()
  File "/usr/lib/python2.7/dist-packages/requests/models.py", line
   773, in raise_for_status
raise HTTPError(http_error_msg, response=self)
   requests.exceptions.HTTPError: 500 Server Error: Server Error


I also get these errors on the karaf console:

   opendaylight-user@root>Exception in thread "CommitFutures-5"
   org.opendaylight.netconf.sal.restconf.impl.RestconfDocumentedException:
   errors: [RestconfError [error-type: application, error-tag:
   operation-failed, error-message: Data did not pass validation.,
   error-info: TransactionCommitFailedException{message=Data did not
   pass validation., errorList=[RpcError [message=Data did not pass
   validation., severity=ERROR, errorType=APPLICATION,
   tag=operation-failed, applicationTag=null, info=null,
   
cause=org.opendaylight.yangtools.yang.data.api.schema.tree.ModifiedNodeDoesNotExistException:
   Node /(urn:opendaylight:inventory?revision=2013-08-19)nodes/node
   does not exist. Cannot apply modification to its children.]]}
at
   
org.opendaylight.controller.cluster.datastore.ShardDataTree.processNextTransaction(ShardDataTree.java:340)
at
   
org.opendaylight.controller.cluster.datastore.ShardDataTree.startCanCommit(ShardDataTree.java:360)
at
   
org.opendaylight.controller.cluster.datastore.SimpleShardDataTreeCohort.canCommit(SimpleShardDataTreeCohort.java:85)
at
   
org.opendaylight.controller.cluster.datastore.CohortEntry.canCommit(CohortEntry.java:98)
at
   
org.opendaylight.controller.cluster.datastore.ShardCommitCoordinator.handleCanCommit(ShardCommitCoordinator.java:237)
at
   
org.opendaylight.controller.cluster.datastore.ShardCommitCoordinator.handleReadyLocalTransaction(ShardCommitCoordinator.java:201)
at
   
org.opendaylight.controller.cluster.datastore.Shard.handleReadyLocalTransaction(Shard.java:438)
at
   
org.opendaylight.controller.cluster.datastore.Shard.handleNonRaftCommand(Shard.java:240)
at
   
org.opendaylight.controller.cluster.raft.RaftActor.handleCommand(RaftActor.java:299)
at
   
org.opendaylight.controller.cluster.common.actor.AbstractUntypedPersistentActor.onReceiveCommand(AbstractUntypedPersistentActor.java:29)
at
   akka.persistence.UntypedPersistentActor.onReceive(PersistentActor.scala:170)
at
   
org.opendaylight.controller.cluster.common.actor.MeteringBehavior.apply(MeteringBehavior.java:97)
at
   akka.actor.ActorCell$$anonfun$become$1.applyOrElse(ActorCell.scala:544)
at akka.actor.Actor$class.aroundReceive(Actor.scala:484)
at
   
akka.persistence.UntypedPersistentActor.akka$persistence$Eventsourced$$super$aroundReceive(PersistentActor.scala:168)
at
   akka.persistence.Eventsourced$$anon$1.stateReceive(Eventsourced.scala:633)
at
   akka.persistence.Eventsourced$class.aroundReceive(Eventsourced.scala:179)
at
   

Re: [controller-dev] Health Checks to external network functions

[Brady Allen Johnson]

The SFC project has functionality that can "indirectly" monitor network 
functions (called Service Functions in SFC). I say indirectly since the 
monitoring is used for what we call Service Function (SF) scheduling 
algorithms, which helps us choose which SF to use based on either CPU 
load, or shortest path.


When we integrated ODL SFC into OPNFV, we didnt use the SF scheduling 
algorithms but instead delegated that to a VNF manager. Typically, the 
VNF manager would also monitor the network functions.


In Beryllium, the Armoury project was created to monitor the network 
load of a network function which could then report overloading 
situations to a VNF manager. The Armoury project didnt get much 
traction, and is effectively on hold for now.


The question needs to be asked if it really makes sense for ODL to 
monitor SFs/Network Functions or if something like a VNF manager should 
do it instead.


Regards,

Brady


On 20/09/16 07:31, Sela, Guy wrote:


Hi,

Is there any project/plugin in ODL that its purpose is to conduct 
health checks ?


I’m referring to the health of external machines that run network 
functions for example (firewalls, load balancers, content filtering, 
etc.).


Health checks can be pings, load, generic scripts etc.

In a real deployment, will you do those inside ODL? or use an external 
health tool that will notify status change to the ODL?


Thanks,

Guy Sela



___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev


___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] deprecating the config subsystem in Carbon?

[Brady Allen Johnson]

Just my 2 cents: I think Option 2 sounds very reasonable.

In SFC, I think we would even be ready to completely adapt to blueprint 
and no longer use the config system by the completion of Carbon.


Regards,

Brady


On 17/11/16 03:33, Colin Dixon wrote:

So, even though the file is in src/ it imports a generated file, see here:
https://github.com/opendaylight/lacp/blob/master/lacp-main/implementation/src/main/java/org/opendaylight/yang/gen/v1/urn/opendaylight/lacp/lacp/main/rev141216/LacpMainModule.java#L35

You could thus deprecate the generated class: in this case 
org.opendaylight.yang.gen.v1.urn.opendaylight.lacp.lacp.main.rev141216.AbstractLacpMainModule


That would work with a relatively simple change in the code generator 
and apply everywhere, right?


--Colin


On Wed, Nov 16, 2016 at 7:11 PM, Ryan Goulding 
> wrote:


You mean the Provider?  Most people adapt the Provider and put it
in src/ anyway;  I would guess this wouldn't really raise much
awareness but that is my own $0.02.  The easiest path forward is
probably to make sweeping announcements via email and strong
suggestions in the release notes... but I could be wrong.  Open to
discussion on the strategy going forward.  Tom Pantelis may have a
clever suggestion for this too...

Regards,

Ryan Goulding

On Wed, Nov 16, 2016 at 2:50 PM, Colin Dixon > wrote:

That sounds good to me. What's the right way for us to
"deprecate" the config subsystem. I guess the simplest thing
would be add an @deprecated decorator to the relevant classes
that get generated with a pointer to the docs on how to migrate.

--Colin


On Tue, Nov 15, 2016 at 5:07 PM, FREEMAN, BRIAN D
> wrote:

I think Option 2 is a reasonable approach.

Brian


-Original Message-
From: controller-dev-boun...@lists.opendaylight.org

[mailto:controller-dev-boun...@lists.opendaylight.org
] On
Behalf Of Robert Varga
Sent: Tuesday, November 15, 2016 4:46 PM
To: Alexis de Talhouët; thomas nadeau
Cc: controller-dev
Subject: Re: [controller-dev] deprecating the config
subsystem in Carbon?

On 11/15/2016 10:08 PM, Alexis de Talhouët wrote:
>
> Option 2:
> Deprecation notice in Carbon
> Adaptation in Nitrogen
> Removal in Oxygen
>
> During the kernel meeting I was more after option 3, but
I think option
> 2 make sense so downstream consumer can be notified
earlier in the
> process and start migrating things to blueprint.

I think option 2 works best, especially since we can
decide on when the
actual removal takes place -- which I think should be one
release after
we have shipped without internal projects using it.

Bye,
Robert

___
controller-dev mailing list
controller-dev@lists.opendaylight.org

https://lists.opendaylight.org/mailman/listinfo/controller-dev




___
controller-dev mailing list
controller-dev@lists.opendaylight.org

https://lists.opendaylight.org/mailman/listinfo/controller-dev






___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev


___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev