[controller-dev] [release] Autorelease fluorine-mvn35-openjdk8 failed to build sal-distributed-datastore from controller

[Jenkins]

Attention controller-devs,

Autorelease fluorine-mvn35-openjdk8 failed to build sal-distributed-datastore 
from controller in build
109. Attached is a snippet of the error message related to the
failure that we were able to automatically parse as well as console logs. 


Console Logs:
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/autorelease-release-fluorine-mvn35-openjdk8/109

Jenkins Build:
https://jenkins.opendaylight.org/releng/job/autorelease-release-fluorine-mvn35-openjdk8/109/

Please review and provide an ETA on when a fix will be available.

Thanks,
ODL releng/autorelease team



error.log.gz
Description: Binary data
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [release] Autorelease fluorine-mvn35-openjdk8 failed to build sal-distributed-datastore from controller

[Robert Varga]

On 09/05/2019 03:25, Jenkins wrote:
> Attention controller-devs,
> 
> Autorelease fluorine-mvn35-openjdk8 failed to build sal-distributed-datastore 
> from controller in build
> 108. Attached is a snippet of the error message related to the
> failure that we were able to automatically parse as well as console logs. 
> 
> 
> Console Logs:
> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/autorelease-release-fluorine-mvn35-openjdk8/108

*sigh* this test is getting unstable. I'll try to look at what's going
on next week.

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] [netconf-dev] Help regarding Yang 1.1 actions

[Emmett Cox]

On 09/05/2019 14:02, Robert Varga wrote:
> On 09/05/2019 13:27, Martin Sandberg wrote:
>> Hi Ajay,
>>
>>   
>>
>> Sorry, I can’t really describe the signaling sequence more than that. I
>> have basically no knowledge about the code, I have only tested ODL a
>> bit, and observed the behavior I described below. I don’t actually know
>> for a fact how ODL reads up the models from the node after the Hello
>> message exchange, it’s just an assumption that a  on RFC 7895
>> /modules-state is done, and then uploads each of those models. Hopefully
>> others who knows the code much better can answer detailed questions.
> Hello,
>
> the issue here is discovery of what modules does a particular server
> support, which we need to know in order to form our understanding of the
> data that can be exchanged with it.
>
> The baseline specification here is RFC6020, which requires all models to
> be announced: https://tools.ietf.org/html/rfc6020#section-5.6.4
>
> This obviously is inefficient and does not support transfer of schemas,
> which is required for seamless connection establishment. An alternative
> is RFC6022 (ietf-netconf-monitoring), which optional to implement.
>
> This mistake was rectified in YANG 1.1 (RFC7950), which refers to
> RFC7895 (ietf-yang-library) to provide capabilities similar to RFC6022.
>
> Hence our connection bootstrap process occurs in two phases, where the
> first phase bootstraps the basic understanding of models based on
> advertisement in , which allows us to start talking to the
> device -- i.e. interact with RFC6022/RFC7895, at which point we
> establish the connection based on the combined understanding of the
> device's schema.
>
>> If you turn on detailed tracing, you can maybe see the exact signaling
>> sequence.
> Yup, the sequence can be inferred at TRACE level, where netconf becomes
> very chatty about what it is doing.
>
>> Since the trace is only a WARNing, I guess it shouldn’t be treated as
>> something that is breaking anything, but I agree it could maybe have
>> sufficed as a INFO trace.
> Actually, the code should be re-visited to suppress the warning in case
> of :yang-library(:1.1) capability presence, as that is a promise that
> yang-library is available and the server is following RFC7950 specification.
>
> If the capability is not present, the warning still has to be present
> there, as in that case we are dealing with an inconsistent
> RFC6020/RFC6022 server.
>
>> I think our reason to only advertise the basic capabilities in the Hello
>> message is to be able to protect access to more sensitive
>> application-specific models via  on /modules-state by applying
>> access control mechanisms on that part of the model.
> That, and also to keep the  message small.
>
> Regards,
> Robert
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [netconf-dev] Help regarding Yang 1.1 actions

[Ajay Deep Singh]

Hi Martin,

Thanks for your inputs.

  *   Please can you help me understand how this “signaling sequence” work in 
ODl & how its initiated.? Also any light if you can throw on course of base 
action that are triggered from Odl to make sure Node capabilities are 
completely understood..?
  *   “The application-specific Yang 1.1 models are not advertised in the Hello 
message”, In this context on adding any new Node (Yang Model) we should be 
encountering same waring message every time which gives false message in logs 
as it doesn’t Stop Odl to perform any operation on Node, guess this message 
should be updated..?  I am fine with not finding specific capabilities in Hello 
message which I was expected to be present in it, as the Node is properly 
mounted in Odl I don’t suspect any problem there.


Also will request other members In dev list to please comment on queries posted 
in below mail chain.

Regards,
Ajay

From: Martin Sandberg
Sent: Wednesday, May 8, 2019 12:32 PM
To: Emmett Cox ; Robert Varga ; 
netconf-...@lists.opendaylight.org; controller-dev@lists.opendaylight.org
Cc: Ajay Deep Singh ; Mariusz Sobucki 
; Paul Dennehy ; 
mdsal-...@lists.opendaylight.org
Subject: RE: [netconf-dev] Help regarding Yang 1.1 actions

Hi Emmet,
Regarding ” 2019-05-07T16:22:13,468 | WARN  | 
remote-connector-processing-executor-12 | NetconfDevice  | 347 - 
org.opendaylight.net  conf.sal-netconf-connector - 1.9.0 | 
RemoteDevice{pnf-simulator}: Netconf device provides additional yang models not 
reported in hello message capabilities:”
The warning message you see appears when the netconf device only advertises a 
subset of its capabilities in its Hello message, and ODL later in the signaling 
sequence receives more Yang 1.1 models when it performs an RCF 6022 get-schema 
or  on RFC 7895 /modules-state (which lists both 1.0 and 1.1 models). I 
got the same message when testing ODL with our nodes, which apparently only 
advertise NETCONF (base + any capabilities), YANG 1.0 models, and the YANG 1.1 
RFC 7895 model. The application-specific Yang 1.1 models are not advertised in 
the Hello message, and are discovered by ODL later as described above. It 
didn’t cause any problem for me though, I could still perform configuration 
operations on the application-specific models.
You can probably configure on your device which capabilities that shall be 
included in the Hello message, but you probably don’t need do it, is my guess. 
Or do you suspect you have problem with not getting all capabilities in the 
Hello message?
Regards,
Martin

From: Emmett Cox mailto:emmett@est.tech>>
Sent: den 8 maj 2019 12:13
To: Robert Varga mailto:n...@hq.sk>>; 
netconf-...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org
Cc: Ajay Deep Singh 
mailto:ajay.deep.si...@ericsson.com>>; Mariusz 
Sobucki mailto:mariusz.sobu...@est.tech>>; Martin 
Sandberg mailto:martin.sandb...@ericsson.com>>; 
Paul Dennehy mailto:paul.denn...@est.tech>>; 
mdsal-...@lists.opendaylight.org
Subject: Re: [netconf-dev] Help regarding Yang 1.1 actions


Hi Everyone,

I emailed a while ago regarding the issues listed below( thanks for the 
response Robert, it was a great help).

Since then myself and my team have investigated further into netconf, restconf 
and mdsal, and were hoping to get some clarification regarding a few questions.

Firstly, we're wondering how exactly the wiring is done between restconf and 
mdsal -

  *   based upon previous response our understanding is that the 
restconf-nb-rfc8040 module is used for handling restconf requirements etc. 
relating to that rfc, or beyond that rfc, and that we will have to add 
DOMActionService support to that module through the Rfc8040RestConfWiring class 
and several other classes in that module. Is our understanding correct here?
  *   We are not sure whether this module will also generate the rest api's as 
part of the webpage, and what changes we would need to make to get this to work 
- or if we would need to make any changes. what other modules would be used in 
restconf to generate the rest api's and display them as part of the apidocs?
  *   Our current understanding of how the objects are instantiated in 
restconf-nb-rfc8040 is through the @inject annotation , which passes through 
the various objects needed eg. schemaHandler, domDataBroker etc. We think that 
these object are already instantiated in mdsal etc, and that the restconf 
module will request this information and generate the rest api's etc. based 
upon this information. is this understanding correct? and if so, what modules, 
classes etc. are used in restconf to facilitate this.



  *   We added a yang model to a simulated node and mounted it in odl - the 
yang model seems to come up in the apidocs, but we've been seeing this warning 
when we mount it:
 *   2019-05-07T16:22:13,468 | WARN  | 

Re: [controller-dev] [netconf-dev] Help regarding Yang 1.1 actions

[Robert Varga]

On 09/05/2019 13:27, Martin Sandberg wrote:
> Hi Ajay,
> 
>  
> 
> Sorry, I can’t really describe the signaling sequence more than that. I
> have basically no knowledge about the code, I have only tested ODL a
> bit, and observed the behavior I described below. I don’t actually know
> for a fact how ODL reads up the models from the node after the Hello
> message exchange, it’s just an assumption that a  on RFC 7895
> /modules-state is done, and then uploads each of those models. Hopefully
> others who knows the code much better can answer detailed questions.

Hello,

the issue here is discovery of what modules does a particular server
support, which we need to know in order to form our understanding of the
data that can be exchanged with it.

The baseline specification here is RFC6020, which requires all models to
be announced: https://tools.ietf.org/html/rfc6020#section-5.6.4

This obviously is inefficient and does not support transfer of schemas,
which is required for seamless connection establishment. An alternative
is RFC6022 (ietf-netconf-monitoring), which optional to implement.

This mistake was rectified in YANG 1.1 (RFC7950), which refers to
RFC7895 (ietf-yang-library) to provide capabilities similar to RFC6022.

Hence our connection bootstrap process occurs in two phases, where the
first phase bootstraps the basic understanding of models based on
advertisement in , which allows us to start talking to the
device -- i.e. interact with RFC6022/RFC7895, at which point we
establish the connection based on the combined understanding of the
device's schema.

> If you turn on detailed tracing, you can maybe see the exact signaling
> sequence.

Yup, the sequence can be inferred at TRACE level, where netconf becomes
very chatty about what it is doing.

> Since the trace is only a WARNing, I guess it shouldn’t be treated as
> something that is breaking anything, but I agree it could maybe have
> sufficed as a INFO trace.

Actually, the code should be re-visited to suppress the warning in case
of :yang-library(:1.1) capability presence, as that is a promise that
yang-library is available and the server is following RFC7950 specification.

If the capability is not present, the warning still has to be present
there, as in that case we are dealing with an inconsistent
RFC6020/RFC6022 server.

> I think our reason to only advertise the basic capabilities in the Hello
> message is to be able to protect access to more sensitive
> application-specific models via  on /modules-state by applying
> access control mechanisms on that part of the model.

That, and also to keep the  message small.

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] [netconf-dev] Help regarding Yang 1.1 actions

[Martin Sandberg]

Hi Ajay,

Sorry, I can’t really describe the signaling sequence more than that. I have 
basically no knowledge about the code, I have only tested ODL a bit, and 
observed the behavior I described below. I don’t actually know for a fact how 
ODL reads up the models from the node after the Hello message exchange, it’s 
just an assumption that a  on RFC 7895 /modules-state is done, and then 
uploads each of those models. Hopefully others who knows the code much better 
can answer detailed questions.

If you turn on detailed tracing, you can maybe see the exact signaling sequence.

Since the trace is only a WARNing, I guess it shouldn’t be treated as something 
that is breaking anything, but I agree it could maybe have sufficed as a INFO 
trace.
I think our reason to only advertise the basic capabilities in the Hello 
message is to be able to protect access to more sensitive application-specific 
models via  on /modules-state by applying access control mechanisms on 
that part of the model.

//Martin

From: Ajay Deep Singh
Sent: den 9 maj 2019 11:33
To: Martin Sandberg ; Emmett Cox 
; Robert Varga ; 
netconf-...@lists.opendaylight.org; controller-dev@lists.opendaylight.org
Cc: Mariusz Sobucki ; Paul Dennehy 
; mdsal-...@lists.opendaylight.org
Subject: RE: [netconf-dev] Help regarding Yang 1.1 actions

Hi Martin,

Thanks for your inputs.

  *   Please can you help me understand how this “signaling sequence” work in 
ODl & how its initiated.? Also any light if you can throw on course of base 
action that are triggered from Odl to make sure Node capabilities are 
completely understood..?
  *   “The application-specific Yang 1.1 models are not advertised in the Hello 
message”, In this context on adding any new Node (Yang Model) we should be 
encountering same waring message every time which gives false message in logs 
as it doesn’t Stop Odl to perform any operation on Node, guess this message 
should be updated..?  I am fine with not finding specific capabilities in Hello 
message which I was expected to be present in it, as the Node is properly 
mounted in Odl I don’t suspect any problem there.


Also will request other members In dev list to please comment on queries posted 
in below mail chain.

Regards,
Ajay

From: Martin Sandberg
Sent: Wednesday, May 8, 2019 12:32 PM
To: Emmett Cox mailto:emmett@est.tech>>; Robert Varga 
mailto:n...@hq.sk>>; 
netconf-...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org
Cc: Ajay Deep Singh 
mailto:ajay.deep.si...@ericsson.com>>; Mariusz 
Sobucki mailto:mariusz.sobu...@est.tech>>; Paul 
Dennehy mailto:paul.denn...@est.tech>>; 
mdsal-...@lists.opendaylight.org
Subject: RE: [netconf-dev] Help regarding Yang 1.1 actions

Hi Emmet,
Regarding ” 2019-05-07T16:22:13,468 | WARN  | 
remote-connector-processing-executor-12 | NetconfDevice  | 347 - 
org.opendaylight.net  conf.sal-netconf-connector - 1.9.0 | 
RemoteDevice{pnf-simulator}: Netconf device provides additional yang models not 
reported in hello message capabilities:”
The warning message you see appears when the netconf device only advertises a 
subset of its capabilities in its Hello message, and ODL later in the signaling 
sequence receives more Yang 1.1 models when it performs an RCF 6022 get-schema 
or  on RFC 7895 /modules-state (which lists both 1.0 and 1.1 models). I 
got the same message when testing ODL with our nodes, which apparently only 
advertise NETCONF (base + any capabilities), YANG 1.0 models, and the YANG 1.1 
RFC 7895 model. The application-specific Yang 1.1 models are not advertised in 
the Hello message, and are discovered by ODL later as described above. It 
didn’t cause any problem for me though, I could still perform configuration 
operations on the application-specific models.
You can probably configure on your device which capabilities that shall be 
included in the Hello message, but you probably don’t need do it, is my guess. 
Or do you suspect you have problem with not getting all capabilities in the 
Hello message?
Regards,
Martin

From: Emmett Cox mailto:emmett@est.tech>>
Sent: den 8 maj 2019 12:13
To: Robert Varga mailto:n...@hq.sk>>; 
netconf-...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org
Cc: Ajay Deep Singh 
mailto:ajay.deep.si...@ericsson.com>>; Mariusz 
Sobucki mailto:mariusz.sobu...@est.tech>>; Martin 
Sandberg mailto:martin.sandb...@ericsson.com>>; 
Paul Dennehy mailto:paul.denn...@est.tech>>; 
mdsal-...@lists.opendaylight.org
Subject: Re: [netconf-dev] Help regarding Yang 1.1 actions


Hi Everyone,

I emailed a while ago regarding the issues listed below( thanks for the 
response Robert, it was a great help).

Since then myself and my team have investigated further into netconf, restconf