From mhemmatp at cisco.com  Fri Feb  1 15:43:43 2019
From: mhemmatp at cisco.com (Masoud Hemmatpour (mhemmatp))
Date: Fri, 1 Feb 2019 15:43:43 +0000
Subject: [sysrepo-devel] Sysrepo Netopeer2-server failes
Message-ID: <92FC4AD0-B521-467F-973E-020CC7E72EF7@cisco.com>


 Hello all,

 I m going to connect Netopeer2-server to OpenDaylight. When netopeer2-server loads it gives me the following:

[WRN]: Sysrepo does not have the "ietf-netconf-server" module or keystored keys dir unknown, using default NETCONF server options.


I tried to install the ietf-netconf-server with its dependencies. However, again loading netopeer2-server faces this error:

Error by processing of the subscribe request (session id=1488598074): Invalid expression..

Any help is appreciated.

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sysrepo.org/archives/sysrepo-devel/attachments/20190201/e55969f8/attachment.html>

From JoLandry at advaoptical.com  Fri Feb  8 10:36:03 2019
From: JoLandry at advaoptical.com (Joan Landry)
Date: Fri, 8 Feb 2019 10:36:03 +0000
Subject: [sysrepo-devel] question on locks
Message-ID: <47a8aca380004f38aa4889f3e7f0eeb7@advaoptical.com>

1. is there a callback to get notified if a netconf client took the candidate lock
2. is there a way to via that callback to reject/accept the candidate lock 

Thanks


From mvasko at cesnet.cz  Fri Feb  8 11:28:11 2019
From: mvasko at cesnet.cz (=?utf-8?q?Michal_Va=C5=A1ko?=)
Date: Fri, 08 Feb 2019 12:28:11 +0100
Subject: [sysrepo-devel] 
 =?utf-8?b?Pz09P3V0Zi04P3E/ICBxdWVzdGlvbiBvbiBs?= =?utf-8?q?ocks?=
In-Reply-To: <47a8aca380004f38aa4889f3e7f0eeb7@advaoptical.com>
Message-ID: <2793-5c5d6800-4f-2cd0ea40@164075709>

Hi,
generally, no, there is no callback called in sysrepo as these RPCs (<lock> and <unlock>) are handled internally by netopeer2 and then only sr_lock_*() and sr_unlock_*() sysrepo functions are called. If you need this functionality, you will have to add it directly into netopeer2-server callbacks (op_un_lock.c).

By the way, candidate datastore is session-exclusive so locking it is completely redundant albeit supported only so that we conform to NETCONF.

Regards,
Michal

On Friday, February 8, 2019 11:36 CET, Joan Landry <JoLandry at advaoptical.com> wrote: 
 
> 1. is there a callback to get notified if a netconf client took the candidate lock
> 2. is there a way to via that callback to reject/accept the candidate lock 
> 
> Thanks
> 
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org
> http://lists.sysrepo.org/listinfo/sysrepo-devel
 
 


From JoLandry at advaoptical.com  Fri Feb  8 13:18:31 2019
From: JoLandry at advaoptical.com (Joan Landry)
Date: Fri, 8 Feb 2019 13:18:31 +0000
Subject: [sysrepo-devel] question on locks
In-Reply-To: <2793-5c5d6800-4f-2cd0ea40@164075709>
References: <47a8aca380004f38aa4889f3e7f0eeb7@advaoptical.com>
 <2793-5c5d6800-4f-2cd0ea40@164075709>
Message-ID: <ed52734d78824fc8add40a087c947ebf@advaoptical.com>

Thanks for the response.

-----Original Message-----
From: Michal Va?ko <mvasko at cesnet.cz> 
Sent: Friday, February 8, 2019 6:28 AM
To: Joan Landry <JoLandry at advaoptical.com>
Cc: sysrepo-devel at sysrepo.org
Subject: Re: [sysrepo-devel] question on locks

Hi,
generally, no, there is no callback called in sysrepo as these RPCs (<lock> and <unlock>) are handled internally by netopeer2 and then only sr_lock_*() and sr_unlock_*() sysrepo functions are called. If you need this functionality, you will have to add it directly into netopeer2-server callbacks (op_un_lock.c).

By the way, candidate datastore is session-exclusive so locking it is completely redundant albeit supported only so that we conform to NETCONF.

Regards,
Michal

On Friday, February 8, 2019 11:36 CET, Joan Landry <JoLandry at advaoptical.com> wrote: 
 
> 1. is there a callback to get notified if a netconf client took the 
> candidate lock 2. is there a way to via that callback to reject/accept 
> the candidate lock
> 
> Thanks
> 
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org
> http://lists.sysrepo.org/listinfo/sysrepo-devel
 
 


From JoLandry at advaoptical.com  Fri Feb  8 15:29:10 2019
From: JoLandry at advaoptical.com (Joan Landry)
Date: Fri, 8 Feb 2019 15:29:10 +0000
Subject: [sysrepo-devel] question on locks
In-Reply-To: <2793-5c5d6800-4f-2cd0ea40@164075709>
References: <47a8aca380004f38aa4889f3e7f0eeb7@advaoptical.com>
 <2793-5c5d6800-4f-2cd0ea40@164075709>
Message-ID: <96dc1da8bf974ceaa718856b1cdc0b23@advaoptical.com>

Not sure I understand the point regarding the candidate datastore - are you saying each session has their own version of this lock and it is not global lock like it is for the running datastore?


-----Original Message-----
From: Michal Va?ko <mvasko at cesnet.cz> 
Sent: Friday, February 8, 2019 6:28 AM
To: Joan Landry <JoLandry at advaoptical.com>
Cc: sysrepo-devel at sysrepo.org
Subject: Re: [sysrepo-devel] question on locks

Hi,
generally, no, there is no callback called in sysrepo as these RPCs (<lock> and <unlock>) are handled internally by netopeer2 and then only sr_lock_*() and sr_unlock_*() sysrepo functions are called. If you need this functionality, you will have to add it directly into netopeer2-server callbacks (op_un_lock.c).

By the way, candidate datastore is session-exclusive so locking it is completely redundant albeit supported only so that we conform to NETCONF.

Regards,
Michal

On Friday, February 8, 2019 11:36 CET, Joan Landry <JoLandry at advaoptical.com> wrote: 
 
> 1. is there a callback to get notified if a netconf client took the 
> candidate lock 2. is there a way to via that callback to reject/accept 
> the candidate lock
> 
> Thanks
> 
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org
> http://lists.sysrepo.org/listinfo/sysrepo-devel
 
 


From mvasko at cesnet.cz  Mon Feb 11 07:23:49 2019
From: mvasko at cesnet.cz (=?utf-8?q?Michal_Va=C5=A1ko?=)
Date: Mon, 11 Feb 2019 08:23:49 +0100
Subject: [sysrepo-devel] 
 =?utf-8?b?Pz09P3V0Zi04P3E/ICBxdWVzdGlvbiBvbiBs?= =?utf-8?q?ocks?=
In-Reply-To: <96dc1da8bf974ceaa718856b1cdc0b23@advaoptical.com>
Message-ID: <7bf5-5c612300-55-3398efc0@189055380>

Hi,
I could have explained it a bit more. No, the candidate lock is global and behaves just like the lock for running. However, there is no point in locking this datastore and hence preventing other sessions from writing into the candidate datastore because all the sessions have their own candidate datastore version so they can all write simultaneously into it and there will be no data race or any other concurrency problem.

Regards,
Michal

On Friday, February 8, 2019 16:29 CET, Joan Landry <JoLandry at advaoptical.com> wrote: 
 
> Not sure I understand the point regarding the candidate datastore - are you saying each session has their own version of this lock and it is not global lock like it is for the running datastore?
> 
> 
> -----Original Message-----
> From: Michal Va?ko <mvasko at cesnet.cz> 
> Sent: Friday, February 8, 2019 6:28 AM
> To: Joan Landry <JoLandry at advaoptical.com>
> Cc: sysrepo-devel at sysrepo.org
> Subject: Re: [sysrepo-devel] question on locks
> 
> Hi,
> generally, no, there is no callback called in sysrepo as these RPCs (<lock> and <unlock>) are handled internally by netopeer2 and then only sr_lock_*() and sr_unlock_*() sysrepo functions are called. If you need this functionality, you will have to add it directly into netopeer2-server callbacks (op_un_lock.c).
> 
> By the way, candidate datastore is session-exclusive so locking it is completely redundant albeit supported only so that we conform to NETCONF.
> 
> Regards,
> Michal
> 
> On Friday, February 8, 2019 11:36 CET, Joan Landry <JoLandry at advaoptical.com> wrote: 
>  
> > 1. is there a callback to get notified if a netconf client took the 
> > candidate lock 2. is there a way to via that callback to reject/accept 
> > the candidate lock
> > 
> > Thanks
> > 
> > _______________________________________________
> > sysrepo-devel mailing list
> > sysrepo-devel at sysrepo.org
> > http://lists.sysrepo.org/listinfo/sysrepo-devel
>  
>  
> 
 
 


From JoLandry at advaoptical.com  Mon Feb 11 08:18:50 2019
From: JoLandry at advaoptical.com (Joan Landry)
Date: Mon, 11 Feb 2019 08:18:50 +0000
Subject: [sysrepo-devel] question on locks
In-Reply-To: <7bf5-5c612300-55-3398efc0@189055380>
References: <96dc1da8bf974ceaa718856b1cdc0b23@advaoptical.com>
 <7bf5-5c612300-55-3398efc0@189055380>
Message-ID: <f76f0f5adaaa47238a5fd4d045aba55d@advaoptical.com>

Thanks for that clarification.

If you don?t mind I would like to know if you would share  your view on when the user should take the running lock (assuming they are ready to commit their candidate to running)? 
Should they be prepared to do it iteratively till the running lock is available or should they theoretically take the running lock prior to doing the edit on their candidate

Again - thanks for your insight into this.

-----Original Message-----
From: Michal Va?ko <mvasko at cesnet.cz> 
Sent: Monday, February 11, 2019 2:24 AM
To: Joan Landry <JoLandry at advaoptical.com>
Cc: sysrepo-devel at sysrepo.org
Subject: RE: [sysrepo-devel] question on locks

Hi,
I could have explained it a bit more. No, the candidate lock is global and behaves just like the lock for running. However, there is no point in locking this datastore and hence preventing other sessions from writing into the candidate datastore because all the sessions have their own candidate datastore version so they can all write simultaneously into it and there will be no data race or any other concurrency problem.

Regards,
Michal

On Friday, February 8, 2019 16:29 CET, Joan Landry <JoLandry at advaoptical.com> wrote: 
 
> Not sure I understand the point regarding the candidate datastore - are you saying each session has their own version of this lock and it is not global lock like it is for the running datastore?
> 
> 
> -----Original Message-----
> From: Michal Va?ko <mvasko at cesnet.cz>
> Sent: Friday, February 8, 2019 6:28 AM
> To: Joan Landry <JoLandry at advaoptical.com>
> Cc: sysrepo-devel at sysrepo.org
> Subject: Re: [sysrepo-devel] question on locks
> 
> Hi,
> generally, no, there is no callback called in sysrepo as these RPCs (<lock> and <unlock>) are handled internally by netopeer2 and then only sr_lock_*() and sr_unlock_*() sysrepo functions are called. If you need this functionality, you will have to add it directly into netopeer2-server callbacks (op_un_lock.c).
> 
> By the way, candidate datastore is session-exclusive so locking it is completely redundant albeit supported only so that we conform to NETCONF.
> 
> Regards,
> Michal
> 
> On Friday, February 8, 2019 11:36 CET, Joan Landry <JoLandry at advaoptical.com> wrote: 
>  
> > 1. is there a callback to get notified if a netconf client took the 
> > candidate lock 2. is there a way to via that callback to 
> > reject/accept the candidate lock
> > 
> > Thanks
> > 
> > _______________________________________________
> > sysrepo-devel mailing list
> > sysrepo-devel at sysrepo.org
> > http://lists.sysrepo.org/listinfo/sysrepo-devel
>  
>  
> 
 
 


From mvasko at cesnet.cz  Mon Feb 11 08:25:39 2019
From: mvasko at cesnet.cz (=?utf-8?q?Michal_Va=C5=A1ko?=)
Date: Mon, 11 Feb 2019 09:25:39 +0100
Subject: [sysrepo-devel] 
 =?utf-8?b?Pz09P3V0Zi04P3E/ICBxdWVzdGlvbiBvbiBs?= =?utf-8?q?ocks?=
In-Reply-To: <f76f0f5adaaa47238a5fd4d045aba55d@advaoptical.com>
Message-ID: <7bf5-5c613180-61-3398efc0@189055545>

Hi,
this is all about the problem of session A performing certain changes in its candidate datastore, then session B changing the running datastore, and finally session A committing its candidate datastore into running.

If session A does not hold running lock during this whole process then the changes of session B will be lost. If it does, then session B will not even be allowed to make the changes. You need to chose the behavior that suits you more.

Regards,
Michal

On Monday, February 11, 2019 09:18 CET, Joan Landry <JoLandry at advaoptical.com> wrote: 
 
> Thanks for that clarification.
> 
> If you don?t mind I would like to know if you would share  your view on when the user should take the running lock (assuming they are ready to commit their candidate to running)? 
> Should they be prepared to do it iteratively till the running lock is available or should they theoretically take the running lock prior to doing the edit on their candidate
> 
> Again - thanks for your insight into this.
> 
> -----Original Message-----
> From: Michal Va?ko <mvasko at cesnet.cz> 
> Sent: Monday, February 11, 2019 2:24 AM
> To: Joan Landry <JoLandry at advaoptical.com>
> Cc: sysrepo-devel at sysrepo.org
> Subject: RE: [sysrepo-devel] question on locks
> 
> Hi,
> I could have explained it a bit more. No, the candidate lock is global and behaves just like the lock for running. However, there is no point in locking this datastore and hence preventing other sessions from writing into the candidate datastore because all the sessions have their own candidate datastore version so they can all write simultaneously into it and there will be no data race or any other concurrency problem.
> 
> Regards,
> Michal
> 
> On Friday, February 8, 2019 16:29 CET, Joan Landry <JoLandry at advaoptical.com> wrote: 
>  
> > Not sure I understand the point regarding the candidate datastore - are you saying each session has their own version of this lock and it is not global lock like it is for the running datastore?
> > 
> > 
> > -----Original Message-----
> > From: Michal Va?ko <mvasko at cesnet.cz>
> > Sent: Friday, February 8, 2019 6:28 AM
> > To: Joan Landry <JoLandry at advaoptical.com>
> > Cc: sysrepo-devel at sysrepo.org
> > Subject: Re: [sysrepo-devel] question on locks
> > 
> > Hi,
> > generally, no, there is no callback called in sysrepo as these RPCs (<lock> and <unlock>) are handled internally by netopeer2 and then only sr_lock_*() and sr_unlock_*() sysrepo functions are called. If you need this functionality, you will have to add it directly into netopeer2-server callbacks (op_un_lock.c).
> > 
> > By the way, candidate datastore is session-exclusive so locking it is completely redundant albeit supported only so that we conform to NETCONF.
> > 
> > Regards,
> > Michal
> > 
> > On Friday, February 8, 2019 11:36 CET, Joan Landry <JoLandry at advaoptical.com> wrote: 
> >  
> > > 1. is there a callback to get notified if a netconf client took the 
> > > candidate lock 2. is there a way to via that callback to 
> > > reject/accept the candidate lock
> > > 
> > > Thanks
> > > 
> > > _______________________________________________
> > > sysrepo-devel mailing list
> > > sysrepo-devel at sysrepo.org
> > > http://lists.sysrepo.org/listinfo/sysrepo-devel
> >  
> >  
> > 
>  
>  
> 
 
 


From hongjun.ni at intel.com  Wed Feb 13 01:04:40 2019
From: hongjun.ni at intel.com (Ni, Hongjun)
Date: Wed, 13 Feb 2019 01:04:40 +0000
Subject: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
In-Reply-To: <1582C6A199AEF329.22639@lists.fd.io>
References: <963AC32C-B995-4D2E-9905-F0957922E194@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9DC0E@shsmsx102.ccr.corp.intel.com>
 <C7E6BFC6-F9E5-4AA1-BF22-C4351F7FF8DF@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9E290@shsmsx102.ccr.corp.intel.com>
 <075a4b4a88df48beb58c9e1ca568c10a@XCH-RCD-002.cisco.com>
 <1582C6A199AEF329.22639@lists.fd.io>
Message-ID: <A778FB3954515F498B35C4F5403D4F443FC9E811@shsmsx102.ccr.corp.intel.com>

Hi Sysrepo Maintainers and Developers,

We are working on Sweetcomb project, which has been leveraging Sysrepo as a Data Store.
Thank you all for doing a great work!

At present, we have a concern and need your great help.
Please see below email thread for details.
In order to avoid work duplication, best option, IMO, would be to have dep/rpm
in a repo that belongs to sysrepo maintainers.

Thanks,
Hongjun

From: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io> [mailto:sweetcomb-dev at lists.fd.io] On Behalf Of Rastislav Szabo -X (raszabo - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
Sent: Tuesday, February 12, 2019 5:30 PM
To: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>
Subject: Re: [sweetcomb-dev] sysrepo binary distributions

Hi Hongjun,

> What is your opinion on having sysrepo dep/rpm in a repo?

Good idea. You can use e.g. https://help.launchpad.net/Packaging/PPA for building the Ubuntu deb packages. We also had automated Docker builds for Sysrepo some time ago, it seems they are still being built: https://hub.docker.com/r/sysrepo/sysrepo-netopeer2

Anyway, as I am no longer maintainer of sysrepo, I would recommend asking on the sysrepo-devel mailing list (sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org>).

Rastislav

From: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io> <sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>> On Behalf Of Ni, Hongjun
Sent: Tuesday, February 12, 2019 6:22 AM
To: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>
Subject: Re: [sweetcomb-dev] sysrepo binary distributions

Hi Luca,
Thank you for your clear explanation.

Hi Rastislav,
What is your opinion on having sysrepo dep/rpm in a repo?
Or having other options?

Thanks,
Hongjun

From: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io> [mailto:sweetcomb-dev at lists.fd.io] On Behalf Of Luca Muscariello via Lists.Fd.Io
Sent: Monday, February 11, 2019 4:37 PM
To: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>
Subject: Re: [sweetcomb-dev] sysrepo binary distributions

Hi Hongjun,

Sysrepo does not come with a binary distribution. At least I did not find any.

I don?t know if some of the sysrepo maintainers are also on this list,
but IMO having binary distros helps quite a lot.

If I need to deploy sysrepo in a container, currently I need to check out the code
and build it or prepare an image myself (I?d like to avoid to install gcc in the container).
Or I have to create a repo on my own and spin off containers that will use that repo.
This option is sub-optimal as I may need to catch up with new releases manually.

In order to avoid work duplication, best option, IMO, would be to have dep/rpm
in a repo that belongs to sysrepo maintainers.

Consider that current sweetcomb plugins may require to be installed in
a different location if the target OS is Ubuntu or CentOS.
Having consistency while installing sysrepo and all sysrepo?s dependencies + sweetcomb
seems to be quite useful to enforce sanity checks in the target OS.

Does it make sense?

Best
Luca




From: <sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>> on behalf of "Ni, Hongjun" <hongjun.ni at intel.com<mailto:hongjun.ni at intel.com>>
Reply-To: "sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>" <sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>>
Date: Monday 11 February 2019 at 06:11
To: "sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>" <sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>>
Subject: Re: [sweetcomb-dev] sysrepo binary distributions

Hi Luca,

Sorry for delayed response because of one week?s public holiday.

We are packaging and uploading deb/rpm for Sweetcomb as a whole to package cloud.
Do you mean that we need to package sysrepo as a separate rpm/deb to package cloud?

Thanks,
Hongjun

From: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io> [mailto:sweetcomb-dev at lists.fd.io] On Behalf Of Luca Muscariello via Lists.Fd.Io
Sent: Friday, February 8, 2019 6:51 PM
To: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>
Subject: [sweetcomb-dev] sysrepo binary distributions


Hi everyone,

Is anybody aware of a binary distribution of sysrepo for Ubuntu/CentOS
and distribution in deb/rpm repos?




Thanks
Luca

_._,_._,_
________________________________
Links:

You receive all messages sent to this group.

View/Reply Online (#185)<https://lists.fd.io/g/sweetcomb-dev/message/185> | Reply To Group<mailto:sweetcomb-dev at lists.fd.io?subject=Re:%20Re%3A%20%5Bsweetcomb-dev%5D%20sysrepo%20binary%20distributions> | Reply To Sender<mailto:hongjun.ni at intel.com?subject=Private:%20Re:%20Re%3A%20%5Bsweetcomb-dev%5D%20sysrepo%20binary%20distributions> | Mute This Topic<https://lists.fd.io/mt/29700321/675159> | New Topic<https://lists.fd.io/g/sweetcomb-dev/post>

Your Subscription<https://lists.fd.io/g/sweetcomb-dev/editsub/675159> | Contact Group Owner<mailto:sweetcomb-dev+owner at lists.fd.io> | Unsubscribe<https://lists.fd.io/g/sweetcomb-dev/leave/3375019/1360326146/xyzzy> [hongjun.ni at intel.com]
_._,_._,_
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sysrepo.org/archives/sysrepo-devel/attachments/20190213/02e01d53/attachment.html>

From mislav.novakovic at sartura.hr  Wed Feb 13 10:36:49 2019
From: mislav.novakovic at sartura.hr (Mislav Novakovic)
Date: Wed, 13 Feb 2019 11:36:49 +0100
Subject: [sysrepo-devel] deprecating sysrepo Lua bindings
Message-ID: <CACmwirNfKYLzMA3kQ46Oo1XKS7C9UMmmJgh2dUW8HChbUaCGbA@mail.gmail.com>

Hi,

we are planing to deprecate the Sysrepo Lua bindings.
With the current changes to the Sysrepo C++ bindings we had to use
simple wrapper class (ptr class) for the objects returned and sent to
the Lua bindings which makes them a bit awkward to use now, the
example below:

 -            change = sess:get_change_next(it)
+            change = sr.ptr(sess:get_change_next(it))

We used Lua bindings for scripting on OpenWrt alongside with Python
but now Python is better suited for that. Besides us, we aren't aware
of any one using the Lua bindings and they are making the C++/Python
bindings harder to maintain.

Regards,
Mislav

From hongjun.ni at intel.com  Thu Feb 14 04:46:34 2019
From: hongjun.ni at intel.com (Ni, Hongjun)
Date: Thu, 14 Feb 2019 04:46:34 +0000
Subject: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
In-Reply-To: <1582C6DF44DED5BC.22639@lists.fd.io>
References: <963AC32C-B995-4D2E-9905-F0957922E194@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9DC0E@shsmsx102.ccr.corp.intel.com>
 <C7E6BFC6-F9E5-4AA1-BF22-C4351F7FF8DF@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9E290@shsmsx102.ccr.corp.intel.com>
 <075a4b4a88df48beb58c9e1ca568c10a@XCH-RCD-002.cisco.com>
 <1582C6A199AEF329.22639@lists.fd.io> <1582C6DF44DED5BC.22639@lists.fd.io>
Message-ID: <A778FB3954515F498B35C4F5403D4F443FC9F001@shsmsx102.ccr.corp.intel.com>

Hi Sysrepo Maintainers and Developers,

We are working on Sweetcomb project, which has been leveraging Sysrepo as a Data Store.
Thank you all for doing a great work!

At present, we have a concern and need your great help.
Please see below email thread for details.
In order to avoid work duplication, best option, IMO, would be to have dep/rpm
in a repo that belongs to sysrepo maintainers.

Thanks,
Hongjun

From: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io> [mailto:sweetcomb-dev at lists.fd.io] On Behalf Of Rastislav Szabo -X (raszabo - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
Sent: Tuesday, February 12, 2019 5:30 PM
To: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>
Subject: Re: [sweetcomb-dev] sysrepo binary distributions

Hi Hongjun,

> What is your opinion on having sysrepo dep/rpm in a repo?

Good idea. You can use e.g. https://help.launchpad.net/Packaging/PPA for building the Ubuntu deb packages. We also had automated Docker builds for Sysrepo some time ago, it seems they are still being built: https://hub.docker.com/r/sysrepo/sysrepo-netopeer2

Anyway, as I am no longer maintainer of sysrepo, I would recommend asking on the sysrepo-devel mailing list (sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org>).

Rastislav

From: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io> <sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>> On Behalf Of Ni, Hongjun
Sent: Tuesday, February 12, 2019 6:22 AM
To: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>
Subject: Re: [sweetcomb-dev] sysrepo binary distributions

Hi Luca,
Thank you for your clear explanation.

Hi Rastislav,
What is your opinion on having sysrepo dep/rpm in a repo?
Or having other options?

Thanks,
Hongjun

From: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io> [mailto:sweetcomb-dev at lists.fd.io] On Behalf Of Luca Muscariello via Lists.Fd.Io
Sent: Monday, February 11, 2019 4:37 PM
To: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>
Subject: Re: [sweetcomb-dev] sysrepo binary distributions

Hi Hongjun,

Sysrepo does not come with a binary distribution. At least I did not find any.

I don?t know if some of the sysrepo maintainers are also on this list,
but IMO having binary distros helps quite a lot.

If I need to deploy sysrepo in a container, currently I need to check out the code
and build it or prepare an image myself (I?d like to avoid to install gcc in the container).
Or I have to create a repo on my own and spin off containers that will use that repo.
This option is sub-optimal as I may need to catch up with new releases manually.

In order to avoid work duplication, best option, IMO, would be to have dep/rpm
in a repo that belongs to sysrepo maintainers.

Consider that current sweetcomb plugins may require to be installed in
a different location if the target OS is Ubuntu or CentOS.
Having consistency while installing sysrepo and all sysrepo?s dependencies + sweetcomb
seems to be quite useful to enforce sanity checks in the target OS.

Does it make sense?

Best
Luca




From: <sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>> on behalf of "Ni, Hongjun" <hongjun.ni at intel.com<mailto:hongjun.ni at intel.com>>
Reply-To: "sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>" <sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>>
Date: Monday 11 February 2019 at 06:11
To: "sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>" <sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>>
Subject: Re: [sweetcomb-dev] sysrepo binary distributions

Hi Luca,

Sorry for delayed response because of one week?s public holiday.

We are packaging and uploading deb/rpm for Sweetcomb as a whole to package cloud.
Do you mean that we need to package sysrepo as a separate rpm/deb to package cloud?

Thanks,
Hongjun

From: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io> [mailto:sweetcomb-dev at lists.fd.io] On Behalf Of Luca Muscariello via Lists.Fd.Io
Sent: Friday, February 8, 2019 6:51 PM
To: sweetcomb-dev at lists.fd.io<mailto:sweetcomb-dev at lists.fd.io>
Subject: [sweetcomb-dev] sysrepo binary distributions


Hi everyone,

Is anybody aware of a binary distribution of sysrepo for Ubuntu/CentOS
and distribution in deb/rpm repos?




Thanks
Luca

_._,_._,_
________________________________
Links:

You receive all messages sent to this group.

View/Reply Online (#186)<https://lists.fd.io/g/sweetcomb-dev/message/186> | Reply To Group<mailto:sweetcomb-dev at lists.fd.io?subject=Re:%20Re%3A%20%5Bsweetcomb-dev%5D%20sysrepo%20binary%20distributions> | Reply To Sender<mailto:hongjun.ni at intel.com?subject=Private:%20Re:%20Re%3A%20%5Bsweetcomb-dev%5D%20sysrepo%20binary%20distributions> | Mute This Topic<https://lists.fd.io/mt/29700321/675159> | New Topic<https://lists.fd.io/g/sweetcomb-dev/post>

Your Subscription<https://lists.fd.io/g/sweetcomb-dev/editsub/675159> | Contact Group Owner<mailto:sweetcomb-dev+owner at lists.fd.io> | Unsubscribe<https://lists.fd.io/g/sweetcomb-dev/leave/3375019/1360326146/xyzzy> [hongjun.ni at intel.com]
_._,_._,_
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sysrepo.org/archives/sysrepo-devel/attachments/20190214/128e79dc/attachment.html>

From swmike at swm.pp.se  Thu Feb 14 05:34:56 2019
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 14 Feb 2019 06:34:56 +0100 (CET)
Subject: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
In-Reply-To: <A778FB3954515F498B35C4F5403D4F443FC9F001@shsmsx102.ccr.corp.intel.com>
References: <963AC32C-B995-4D2E-9905-F0957922E194@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9DC0E@shsmsx102.ccr.corp.intel.com>
 <C7E6BFC6-F9E5-4AA1-BF22-C4351F7FF8DF@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9E290@shsmsx102.ccr.corp.intel.com>
 <075a4b4a88df48beb58c9e1ca568c10a@XCH-RCD-002.cisco.com>
 <1582C6A199AEF329.22639@lists.fd.io> <1582C6DF44DED5BC.22639@lists.fd.io>
 <A778FB3954515F498B35C4F5403D4F443FC9F001@shsmsx102.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.20.1902140626440.23912@uplift.swm.pp.se>

On Thu, 14 Feb 2019, Ni, Hongjun wrote:

> In order to avoid work duplication, best option, IMO, would be to have 
> dep/rpm in a repo that belongs to sysrepo maintainers.

This has been on our radar for quite some time and I agree that it would 
be great to have rpm/deb for all major distributions and versions for all 
the dependencies needed for Sysrepo. This is not the first time we get 
this request.

However, all our resources right now is aimed towards development of 
Sysrepo and and we don't currently have the skill set and man hours to 
well maintain repos for these.

If there is someone willing to become maintainer for packages, that'd be 
greatly welcome. This isn't isolated to just packaging, we're an open 
project and if someone wants to contribute more closely, that's welcome as 
well. We always need more developers and people who can do integration and 
packaging/testing.

So if someone can volunteer to do this, we'd gladly designate these as 
the official sysrepo repo:s for packages.

Thanks for your support.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From hongjun.ni at intel.com  Thu Feb 14 05:39:02 2019
From: hongjun.ni at intel.com (Ni, Hongjun)
Date: Thu, 14 Feb 2019 05:39:02 +0000
Subject: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
In-Reply-To: <alpine.DEB.2.20.1902140626440.23912@uplift.swm.pp.se>
References: <963AC32C-B995-4D2E-9905-F0957922E194@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9DC0E@shsmsx102.ccr.corp.intel.com>
 <C7E6BFC6-F9E5-4AA1-BF22-C4351F7FF8DF@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9E290@shsmsx102.ccr.corp.intel.com>
 <075a4b4a88df48beb58c9e1ca568c10a@XCH-RCD-002.cisco.com>
 <1582C6A199AEF329.22639@lists.fd.io> <1582C6DF44DED5BC.22639@lists.fd.io>
 <A778FB3954515F498B35C4F5403D4F443FC9F001@shsmsx102.ccr.corp.intel.com>
 <alpine.DEB.2.20.1902140626440.23912@uplift.swm.pp.se>
Message-ID: <A778FB3954515F498B35C4F5403D4F443FC9F0A8@shsmsx102.ccr.corp.intel.com>


Thank you Mikael! 

Sweetcomb community will discuss it in today's weekly meeting.
Hope we will figure out an applicable way.

Thanks,
Hongjun

-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
Sent: Thursday, February 14, 2019 1:35 PM
To: Ni, Hongjun <hongjun.ni at intel.com>
Cc: sysrepo-devel at sysrepo.org
Subject: Re: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions

On Thu, 14 Feb 2019, Ni, Hongjun wrote:

> In order to avoid work duplication, best option, IMO, would be to have 
> dep/rpm in a repo that belongs to sysrepo maintainers.

This has been on our radar for quite some time and I agree that it would be great to have rpm/deb for all major distributions and versions for all the dependencies needed for Sysrepo. This is not the first time we get this request.

However, all our resources right now is aimed towards development of Sysrepo and and we don't currently have the skill set and man hours to well maintain repos for these.

If there is someone willing to become maintainer for packages, that'd be greatly welcome. This isn't isolated to just packaging, we're an open project and if someone wants to contribute more closely, that's welcome as well. We always need more developers and people who can do integration and packaging/testing.

So if someone can volunteer to do this, we'd gladly designate these as the official sysrepo repo:s for packages.

Thanks for your support.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se

From lumuscar at cisco.com  Thu Feb 14 10:10:46 2019
From: lumuscar at cisco.com (Luca Muscariello (lumuscar))
Date: Thu, 14 Feb 2019 10:10:46 +0000
Subject: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
In-Reply-To: <A778FB3954515F498B35C4F5403D4F443FC9F0A8@shsmsx102.ccr.corp.intel.com>
References: <963AC32C-B995-4D2E-9905-F0957922E194@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9DC0E@shsmsx102.ccr.corp.intel.com>
 <C7E6BFC6-F9E5-4AA1-BF22-C4351F7FF8DF@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9E290@shsmsx102.ccr.corp.intel.com>
 <075a4b4a88df48beb58c9e1ca568c10a@XCH-RCD-002.cisco.com>
 <1582C6A199AEF329.22639@lists.fd.io> <1582C6DF44DED5BC.22639@lists.fd.io>
 <A778FB3954515F498B35C4F5403D4F443FC9F001@shsmsx102.ccr.corp.intel.com>
 <alpine.DEB.2.20.1902140626440.23912@uplift.swm.pp.se>
 <A778FB3954515F498B35C4F5403D4F443FC9F0A8@shsmsx102.ccr.corp.intel.com>
Message-ID: <BF6DF192-C56B-4C38-816B-4C8CA05C4B68@cisco.com>

Mikael,

We could help to set CI infra.
One point to clarify is who's supposed to host the infra.

One option is LFN but I'm not sure that would be ok as 
sysrepo is not an LFN project. FYI, LFN/fd.io is using package cloud.

Other infras are possible but I guess sysrepo maintainers may have a preference.

Also, my intent was to only support Ubuntu 18/16 and CentOS 7.

Thanks
Luca




?On 14/02/2019 06:39, "sweetcomb-dev at lists.fd.io on behalf of Ni, Hongjun" <sweetcomb-dev at lists.fd.io on behalf of hongjun.ni at intel.com> wrote:

    
    Thank you Mikael! 
    
    Sweetcomb community will discuss it in today's weekly meeting.
    Hope we will figure out an applicable way.
    
    Thanks,
    Hongjun
    
    -----Original Message-----
    From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
    Sent: Thursday, February 14, 2019 1:35 PM
    To: Ni, Hongjun <hongjun.ni at intel.com>
    Cc: sysrepo-devel at sysrepo.org
    Subject: Re: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
    
    On Thu, 14 Feb 2019, Ni, Hongjun wrote:
    
    > In order to avoid work duplication, best option, IMO, would be to have 
    > dep/rpm in a repo that belongs to sysrepo maintainers.
    
    This has been on our radar for quite some time and I agree that it would be great to have rpm/deb for all major distributions and versions for all the dependencies needed for Sysrepo. This is not the first time we get this request.
    
    However, all our resources right now is aimed towards development of Sysrepo and and we don't currently have the skill set and man hours to well maintain repos for these.
    
    If there is someone willing to become maintainer for packages, that'd be greatly welcome. This isn't isolated to just packaging, we're an open project and if someone wants to contribute more closely, that's welcome as well. We always need more developers and people who can do integration and packaging/testing.
    
    So if someone can volunteer to do this, we'd gladly designate these as the official sysrepo repo:s for packages.
    
    Thanks for your support.
    
    -- 
    Mikael Abrahamsson    email: swmike at swm.pp.se
    
    -=-=-=-=-=-=-=-=-=-=-=-
    Links: You receive all messages sent to this group.
    
    View/Reply Online (#188): https://lists.fd.io/g/sweetcomb-dev/message/188
    Mute This Topic: https://lists.fd.io/mt/29835719/675095
    Group Owner: sweetcomb-dev+owner at lists.fd.io
    Unsubscribe: https://lists.fd.io/g/sweetcomb-dev/leave/3620860/1123205057/xyzzy  [lumuscar+fdio at cisco.com]
    -=-=-=-=-=-=-=-=-=-=-=-
    
    


From lumuscar+fdio at cisco.com  Thu Feb 14 10:11:25 2019
From: lumuscar+fdio at cisco.com (Luca Muscariello)
Date: Thu, 14 Feb 2019 11:11:25 +0100
Subject: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
In-Reply-To: <A778FB3954515F498B35C4F5403D4F443FC9F0A8@shsmsx102.ccr.corp.intel.com>
References: <963AC32C-B995-4D2E-9905-F0957922E194@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9DC0E@shsmsx102.ccr.corp.intel.com>
 <C7E6BFC6-F9E5-4AA1-BF22-C4351F7FF8DF@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9E290@shsmsx102.ccr.corp.intel.com>
 <075a4b4a88df48beb58c9e1ca568c10a@XCH-RCD-002.cisco.com>
 <1582C6A199AEF329.22639@lists.fd.io>
 <1582C6DF44DED5BC.22639@lists.fd.io>
 <A778FB3954515F498B35C4F5403D4F443FC9F001@shsmsx102.ccr.corp.intel.com>
 <alpine.DEB.2.20.1902140626440.23912@uplift.swm.pp.se>
 <A778FB3954515F498B35C4F5403D4F443FC9F0A8@shsmsx102.ccr.corp.intel.com>
Message-ID: <7BE8787E-1BC7-4BBA-9E0A-2A67ED648691@cisco.com>

Mikael,

We could help to set CI infra.
One point to clarify is who's supposed to host the infra.

One option is LFN but I'm not sure that would be ok as
sysrepo is not an LFN project. FYI, LFN/fd.io is using package cloud.

Other infras are possible but I guess sysrepo maintainers may have a preference.

Also, my intent was to only support Ubuntu 18/16 and CentOS 7.

Thanks
Luca



?On 14/02/2019 06:39, "sweetcomb-dev at lists.fd.io on behalf of Ni, Hongjun" <sweetcomb-dev at lists.fd.io on behalf of hongjun.ni at intel.com> wrote:

    
    Thank you Mikael! 
    
    Sweetcomb community will discuss it in today's weekly meeting.
    Hope we will figure out an applicable way.
    
    Thanks,
    Hongjun
    
    -----Original Message-----
    From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
    Sent: Thursday, February 14, 2019 1:35 PM
    To: Ni, Hongjun <hongjun.ni at intel.com>
    Cc: sysrepo-devel at sysrepo.org
    Subject: Re: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
    
    On Thu, 14 Feb 2019, Ni, Hongjun wrote:
    
    > In order to avoid work duplication, best option, IMO, would be to have 
    > dep/rpm in a repo that belongs to sysrepo maintainers.
    
    This has been on our radar for quite some time and I agree that it would be great to have rpm/deb for all major distributions and versions for all the dependencies needed for Sysrepo. This is not the first time we get this request.
    
    However, all our resources right now is aimed towards development of Sysrepo and and we don't currently have the skill set and man hours to well maintain repos for these.
    
    If there is someone willing to become maintainer for packages, that'd be greatly welcome. This isn't isolated to just packaging, we're an open project and if someone wants to contribute more closely, that's welcome as well. We always need more developers and people who can do integration and packaging/testing.
    
    So if someone can volunteer to do this, we'd gladly designate these as the official sysrepo repo:s for packages.
    
    Thanks for your support.
    
    -- 
    Mikael Abrahamsson    email: swmike at swm.pp.se
    
    -=-=-=-=-=-=-=-=-=-=-=-
    Links: You receive all messages sent to this group.
    
    View/Reply Online (#188): https://lists.fd.io/g/sweetcomb-dev/message/188
    Mute This Topic: https://lists.fd.io/mt/29835719/675095
    Group Owner: sweetcomb-dev+owner at lists.fd.io
    Unsubscribe: https://lists.fd.io/g/sweetcomb-dev/leave/3620860/1123205057/xyzzy  [lumuscar+fdio at cisco.com]
    -=-=-=-=-=-=-=-=-=-=-=-
    
    



From lumuscar+fdio at cisco.com  Thu Feb 14 13:15:23 2019
From: lumuscar+fdio at cisco.com (Luca Muscariello)
Date: Thu, 14 Feb 2019 14:15:23 +0100
Subject: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
In-Reply-To: <15833349D8A1CCC4.15679@lists.fd.io>
References: <963AC32C-B995-4D2E-9905-F0957922E194@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9DC0E@shsmsx102.ccr.corp.intel.com>
 <C7E6BFC6-F9E5-4AA1-BF22-C4351F7FF8DF@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9E290@shsmsx102.ccr.corp.intel.com>
 <075a4b4a88df48beb58c9e1ca568c10a@XCH-RCD-002.cisco.com>
 <1582C6A199AEF329.22639@lists.fd.io>
 <1582C6DF44DED5BC.22639@lists.fd.io>
 <A778FB3954515F498B35C4F5403D4F443FC9F001@shsmsx102.ccr.corp.intel.com>
 <alpine.DEB.2.20.1902140626440.23912@uplift.swm.pp.se>
 <A778FB3954515F498B35C4F5403D4F443FC9F0A8@shsmsx102.ccr.corp.intel.com>
 <15833349D8A1CCC4.15679@lists.fd.io>
Message-ID: <246F28CE-3930-46C6-B7D5-01A140DAE35B@cisco.com>

One additional thing:

sysrepo has three dependencies which are not currently distributed in binaries.
All from the same editor: CESNET.

https://github.com/CESNET/Netopeer2
https://github.com/CESNET/libyang
https://github.com/CESNET/libnetconf2


One option could be to package the three dependencies with sysrepo in the same binary distro
until CESNET decides to have their own repos.

Luca



?On 14/02/2019 11:11, "sweetcomb-dev at lists.fd.io on behalf of Luca Muscariello via Lists.Fd.Io" <sweetcomb-dev at lists.fd.io on behalf of lumuscar+fdio=cisco.com at lists.fd.io> wrote:

    Mikael,
    
    We could help to set CI infra.
    One point to clarify is who's supposed to host the infra.
    
    One option is LFN but I'm not sure that would be ok as
    sysrepo is not an LFN project. FYI, LFN/fd.io is using package cloud.
    
    Other infras are possible but I guess sysrepo maintainers may have a preference.
    
    Also, my intent was to only support Ubuntu 18/16 and CentOS 7.
    
    Thanks
    Luca
    
    
    
    On 14/02/2019 06:39, "sweetcomb-dev at lists.fd.io on behalf of Ni, Hongjun" <sweetcomb-dev at lists.fd.io on behalf of hongjun.ni at intel.com> wrote:
    
    
        Thank you Mikael! 
    
        Sweetcomb community will discuss it in today's weekly meeting.
        Hope we will figure out an applicable way.
    
        Thanks,
        Hongjun
    
        -----Original Message-----
        From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
        Sent: Thursday, February 14, 2019 1:35 PM
        To: Ni, Hongjun <hongjun.ni at intel.com>
        Cc: sysrepo-devel at sysrepo.org
        Subject: Re: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
    
        On Thu, 14 Feb 2019, Ni, Hongjun wrote:
    
        > In order to avoid work duplication, best option, IMO, would be to have 
        > dep/rpm in a repo that belongs to sysrepo maintainers.
    
        This has been on our radar for quite some time and I agree that it would be great to have rpm/deb for all major distributions and versions for all the dependencies needed for Sysrepo. This is not the first time we get this request.
    
        However, all our resources right now is aimed towards development of Sysrepo and and we don't currently have the skill set and man hours to well maintain repos for these.
    
        If there is someone willing to become maintainer for packages, that'd be greatly welcome. This isn't isolated to just packaging, we're an open project and if someone wants to contribute more closely, that's welcome as well. We always need more developers and people who can do integration and packaging/testing.
    
        So if someone can volunteer to do this, we'd gladly designate these as the official sysrepo repo:s for packages.
    
        Thanks for your support.
    
        -- 
        Mikael Abrahamsson    email: swmike at swm.pp.se
    
    
    
    
    
    
    
    -=-=-=-=-=-=-=-=-=-=-=-
    Links: You receive all messages sent to this group.
    
    View/Reply Online (#190): https://lists.fd.io/g/sweetcomb-dev/message/190
    Mute This Topic: https://lists.fd.io/mt/29835719/675095
    Group Owner: sweetcomb-dev+owner at lists.fd.io
    Unsubscribe: https://lists.fd.io/g/sweetcomb-dev/leave/3620860/1123205057/xyzzy  [lumuscar+fdio at cisco.com]
    -=-=-=-=-=-=-=-=-=-=-=-
    
    



From lumuscar at cisco.com  Thu Feb 14 13:15:04 2019
From: lumuscar at cisco.com (Luca Muscariello (lumuscar))
Date: Thu, 14 Feb 2019 13:15:04 +0000
Subject: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
In-Reply-To: <15833349D8A1CCC4.15679@lists.fd.io>
References: <963AC32C-B995-4D2E-9905-F0957922E194@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9DC0E@shsmsx102.ccr.corp.intel.com>
 <C7E6BFC6-F9E5-4AA1-BF22-C4351F7FF8DF@cisco.com>
 <A778FB3954515F498B35C4F5403D4F443FC9E290@shsmsx102.ccr.corp.intel.com>
 <075a4b4a88df48beb58c9e1ca568c10a@XCH-RCD-002.cisco.com>
 <1582C6A199AEF329.22639@lists.fd.io> <1582C6DF44DED5BC.22639@lists.fd.io>
 <A778FB3954515F498B35C4F5403D4F443FC9F001@shsmsx102.ccr.corp.intel.com>
 <alpine.DEB.2.20.1902140626440.23912@uplift.swm.pp.se>
 <A778FB3954515F498B35C4F5403D4F443FC9F0A8@shsmsx102.ccr.corp.intel.com>
 <15833349D8A1CCC4.15679@lists.fd.io>
Message-ID: <76173C10-DEBD-486C-BB3A-D8601CA13DE3@cisco.com>

One additional thing:

sysrepo has three dependencies which are not currently distributed in binaries.
All from the same editor: CESNET.

https://github.com/CESNET/Netopeer2
https://github.com/CESNET/libyang
https://github.com/CESNET/libnetconf2


One option could be to package the three dependencies with sysrepo in the same binary distro
until CESNET decides to have their own repos.

Luca



?On 14/02/2019 11:11, "sweetcomb-dev at lists.fd.io on behalf of Luca Muscariello via Lists.Fd.Io" <sweetcomb-dev at lists.fd.io on behalf of lumuscar+fdio=cisco.com at lists.fd.io> wrote:

    Mikael,
    
    We could help to set CI infra.
    One point to clarify is who's supposed to host the infra.
    
    One option is LFN but I'm not sure that would be ok as
    sysrepo is not an LFN project. FYI, LFN/fd.io is using package cloud.
    
    Other infras are possible but I guess sysrepo maintainers may have a preference.
    
    Also, my intent was to only support Ubuntu 18/16 and CentOS 7.
    
    Thanks
    Luca
    
    
    
    On 14/02/2019 06:39, "sweetcomb-dev at lists.fd.io on behalf of Ni, Hongjun" <sweetcomb-dev at lists.fd.io on behalf of hongjun.ni at intel.com> wrote:
    
    
        Thank you Mikael! 
    
        Sweetcomb community will discuss it in today's weekly meeting.
        Hope we will figure out an applicable way.
    
        Thanks,
        Hongjun
    
        -----Original Message-----
        From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
        Sent: Thursday, February 14, 2019 1:35 PM
        To: Ni, Hongjun <hongjun.ni at intel.com>
        Cc: sysrepo-devel at sysrepo.org
        Subject: Re: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
    
        On Thu, 14 Feb 2019, Ni, Hongjun wrote:
    
        > In order to avoid work duplication, best option, IMO, would be to have 
        > dep/rpm in a repo that belongs to sysrepo maintainers.
    
        This has been on our radar for quite some time and I agree that it would be great to have rpm/deb for all major distributions and versions for all the dependencies needed for Sysrepo. This is not the first time we get this request.
    
        However, all our resources right now is aimed towards development of Sysrepo and and we don't currently have the skill set and man hours to well maintain repos for these.
    
        If there is someone willing to become maintainer for packages, that'd be greatly welcome. This isn't isolated to just packaging, we're an open project and if someone wants to contribute more closely, that's welcome as well. We always need more developers and people who can do integration and packaging/testing.
    
        So if someone can volunteer to do this, we'd gladly designate these as the official sysrepo repo:s for packages.
    
        Thanks for your support.
    
        -- 
        Mikael Abrahamsson    email: swmike at swm.pp.se
    
    
    
    
    
    
    
    -=-=-=-=-=-=-=-=-=-=-=-
    Links: You receive all messages sent to this group.
    
    View/Reply Online (#190): https://lists.fd.io/g/sweetcomb-dev/message/190
    Mute This Topic: https://lists.fd.io/mt/29835719/675095
    Group Owner: sweetcomb-dev+owner at lists.fd.io
    Unsubscribe: https://lists.fd.io/g/sweetcomb-dev/leave/3620860/1123205057/xyzzy  [lumuscar+fdio at cisco.com]
    -=-=-=-=-=-=-=-=-=-=-=-
    
    


From mvasko at cesnet.cz  Thu Feb 14 13:49:53 2019
From: mvasko at cesnet.cz (=?utf-8?q?Michal_Va=C5=A1ko?=)
Date: Thu, 14 Feb 2019 14:49:53 +0100
Subject: [sysrepo-devel] 
 =?utf-8?b?Pz09P3V0Zi04P3E/ICBbc3dlZXRjb21iLWRl?=
 =?utf-8?q?v=5D_sysrepo_binary_distributions?=
In-Reply-To: <246F28CE-3930-46C6-B7D5-01A140DAE35B@cisco.com>
Message-ID: <5331-5c657200-4b-6f907a00@145112604>

Hi,
firstly, reacting to your previous email, what do you mean by "CI infra"? If a generic sysrepo CI infrastructure then we already have that on travis CI [1].

As for your last email, I want to first clarify that libnetconf2 and netopeer2 are *not* sysrepo dependencies. Only libyang is a sysrepo dependency. libnetconf2 depends, again, only on libyang. It is netopeer2 that depends on libyang, libnetconf2, and sysrepo.

Now, the current state of packages is as follows. There is a new Debian libyang package [2] (also with CPP bindings [3]) maintained by a person from FRRouting [4]. Other than that, we have tried maintaining the packages ourselves [5] but we simply do not have enough people to make sure all the builds are continuously successful. At this point we have given up on any further maintenance.

Regards,
Michal

[1] https://travis-ci.org/sysrepo/sysrepo
[2] https://packages.debian.org/unstable/libs/libyang0.16
[3] https://packages.debian.org/unstable/libs/libyang-cpp0.16
[4] https://qa.debian.org/developer.php?email=equinox-debian%40diac24.net
[5] https://build.opensuse.org/project/show/home:liberouter

On Thursday, February 14, 2019 14:15 CET, Luca Muscariello <lumuscar+fdio at cisco.com> wrote: 
 
> One additional thing:
> 
> sysrepo has three dependencies which are not currently distributed in binaries.
> All from the same editor: CESNET.
> 
> https://github.com/CESNET/Netopeer2
> https://github.com/CESNET/libyang
> https://github.com/CESNET/libnetconf2
> 
> 
> One option could be to package the three dependencies with sysrepo in the same binary distro
> until CESNET decides to have their own repos.
> 
> Luca
> 
> 
> 
> ?On 14/02/2019 11:11, "sweetcomb-dev at lists.fd.io on behalf of Luca Muscariello via Lists.Fd.Io" <sweetcomb-dev at lists.fd.io on behalf of lumuscar+fdio=cisco.com at lists.fd.io> wrote:
> 
>     Mikael,
>     
>     We could help to set CI infra.
>     One point to clarify is who's supposed to host the infra.
>     
>     One option is LFN but I'm not sure that would be ok as
>     sysrepo is not an LFN project. FYI, LFN/fd.io is using package cloud.
>     
>     Other infras are possible but I guess sysrepo maintainers may have a preference.
>     
>     Also, my intent was to only support Ubuntu 18/16 and CentOS 7.
>     
>     Thanks
>     Luca
>     
>     
>     
>     On 14/02/2019 06:39, "sweetcomb-dev at lists.fd.io on behalf of Ni, Hongjun" <sweetcomb-dev at lists.fd.io on behalf of hongjun.ni at intel.com> wrote:
>     
>     
>         Thank you Mikael! 
>     
>         Sweetcomb community will discuss it in today's weekly meeting.
>         Hope we will figure out an applicable way.
>     
>         Thanks,
>         Hongjun
>     
>         -----Original Message-----
>         From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
>         Sent: Thursday, February 14, 2019 1:35 PM
>         To: Ni, Hongjun <hongjun.ni at intel.com>
>         Cc: sysrepo-devel at sysrepo.org
>         Subject: Re: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
>     
>         On Thu, 14 Feb 2019, Ni, Hongjun wrote:
>     
>         > In order to avoid work duplication, best option, IMO, would be to have 
>         > dep/rpm in a repo that belongs to sysrepo maintainers.
>     
>         This has been on our radar for quite some time and I agree that it would be great to have rpm/deb for all major distributions and versions for all the dependencies needed for Sysrepo. This is not the first time we get this request.
>     
>         However, all our resources right now is aimed towards development of Sysrepo and and we don't currently have the skill set and man hours to well maintain repos for these.
>     
>         If there is someone willing to become maintainer for packages, that'd be greatly welcome. This isn't isolated to just packaging, we're an open project and if someone wants to contribute more closely, that's welcome as well. We always need more developers and people who can do integration and packaging/testing.
>     
>         So if someone can volunteer to do this, we'd gladly designate these as the official sysrepo repo:s for packages.
>     
>         Thanks for your support.
>     
>         -- 
>         Mikael Abrahamsson    email: swmike at swm.pp.se
>     
>     
>     
>     
>     
>     
>     
>     -=-=-=-=-=-=-=-=-=-=-=-
>     Links: You receive all messages sent to this group.
>     
>     View/Reply Online (#190): https://lists.fd.io/g/sweetcomb-dev/message/190
>     Mute This Topic: https://lists.fd.io/mt/29835719/675095
>     Group Owner: sweetcomb-dev+owner at lists.fd.io
>     Unsubscribe: https://lists.fd.io/g/sweetcomb-dev/leave/3620860/1123205057/xyzzy  [lumuscar+fdio at cisco.com]
>     -=-=-=-=-=-=-=-=-=-=-=-
>     
>     
> 
> 
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org
> http://lists.sysrepo.org/listinfo/sysrepo-devel
 
 


From lumuscar+fdio at cisco.com  Thu Feb 14 17:22:23 2019
From: lumuscar+fdio at cisco.com (Luca Muscariello)
Date: Thu, 14 Feb 2019 18:22:23 +0100
Subject: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
In-Reply-To: <5331-5c657200-4b-6f907a00@145112604>
References: <246F28CE-3930-46C6-B7D5-01A140DAE35B@cisco.com>
 <5331-5c657200-4b-6f907a00@145112604>
Message-ID: <6C67CFD9-24C9-42C8-BB68-0CA608FF7B1C@cisco.com>

Hi Michal,

[1] would be enough indeed. Artifacts could be stored in a deb/rpm repo.
Ubuntu 18/16 and CentOS 7 is what VPP is supporting right now.

Right, only missing dependency is libyang. This would be enough to run sweetcomb verify jobs.

Still, I think that having netopeer2 for the same OSes supported by VPP
seems very useful to pile up VPP, sweetcomb, sysrepo, netopeer2, ODL.
Useful for people running tests in the sweetcomb project in the first place.

There is still the option to use the sweetcomb project account to deploy jobs in Jenkins 
and deploy artifacts in package cloud for Ubuntu 18/16 and CentOS 7.
On problem is to check that all components' versions are the right ones and that
everyone is happy with this solution.


Luca

?On 14/02/2019 14:50, "Michal Va?ko" <mvasko at cesnet.cz> wrote:

    Hi,
    firstly, reacting to your previous email, what do you mean by "CI infra"? If a generic sysrepo CI infrastructure then we already have that on travis CI [1].
    
    As for your last email, I want to first clarify that libnetconf2 and netopeer2 are *not* sysrepo dependencies. Only libyang is a sysrepo dependency. libnetconf2 depends, again, only on libyang. It is netopeer2 that depends on libyang, libnetconf2, and sysrepo.
    
    Now, the current state of packages is as follows. There is a new Debian libyang package [2] (also with CPP bindings [3]) maintained by a person from FRRouting [4]. Other than that, we have tried maintaining the packages ourselves [5] but we simply do not have enough people to make sure all the builds are continuously successful. At this point we have given up on any further maintenance.
    
    Regards,
    Michal
    
    [1] https://travis-ci.org/sysrepo/sysrepo
    [2] https://packages.debian.org/unstable/libs/libyang0.16
    [3] https://packages.debian.org/unstable/libs/libyang-cpp0.16
    [4] https://qa.debian.org/developer.php?email=equinox-debian%40diac24.net
    [5] https://build.opensuse.org/project/show/home:liberouter
    
    On Thursday, February 14, 2019 14:15 CET, Luca Muscariello <lumuscar+fdio at cisco.com> wrote: 
     
    > One additional thing:
    > 
    > sysrepo has three dependencies which are not currently distributed in binaries.
    > All from the same editor: CESNET.
    > 
    > https://github.com/CESNET/Netopeer2
    > https://github.com/CESNET/libyang
    > https://github.com/CESNET/libnetconf2
    > 
    > 
    > One option could be to package the three dependencies with sysrepo in the same binary distro
    > until CESNET decides to have their own repos.
    > 
    > Luca
    > 
    > 
    > 
    > On 14/02/2019 11:11, "sweetcomb-dev at lists.fd.io on behalf of Luca Muscariello via Lists.Fd.Io" <sweetcomb-dev at lists.fd.io on behalf of lumuscar+fdio=cisco.com at lists.fd.io> wrote:
    > 
    >     Mikael,
    >     
    >     We could help to set CI infra.
    >     One point to clarify is who's supposed to host the infra.
    >     
    >     One option is LFN but I'm not sure that would be ok as
    >     sysrepo is not an LFN project. FYI, LFN/fd.io is using package cloud.
    >     
    >     Other infras are possible but I guess sysrepo maintainers may have a preference.
    >     
    >     Also, my intent was to only support Ubuntu 18/16 and CentOS 7.
    >     
    >     Thanks
    >     Luca
    >     
    >     
    >     
    >     On 14/02/2019 06:39, "sweetcomb-dev at lists.fd.io on behalf of Ni, Hongjun" <sweetcomb-dev at lists.fd.io on behalf of hongjun.ni at intel.com> wrote:
    >     
    >     
    >         Thank you Mikael! 
    >     
    >         Sweetcomb community will discuss it in today's weekly meeting.
    >         Hope we will figure out an applicable way.
    >     
    >         Thanks,
    >         Hongjun
    >     
    >         -----Original Message-----
    >         From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
    >         Sent: Thursday, February 14, 2019 1:35 PM
    >         To: Ni, Hongjun <hongjun.ni at intel.com>
    >         Cc: sysrepo-devel at sysrepo.org
    >         Subject: Re: [sysrepo-devel] [sweetcomb-dev] sysrepo binary distributions
    >     
    >         On Thu, 14 Feb 2019, Ni, Hongjun wrote:
    >     
    >         > In order to avoid work duplication, best option, IMO, would be to have 
    >         > dep/rpm in a repo that belongs to sysrepo maintainers.
    >     
    >         This has been on our radar for quite some time and I agree that it would be great to have rpm/deb for all major distributions and versions for all the dependencies needed for Sysrepo. This is not the first time we get this request.
    >     
    >         However, all our resources right now is aimed towards development of Sysrepo and and we don't currently have the skill set and man hours to well maintain repos for these.
    >     
    >         If there is someone willing to become maintainer for packages, that'd be greatly welcome. This isn't isolated to just packaging, we're an open project and if someone wants to contribute more closely, that's welcome as well. We always need more developers and people who can do integration and packaging/testing.
    >     
    >         So if someone can volunteer to do this, we'd gladly designate these as the official sysrepo repo:s for packages.
    >     
    >         Thanks for your support.
    >     
    >         -- 
    >         Mikael Abrahamsson    email: swmike at swm.pp.se
    >     
    >     
    >     
    >     
    >     
    >     
    >     
    >     -=-=-=-=-=-=-=-=-=-=-=-
    >     Links: You receive all messages sent to this group.
    >     
    >     View/Reply Online (#190): https://lists.fd.io/g/sweetcomb-dev/message/190
    >     Mute This Topic: https://lists.fd.io/mt/29835719/675095
    >     Group Owner: sweetcomb-dev+owner at lists.fd.io
    >     Unsubscribe: https://lists.fd.io/g/sweetcomb-dev/leave/3620860/1123205057/xyzzy  [lumuscar+fdio at cisco.com]
    >     -=-=-=-=-=-=-=-=-=-=-=-
    >     
    >     
    > 
    > 
    > _______________________________________________
    > sysrepo-devel mailing list
    > sysrepo-devel at sysrepo.org
    > http://lists.sysrepo.org/listinfo/sysrepo-devel
     
     
    
    



From mhemmatp at cisco.com  Tue Feb 19 17:07:09 2019
From: mhemmatp at cisco.com (Masoud Hemmatpour (mhemmatp))
Date: Tue, 19 Feb 2019 17:07:09 +0000
Subject: [sysrepo-devel] Provide data to netconf client from sysrepo
Message-ID: <1E067ECE-8F46-49A0-9439-AE88AFBCF777@cisco.com>


 Hello all,

 I prepared a yang model consisting a container and some RPCs. Then, I prepared a plugin corresponding to the yang model. Next, I am going to connect netopeer2-cli to the netopeer2-server which is connected to the sysrepo and read/write the value of my leaf in my container.

Actually, I am not sure about the approach. Should I  call an RPC then through the sr_set_item manually modify the value of my leaf. If this is the right approach how can I provide my new values to the netopeer2-cli.

I am not sure how can I provide data to the remote side.

Kind Regards,
Thanks,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sysrepo.org/archives/sysrepo-devel/attachments/20190219/6acfbf58/attachment.html>

From jan.kundrat at cesnet.cz  Tue Feb 19 18:55:10 2019
From: jan.kundrat at cesnet.cz (=?iso-8859-1?Q?Jan_Kundr=E1t?=)
Date: Tue, 19 Feb 2019 19:55:10 +0100
Subject: [sysrepo-devel] Provide data to netconf client from sysrepo
In-Reply-To: <1E067ECE-8F46-49A0-9439-AE88AFBCF777@cisco.com>
References: <1E067ECE-8F46-49A0-9439-AE88AFBCF777@cisco.com>
Message-ID: <f2d4f065-d8d6-441e-878b-35136c264f20@cesnet.cz>

>  I prepared a yang model consisting a container and some RPCs. 
> Then, I prepared a plugin corresponding to the yang model. Next, 
> I am going to connect netopeer2-cli to the netopeer2-server 
> which is connected to the sysrepo and read/write the value of my 
> leaf in my container.
>
> Actually, I am not sure about the approach. Should I  call an 
> RPC then through the sr_set_item manually modify the value of my 
> leaf. If this is the right approach how can I provide my new 
> values to the netopeer2-cli.

It depends on how the YANG model looks like. All items that are `config: 
true` are returned by sysrepo itself; these are considered, well, 
configuration, and configuration is stored in a sysrepo datastore. All 
items that are `config: false` are considered operation data, and your 
application and/or plugin should register a dp_get_items callback. That 
callback will be invoked when a standard NETCONF <get> RPC arrives.

If you want to provide data from a user-defined RPC, then register a 
callback to be invoked when a remote user requests this RPC. This is all 
covered in the docs.

With kind regards,
Jan

From mhemmatp at cisco.com  Wed Feb 20 14:50:52 2019
From: mhemmatp at cisco.com (Masoud Hemmatpour (mhemmatp))
Date: Wed, 20 Feb 2019 14:50:52 +0000
Subject: [sysrepo-devel] Provide data to netconf client from sysrepo
In-Reply-To: <f2d4f065-d8d6-441e-878b-35136c264f20@cesnet.cz>
References: <1E067ECE-8F46-49A0-9439-AE88AFBCF777@cisco.com>
 <f2d4f065-d8d6-441e-878b-35136c264f20@cesnet.cz>
Message-ID: <F66BD3D6-125C-410D-80BC-0AD30133E883@cisco.com>


Thanks Jan for your reply. Actually,  my question is that how to combine the operational data (read only),  configuration data (readable and writeable) and RPCs in yang model. I am going to connect these three elements. I mean I need to call an RPC to perform some operations then modify some leaves regarding to the results. I tried to call an RPC then modify configuration data but when I read the config through get-config it returns the last data I modified through edit-config. What is the approach to bind some operations when an element in configuration is modified?


Kind Regards,
Thanks,



> On 19 Feb 2019, at 19:55, Jan Kundr?t <jan.kundrat at cesnet.cz> wrote:
> 
>> I prepared a yang model consisting a container and some RPCs. Then, I prepared a plugin corresponding to the yang model. Next, I am going to connect netopeer2-cli to the netopeer2-server which is connected to the sysrepo and read/write the value of my leaf in my container.
>> 
>> Actually, I am not sure about the approach. Should I  call an RPC then through the sr_set_item manually modify the value of my leaf. If this is the right approach how can I provide my new values to the netopeer2-cli.
> 
> It depends on how the YANG model looks like. All items that are `config: true` are returned by sysrepo itself; these are considered, well, configuration, and configuration is stored in a sysrepo datastore. All items that are `config: false` are considered operation data, and your application and/or plugin should register a dp_get_items callback. That callback will be invoked when a standard NETCONF <get> RPC arrives.
> 
> If you want to provide data from a user-defined RPC, then register a callback to be invoked when a remote user requests this RPC. This is all covered in the docs.
> 
> With kind regards,
> Jan
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org
> http://lists.sysrepo.org/listinfo/sysrepo-devel


From mvasko at cesnet.cz  Thu Feb 21 08:07:20 2019
From: mvasko at cesnet.cz (=?utf-8?q?Michal_Va=C5=A1ko?=)
Date: Thu, 21 Feb 2019 09:07:20 +0100
Subject: [sysrepo-devel] 
 =?utf-8?b?Pz09P3V0Zi04P3E/ICBQcm92aWRlIGRhdGEg?=
 =?utf-8?q?to_netconf_client_from_sysrepo?=
In-Reply-To: <F66BD3D6-125C-410D-80BC-0AD30133E883@cisco.com>
Message-ID: <6d2c-5c6e5c00-9f-67a7d580@39948982>

Hi,

On Wednesday, February 20, 2019 15:50 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com> wrote: 
 
> 
> Thanks Jan for your reply. Actually,  my question is that how to combine the operational data (read only),  configuration data (readable and writeable) and RPCs in yang model. I am going to connect these three elements.

Whatever YANG elements you want to combine in one model (operational, configuration data, RPCs, ...) you can.

> I mean I need to call an RPC to perform some operations then modify some leaves regarding to the results. I tried to call an RPC then modify configuration data but when I read the config through get-config it returns the last data I modified through edit-config. 

RPCs are generally not meant to modify configuration, they should, generally, execute some remote operation (Remote Procedure Call). Some examples from ietf-system model are <set-current-datetime> or <system-restart>. If you want to change configuration, do so using a standard RPC <edit-config> that is meant for changing configuration (as NETCONF uses only RPCs for synchronous communication, everything must be performed with one).

> What is the approach to bind some operations when an element in configuration is modified?

I assume you are asking how to perform some operations on the actual system when some configuration elements are modified. This is the primary sysrepo use-case, you can do this by registering callbacks on the whole modules [1] or specific configuration nodes [2].

Regards,
Michal

[1] http://www.sysrepo.org/static/doc/html/group__cl.html#ga35341cf4bf9584127f7c5a79405a878f
[2] http://www.sysrepo.org/static/doc/html/group__cl.html#gad2af4031c4bc5e8a4f01437116f80167

> 
> 
> Kind Regards,
> Thanks,
> 
> 
> 
> > On 19 Feb 2019, at 19:55, Jan Kundr?t <jan.kundrat at cesnet.cz> wrote:
> > 
> >> I prepared a yang model consisting a container and some RPCs. Then, I prepared a plugin corresponding to the yang model. Next, I am going to connect netopeer2-cli to the netopeer2-server which is connected to the sysrepo and read/write the value of my leaf in my container.
> >> 
> >> Actually, I am not sure about the approach. Should I  call an RPC then through the sr_set_item manually modify the value of my leaf. If this is the right approach how can I provide my new values to the netopeer2-cli.
> > 
> > It depends on how the YANG model looks like. All items that are `config: true` are returned by sysrepo itself; these are considered, well, configuration, and configuration is stored in a sysrepo datastore. All items that are `config: false` are considered operation data, and your application and/or plugin should register a dp_get_items callback. That callback will be invoked when a standard NETCONF <get> RPC arrives.
> > 
> > If you want to provide data from a user-defined RPC, then register a callback to be invoked when a remote user requests this RPC. This is all covered in the docs.
> > 
> > With kind regards,
> > Jan
> > _______________________________________________
> > sysrepo-devel mailing list
> > sysrepo-devel at sysrepo.org
> > http://lists.sysrepo.org/listinfo/sysrepo-devel
> 
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org
> http://lists.sysrepo.org/listinfo/sysrepo-devel
 
 


From mhemmatp at cisco.com  Fri Feb 22 17:18:46 2019
From: mhemmatp at cisco.com (Masoud Hemmatpour (mhemmatp))
Date: Fri, 22 Feb 2019 17:18:46 +0000
Subject: [sysrepo-devel] Provide data to netconf  client from sysrepo
In-Reply-To: <6d2c-5c6e5c00-9f-67a7d580@39948982>
References: <6d2c-5c6e5c00-9f-67a7d580@39948982>
Message-ID: <01894432-C94C-4C97-AD04-3D21A63B39D1@cisco.com>

Thank you Michal for your reply. Problem solved. But the only issue is that when I try to get state data (operational data) I face segmentation fault. I tried to debug but it seems my callback is OK. Here it is my configuration:

Yang module :
   grouping states {
    leaf a{
                type uint64;
            }
    leaf b{
                type uint64;
            }
}
    container  operational-data {
        config false;
        container states{
            uses states;
        }
    }

In my plugin:
sr_dp_get_items_subscribe(session, "/mymodel:operational-data ", state_cb, NULL, SR_SUBSCR_CTX_REUSE, subscription);

here it is the callback :

state_cb((const char *xpath, sr_val_t **values, size_t *values_cnt,
uint64_t request_id, const char *original_xpath, void *private_ctx){
    sr_val_t *vals;
    rc = sr_new_values(1, &vals);
    if (SR_ERR_OK != rc) {
        return rc;
    }
    Approach 1 :
    sr_val_build_xpath(&vals[0], "/hicn:hicn-state/states/a ");
    sr_val_set_str_data(&vals[0], SR_UINT64_T, "10");
    Approach 2 :
    sr_val_set_xpath(&vals[0], "/hicn:hicn-state/states/a");
    vals[0].type = SR_UINT64_T;
    vals[0].data.uint64_val = 10;

    *values = vals;
    *values_cnt = 1;
     sr_free_val(vals);
}
I tried both approaches. Is there something wrong in my code?


Kind Regards,
Masoud,


On 21 Feb 2019, at 09:07, Michal Va?ko <mvasko at cesnet.cz<mailto:mvasko at cesnet.cz>> wrote:

Hi,

On Wednesday, February 20, 2019 15:50 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com<mailto:mhemmatp at cisco.com>> wrote:


Thanks Jan for your reply. Actually,  my question is that how to combine the operational data (read only),  configuration data (readable and writeable) and RPCs in yang model. I am going to connect these three elements.

Whatever YANG elements you want to combine in one model (operational, configuration data, RPCs, ...) you can.

I mean I need to call an RPC to perform some operations then modify some leaves regarding to the results. I tried to call an RPC then modify configuration data but when I read the config through get-config it returns the last data I modified through edit-config.

RPCs are generally not meant to modify configuration, they should, generally, execute some remote operation (Remote Procedure Call). Some examples from ietf-system model are <set-current-datetime> or <system-restart>. If you want to change configuration, do so using a standard RPC <edit-config> that is meant for changing configuration (as NETCONF uses only RPCs for synchronous communication, everything must be performed with one).

What is the approach to bind some operations when an element in configuration is modified?

I assume you are asking how to perform some operations on the actual system when some configuration elements are modified. This is the primary sysrepo use-case, you can do this by registering callbacks on the whole modules [1] or specific configuration nodes [2].

Regards,
Michal

[1] http://www.sysrepo.org/static/doc/html/group__cl.html#ga35341cf4bf9584127f7c5a79405a878f
[2] http://www.sysrepo.org/static/doc/html/group__cl.html#gad2af4031c4bc5e8a4f01437116f80167



Kind Regards,
Thanks,



On 19 Feb 2019, at 19:55, Jan Kundr?t <jan.kundrat at cesnet.cz<mailto:jan.kundrat at cesnet.cz>> wrote:

I prepared a yang model consisting a container and some RPCs. Then, I prepared a plugin corresponding to the yang model. Next, I am going to connect netopeer2-cli to the netopeer2-server which is connected to the sysrepo and read/write the value of my leaf in my container.

Actually, I am not sure about the approach. Should I  call an RPC then through the sr_set_item manually modify the value of my leaf. If this is the right approach how can I provide my new values to the netopeer2-cli.

It depends on how the YANG model looks like. All items that are `config: true` are returned by sysrepo itself; these are considered, well, configuration, and configuration is stored in a sysrepo datastore. All items that are `config: false` are considered operation data, and your application and/or plugin should register a dp_get_items callback. That callback will be invoked when a standard NETCONF <get> RPC arrives.

If you want to provide data from a user-defined RPC, then register a callback to be invoked when a remote user requests this RPC. This is all covered in the docs.

With kind regards,
Jan
_______________________________________________
sysrepo-devel mailing list
sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org>
http://lists.sysrepo.org/listinfo/sysrepo-devel

_______________________________________________
sysrepo-devel mailing list
sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org>
http://lists.sysrepo.org/listinfo/sysrepo-devel




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sysrepo.org/archives/sysrepo-devel/attachments/20190222/02149541/attachment.html>

From mvasko at cesnet.cz  Mon Feb 25 07:26:56 2019
From: mvasko at cesnet.cz (=?utf-8?q?Michal_Va=C5=A1ko?=)
Date: Mon, 25 Feb 2019 08:26:56 +0100
Subject: [sysrepo-devel] 
 =?utf-8?b?Pz09P3V0Zi04P3E/ICBQcm92aWRlIGRhdGEg?=
 =?utf-8?q?to_netconf_client_from_sysrepo?=
In-Reply-To: <01894432-C94C-4C97-AD04-3D21A63B39D1@cisco.com>
Message-ID: <68f6-5c739900-99-38d77080@157597210>

Hi Masoud,
firstly, at this point you should have probably created an issue, the code can be formatted there if nothing else. So, if you have another problem, please do.

Regarding this one, I believe the problem is the last line of your callback "sr_free_val(vals);". Sysrepo then reads freed data.

Regards,
Michal

On Friday, February 22, 2019 18:18 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com> wrote: 
 
> Thank you Michal for your reply. Problem solved. But the only issue is that when I try to get state data (operational data) I face segmentation fault. I tried to debug but it seems my callback is OK. Here it is my configuration:
> 
> Yang module :
>    grouping states {
>     leaf a{
>                 type uint64;
>             }
>     leaf b{
>                 type uint64;
>             }
> }
>     container  operational-data {
>         config false;
>         container states{
>             uses states;
>         }
>     }
> 
> In my plugin:
> sr_dp_get_items_subscribe(session, "/mymodel:operational-data ", state_cb, NULL, SR_SUBSCR_CTX_REUSE, subscription);
> 
> here it is the callback :
> 
> state_cb((const char *xpath, sr_val_t **values, size_t *values_cnt,
> uint64_t request_id, const char *original_xpath, void *private_ctx){
>     sr_val_t *vals;
>     rc = sr_new_values(1, &vals);
>     if (SR_ERR_OK != rc) {
>         return rc;
>     }
>     Approach 1 :
>     sr_val_build_xpath(&vals[0], "/hicn:hicn-state/states/a ");
>     sr_val_set_str_data(&vals[0], SR_UINT64_T, "10");
>     Approach 2 :
>     sr_val_set_xpath(&vals[0], "/hicn:hicn-state/states/a");
>     vals[0].type = SR_UINT64_T;
>     vals[0].data.uint64_val = 10;
> 
>     *values = vals;
>     *values_cnt = 1;
>      sr_free_val(vals);
> }
> I tried both approaches. Is there something wrong in my code?
> 
> 
> Kind Regards,
> Masoud,
> 
> 
> On 21 Feb 2019, at 09:07, Michal Va?ko <mvasko at cesnet.cz<mailto:mvasko at cesnet.cz>> wrote:
> 
> Hi,
> 
> On Wednesday, February 20, 2019 15:50 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com<mailto:mhemmatp at cisco.com>> wrote:
> 
> 
> Thanks Jan for your reply. Actually,  my question is that how to combine the operational data (read only),  configuration data (readable and writeable) and RPCs in yang model. I am going to connect these three elements.
> 
> Whatever YANG elements you want to combine in one model (operational, configuration data, RPCs, ...) you can.
> 
> I mean I need to call an RPC to perform some operations then modify some leaves regarding to the results. I tried to call an RPC then modify configuration data but when I read the config through get-config it returns the last data I modified through edit-config.
> 
> RPCs are generally not meant to modify configuration, they should, generally, execute some remote operation (Remote Procedure Call). Some examples from ietf-system model are <set-current-datetime> or <system-restart>. If you want to change configuration, do so using a standard RPC <edit-config> that is meant for changing configuration (as NETCONF uses only RPCs for synchronous communication, everything must be performed with one).
> 
> What is the approach to bind some operations when an element in configuration is modified?
> 
> I assume you are asking how to perform some operations on the actual system when some configuration elements are modified. This is the primary sysrepo use-case, you can do this by registering callbacks on the whole modules [1] or specific configuration nodes [2].
> 
> Regards,
> Michal
> 
> [1] http://www.sysrepo.org/static/doc/html/group__cl.html#ga35341cf4bf9584127f7c5a79405a878f
> [2] http://www.sysrepo.org/static/doc/html/group__cl.html#gad2af4031c4bc5e8a4f01437116f80167
> 
> 
> 
> Kind Regards,
> Thanks,
> 
> 
> 
> On 19 Feb 2019, at 19:55, Jan Kundr?t <jan.kundrat at cesnet.cz<mailto:jan.kundrat at cesnet.cz>> wrote:
> 
> I prepared a yang model consisting a container and some RPCs. Then, I prepared a plugin corresponding to the yang model. Next, I am going to connect netopeer2-cli to the netopeer2-server which is connected to the sysrepo and read/write the value of my leaf in my container.
> 
> Actually, I am not sure about the approach. Should I  call an RPC then through the sr_set_item manually modify the value of my leaf. If this is the right approach how can I provide my new values to the netopeer2-cli.
> 
> It depends on how the YANG model looks like. All items that are `config: true` are returned by sysrepo itself; these are considered, well, configuration, and configuration is stored in a sysrepo datastore. All items that are `config: false` are considered operation data, and your application and/or plugin should register a dp_get_items callback. That callback will be invoked when a standard NETCONF <get> RPC arrives.
> 
> If you want to provide data from a user-defined RPC, then register a callback to be invoked when a remote user requests this RPC. This is all covered in the docs.
> 
> With kind regards,
> Jan
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org>
> http://lists.sysrepo.org/listinfo/sysrepo-devel
> 
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org>
> http://lists.sysrepo.org/listinfo/sysrepo-devel
> 
> 
> 
> 
 
 


From mhemmatp at cisco.com  Mon Feb 25 08:59:36 2019
From: mhemmatp at cisco.com (Masoud Hemmatpour (mhemmatp))
Date: Mon, 25 Feb 2019 08:59:36 +0000
Subject: [sysrepo-devel] Provide data to netconf  client from sysrepo
In-Reply-To: <68f6-5c739900-99-38d77080@157597210>
References: <68f6-5c739900-99-38d77080@157597210>
Message-ID: <08A36853-2E5A-42F2-8C0C-0C1E348C61E7@cisco.com>

Thanks Michal.  For the next issues sure. When I remove the "sr_free_val(vals);? here it is the output of debug mode in sysrepo-plugind:

[ERR] (sr_set_val_t_type_in_gpb:1250) Type can not be mapped to gpb type '/mymodel:operational-data' type 0
[ERR] (sr_dup_val_t_to_gpb:1410) Setting type in gpb failed for xpath '/mymodel:operational-data/a'
[ERR] (sr_values_sr_to_gpb:1704) Unable to duplicate sr_val_t to GPB.
[ERR] (cl_sm_dp_request_process:843) Error by copying output values to GPB.

I am sure about the data types are Ok. Is the problem for uint64?

Thanks,

On 25 Feb 2019, at 08:26, Michal Va?ko <mvasko at cesnet.cz<mailto:mvasko at cesnet.cz>> wrote:

Hi Masoud,
firstly, at this point you should have probably created an issue, the code can be formatted there if nothing else. So, if you have another problem, please do.

Regarding this one, I believe the problem is the last line of your callback "sr_free_val(vals);". Sysrepo then reads freed data.

Regards,
Michal

On Friday, February 22, 2019 18:18 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com<mailto:mhemmatp at cisco.com>> wrote:

Thank you Michal for your reply. Problem solved. But the only issue is that when I try to get state data (operational data) I face segmentation fault. I tried to debug but it seems my callback is OK. Here it is my configuration:

Yang module :
  grouping states {
   leaf a{
               type uint64;
           }
   leaf b{
               type uint64;
           }
}
   container  operational-data {
       config false;
       container states{
           uses states;
       }
   }

In my plugin:
sr_dp_get_items_subscribe(session, "/mymodel:operational-data ", state_cb, NULL, SR_SUBSCR_CTX_REUSE, subscription);

here it is the callback :

state_cb((const char *xpath, sr_val_t **values, size_t *values_cnt,
uint64_t request_id, const char *original_xpath, void *private_ctx){
   sr_val_t *vals;
   rc = sr_new_values(1, &vals);
   if (SR_ERR_OK != rc) {
       return rc;
   }
   Approach 1 :
   sr_val_build_xpath(&vals[0], "/hicn:hicn-state/states/a ");
   sr_val_set_str_data(&vals[0], SR_UINT64_T, "10");
   Approach 2 :
   sr_val_set_xpath(&vals[0], "/hicn:hicn-state/states/a");
   vals[0].type = SR_UINT64_T;
   vals[0].data.uint64_val = 10;

   *values = vals;
   *values_cnt = 1;
    sr_free_val(vals);
}
I tried both approaches. Is there something wrong in my code?


Kind Regards,
Masoud,


On 21 Feb 2019, at 09:07, Michal Va?ko <mvasko at cesnet.cz<mailto:mvasko at cesnet.cz><mailto:mvasko at cesnet.cz>> wrote:

Hi,

On Wednesday, February 20, 2019 15:50 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com<mailto:mhemmatp at cisco.com><mailto:mhemmatp at cisco.com>> wrote:


Thanks Jan for your reply. Actually,  my question is that how to combine the operational data (read only),  configuration data (readable and writeable) and RPCs in yang model. I am going to connect these three elements.

Whatever YANG elements you want to combine in one model (operational, configuration data, RPCs, ...) you can.

I mean I need to call an RPC to perform some operations then modify some leaves regarding to the results. I tried to call an RPC then modify configuration data but when I read the config through get-config it returns the last data I modified through edit-config.

RPCs are generally not meant to modify configuration, they should, generally, execute some remote operation (Remote Procedure Call). Some examples from ietf-system model are <set-current-datetime> or <system-restart>. If you want to change configuration, do so using a standard RPC <edit-config> that is meant for changing configuration (as NETCONF uses only RPCs for synchronous communication, everything must be performed with one).

What is the approach to bind some operations when an element in configuration is modified?

I assume you are asking how to perform some operations on the actual system when some configuration elements are modified. This is the primary sysrepo use-case, you can do this by registering callbacks on the whole modules [1] or specific configuration nodes [2].

Regards,
Michal

[1] http://www.sysrepo.org/static/doc/html/group__cl.html#ga35341cf4bf9584127f7c5a79405a878f
[2] http://www.sysrepo.org/static/doc/html/group__cl.html#gad2af4031c4bc5e8a4f01437116f80167



Kind Regards,
Thanks,



On 19 Feb 2019, at 19:55, Jan Kundr?t <jan.kundrat at cesnet.cz<mailto:jan.kundrat at cesnet.cz><mailto:jan.kundrat at cesnet.cz>> wrote:

I prepared a yang model consisting a container and some RPCs. Then, I prepared a plugin corresponding to the yang model. Next, I am going to connect netopeer2-cli to the netopeer2-server which is connected to the sysrepo and read/write the value of my leaf in my container.

Actually, I am not sure about the approach. Should I  call an RPC then through the sr_set_item manually modify the value of my leaf. If this is the right approach how can I provide my new values to the netopeer2-cli.

It depends on how the YANG model looks like. All items that are `config: true` are returned by sysrepo itself; these are considered, well, configuration, and configuration is stored in a sysrepo datastore. All items that are `config: false` are considered operation data, and your application and/or plugin should register a dp_get_items callback. That callback will be invoked when a standard NETCONF <get> RPC arrives.

If you want to provide data from a user-defined RPC, then register a callback to be invoked when a remote user requests this RPC. This is all covered in the docs.

With kind regards,
Jan
_______________________________________________
sysrepo-devel mailing list
sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org><mailto:sysrepo-devel at sysrepo.org>
http://lists.sysrepo.org/listinfo/sysrepo-devel

_______________________________________________
sysrepo-devel mailing list
sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org><mailto:sysrepo-devel at sysrepo.org>
http://lists.sysrepo.org/listinfo/sysrepo-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sysrepo.org/archives/sysrepo-devel/attachments/20190225/930a881d/attachment.html>

From mvasko at cesnet.cz  Mon Feb 25 09:35:41 2019
From: mvasko at cesnet.cz (=?utf-8?q?Michal_Va=C5=A1ko?=)
Date: Mon, 25 Feb 2019 10:35:41 +0100
Subject: [sysrepo-devel] 
 =?utf-8?b?Pz09P3V0Zi04P3E/ICBQcm92aWRlIGRhdGEg?=
 =?utf-8?q?to_netconf_client_from_sysrepo?=
In-Reply-To: <08A36853-2E5A-42F2-8C0C-0C1E348C61E7@cisco.com>
Message-ID: <5637-5c73b700-9-5737ed80@162133157>

Hi Masoud,
I suppose you are using Approach 1:

sr_val_build_xpath(&vals[0], "/hicn:hicn-state/states/a ");
sr_val_set_str_data(&vals[0], SR_UINT64_T, "10");

which is wrong, sr_val_set_str_data() is meant only for string types. If you were checking return values you would know. You should be fine if you used Approach 2.

Also, your issues are quite basic and could have been solved on your own with a little more effort. We are happy to provide support but at the same time will not waste time on problems that can be solved by reading the documentation or having basic C knowledge.

Regards,
Michal

On Monday, February 25, 2019 09:59 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com> wrote: 
 
> Thanks Michal.  For the next issues sure. When I remove the "sr_free_val(vals);? here it is the output of debug mode in sysrepo-plugind:
> 
> [ERR] (sr_set_val_t_type_in_gpb:1250) Type can not be mapped to gpb type '/mymodel:operational-data' type 0
> [ERR] (sr_dup_val_t_to_gpb:1410) Setting type in gpb failed for xpath '/mymodel:operational-data/a'
> [ERR] (sr_values_sr_to_gpb:1704) Unable to duplicate sr_val_t to GPB.
> [ERR] (cl_sm_dp_request_process:843) Error by copying output values to GPB.
> 
> I am sure about the data types are Ok. Is the problem for uint64?
> 
> Thanks,
> 
> On 25 Feb 2019, at 08:26, Michal Va?ko <mvasko at cesnet.cz<mailto:mvasko at cesnet.cz>> wrote:
> 
> Hi Masoud,
> firstly, at this point you should have probably created an issue, the code can be formatted there if nothing else. So, if you have another problem, please do.
> 
> Regarding this one, I believe the problem is the last line of your callback "sr_free_val(vals);". Sysrepo then reads freed data.
> 
> Regards,
> Michal
> 
> On Friday, February 22, 2019 18:18 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com<mailto:mhemmatp at cisco.com>> wrote:
> 
> Thank you Michal for your reply. Problem solved. But the only issue is that when I try to get state data (operational data) I face segmentation fault. I tried to debug but it seems my callback is OK. Here it is my configuration:
> 
> Yang module :
>   grouping states {
>    leaf a{
>                type uint64;
>            }
>    leaf b{
>                type uint64;
>            }
> }
>    container  operational-data {
>        config false;
>        container states{
>            uses states;
>        }
>    }
> 
> In my plugin:
> sr_dp_get_items_subscribe(session, "/mymodel:operational-data ", state_cb, NULL, SR_SUBSCR_CTX_REUSE, subscription);
> 
> here it is the callback :
> 
> state_cb((const char *xpath, sr_val_t **values, size_t *values_cnt,
> uint64_t request_id, const char *original_xpath, void *private_ctx){
>    sr_val_t *vals;
>    rc = sr_new_values(1, &vals);
>    if (SR_ERR_OK != rc) {
>        return rc;
>    }
>    Approach 1 :
>    sr_val_build_xpath(&vals[0], "/hicn:hicn-state/states/a ");
>    sr_val_set_str_data(&vals[0], SR_UINT64_T, "10");
>    Approach 2 :
>    sr_val_set_xpath(&vals[0], "/hicn:hicn-state/states/a");
>    vals[0].type = SR_UINT64_T;
>    vals[0].data.uint64_val = 10;
> 
>    *values = vals;
>    *values_cnt = 1;
>     sr_free_val(vals);
> }
> I tried both approaches. Is there something wrong in my code?
> 
> 
> Kind Regards,
> Masoud,
> 
> 
> On 21 Feb 2019, at 09:07, Michal Va?ko <mvasko at cesnet.cz<mailto:mvasko at cesnet.cz><mailto:mvasko at cesnet.cz>> wrote:
> 
> Hi,
> 
> On Wednesday, February 20, 2019 15:50 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com<mailto:mhemmatp at cisco.com><mailto:mhemmatp at cisco.com>> wrote:
> 
> 
> Thanks Jan for your reply. Actually,  my question is that how to combine the operational data (read only),  configuration data (readable and writeable) and RPCs in yang model. I am going to connect these three elements.
> 
> Whatever YANG elements you want to combine in one model (operational, configuration data, RPCs, ...) you can.
> 
> I mean I need to call an RPC to perform some operations then modify some leaves regarding to the results. I tried to call an RPC then modify configuration data but when I read the config through get-config it returns the last data I modified through edit-config.
> 
> RPCs are generally not meant to modify configuration, they should, generally, execute some remote operation (Remote Procedure Call). Some examples from ietf-system model are <set-current-datetime> or <system-restart>. If you want to change configuration, do so using a standard RPC <edit-config> that is meant for changing configuration (as NETCONF uses only RPCs for synchronous communication, everything must be performed with one).
> 
> What is the approach to bind some operations when an element in configuration is modified?
> 
> I assume you are asking how to perform some operations on the actual system when some configuration elements are modified. This is the primary sysrepo use-case, you can do this by registering callbacks on the whole modules [1] or specific configuration nodes [2].
> 
> Regards,
> Michal
> 
> [1] http://www.sysrepo.org/static/doc/html/group__cl.html#ga35341cf4bf9584127f7c5a79405a878f
> [2] http://www.sysrepo.org/static/doc/html/group__cl.html#gad2af4031c4bc5e8a4f01437116f80167
> 
> 
> 
> Kind Regards,
> Thanks,
> 
> 
> 
> On 19 Feb 2019, at 19:55, Jan Kundr?t <jan.kundrat at cesnet.cz<mailto:jan.kundrat at cesnet.cz><mailto:jan.kundrat at cesnet.cz>> wrote:
> 
> I prepared a yang model consisting a container and some RPCs. Then, I prepared a plugin corresponding to the yang model. Next, I am going to connect netopeer2-cli to the netopeer2-server which is connected to the sysrepo and read/write the value of my leaf in my container.
> 
> Actually, I am not sure about the approach. Should I  call an RPC then through the sr_set_item manually modify the value of my leaf. If this is the right approach how can I provide my new values to the netopeer2-cli.
> 
> It depends on how the YANG model looks like. All items that are `config: true` are returned by sysrepo itself; these are considered, well, configuration, and configuration is stored in a sysrepo datastore. All items that are `config: false` are considered operation data, and your application and/or plugin should register a dp_get_items callback. That callback will be invoked when a standard NETCONF <get> RPC arrives.
> 
> If you want to provide data from a user-defined RPC, then register a callback to be invoked when a remote user requests this RPC. This is all covered in the docs.
> 
> With kind regards,
> Jan
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org><mailto:sysrepo-devel at sysrepo.org>
> http://lists.sysrepo.org/listinfo/sysrepo-devel
> 
> _______________________________________________
> sysrepo-devel mailing list
> sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org><mailto:sysrepo-devel at sysrepo.org>
> http://lists.sysrepo.org/listinfo/sysrepo-devel
> 
 
 


From mhemmatp at cisco.com  Mon Feb 25 10:07:29 2019
From: mhemmatp at cisco.com (Masoud Hemmatpour (mhemmatp))
Date: Mon, 25 Feb 2019 10:07:29 +0000
Subject: [sysrepo-devel] Provide data to netconf  client from sysrepo
In-Reply-To: <5637-5c73b700-9-5737ed80@162133157>
References: <5637-5c73b700-9-5737ed80@162133157>
Message-ID: <C89F5C2F-05BD-4D17-97A1-22AC75A8E09B@cisco.com>

Thanks Michal for the reply. Documentation works as a reference with the definition of APIs to me who just start to use it and I am getting familiar to it.

Kind Regards,

> On 25 Feb 2019, at 10:35, Michal Va?ko <mvasko at cesnet.cz> wrote:
> 
> Hi Masoud,
> I suppose you are using Approach 1:
> 
> sr_val_build_xpath(&vals[0], "/hicn:hicn-state/states/a ");
> sr_val_set_str_data(&vals[0], SR_UINT64_T, "10");
> 
> which is wrong, sr_val_set_str_data() is meant only for string types. If you were checking return values you would know. You should be fine if you used Approach 2.
> 
> Also, your issues are quite basic and could have been solved on your own with a little more effort. We are happy to provide support but at the same time will not waste time on problems that can be solved by reading the documentation or having basic C knowledge.
> 
> Regards,
> Michal
> 
> On Monday, February 25, 2019 09:59 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com> wrote: 
> 
>> Thanks Michal.  For the next issues sure. When I remove the "sr_free_val(vals);? here it is the output of debug mode in sysrepo-plugind:
>> 
>> [ERR] (sr_set_val_t_type_in_gpb:1250) Type can not be mapped to gpb type '/mymodel:operational-data' type 0
>> [ERR] (sr_dup_val_t_to_gpb:1410) Setting type in gpb failed for xpath '/mymodel:operational-data/a'
>> [ERR] (sr_values_sr_to_gpb:1704) Unable to duplicate sr_val_t to GPB.
>> [ERR] (cl_sm_dp_request_process:843) Error by copying output values to GPB.
>> 
>> I am sure about the data types are Ok. Is the problem for uint64?
>> 
>> Thanks,
>> 
>> On 25 Feb 2019, at 08:26, Michal Va?ko <mvasko at cesnet.cz<mailto:mvasko at cesnet.cz>> wrote:
>> 
>> Hi Masoud,
>> firstly, at this point you should have probably created an issue, the code can be formatted there if nothing else. So, if you have another problem, please do.
>> 
>> Regarding this one, I believe the problem is the last line of your callback "sr_free_val(vals);". Sysrepo then reads freed data.
>> 
>> Regards,
>> Michal
>> 
>> On Friday, February 22, 2019 18:18 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com<mailto:mhemmatp at cisco.com>> wrote:
>> 
>> Thank you Michal for your reply. Problem solved. But the only issue is that when I try to get state data (operational data) I face segmentation fault. I tried to debug but it seems my callback is OK. Here it is my configuration:
>> 
>> Yang module :
>>  grouping states {
>>   leaf a{
>>               type uint64;
>>           }
>>   leaf b{
>>               type uint64;
>>           }
>> }
>>   container  operational-data {
>>       config false;
>>       container states{
>>           uses states;
>>       }
>>   }
>> 
>> In my plugin:
>> sr_dp_get_items_subscribe(session, "/mymodel:operational-data ", state_cb, NULL, SR_SUBSCR_CTX_REUSE, subscription);
>> 
>> here it is the callback :
>> 
>> state_cb((const char *xpath, sr_val_t **values, size_t *values_cnt,
>> uint64_t request_id, const char *original_xpath, void *private_ctx){
>>   sr_val_t *vals;
>>   rc = sr_new_values(1, &vals);
>>   if (SR_ERR_OK != rc) {
>>       return rc;
>>   }
>>   Approach 1 :
>>   sr_val_build_xpath(&vals[0], "/hicn:hicn-state/states/a ");
> 
>>   sr_val_set_str_data(&vals[0], SR_UINT64_T, "10");
>>   Approach 2 :
>>   sr_val_set_xpath(&vals[0], "/hicn:hicn-state/states/a");
>>   vals[0].type = SR_UINT64_T;
>>   vals[0].data.uint64_val = 10;
>> 
>>   *values = vals;
>>   *values_cnt = 1;
>>    sr_free_val(vals);
>> }
>> I tried both approaches. Is there something wrong in my code?
>> 
>> 
>> Kind Regards,
>> Masoud,
>> 
>> 
>> On 21 Feb 2019, at 09:07, Michal Va?ko <mvasko at cesnet.cz<mailto:mvasko at cesnet.cz><mailto:mvasko at cesnet.cz>> wrote:
>> 
>> Hi,
>> 
>> On Wednesday, February 20, 2019 15:50 CET, "Masoud Hemmatpour (mhemmatp)" <mhemmatp at cisco.com<mailto:mhemmatp at cisco.com><mailto:mhemmatp at cisco.com>> wrote:
>> 
>> 
>> Thanks Jan for your reply. Actually,  my question is that how to combine the operational data (read only),  configuration data (readable and writeable) and RPCs in yang model. I am going to connect these three elements.
>> 
>> Whatever YANG elements you want to combine in one model (operational, configuration data, RPCs, ...) you can.
>> 
>> I mean I need to call an RPC to perform some operations then modify some leaves regarding to the results. I tried to call an RPC then modify configuration data but when I read the config through get-config it returns the last data I modified through edit-config.
>> 
>> RPCs are generally not meant to modify configuration, they should, generally, execute some remote operation (Remote Procedure Call). Some examples from ietf-system model are <set-current-datetime> or <system-restart>. If you want to change configuration, do so using a standard RPC <edit-config> that is meant for changing configuration (as NETCONF uses only RPCs for synchronous communication, everything must be performed with one).
>> 
>> What is the approach to bind some operations when an element in configuration is modified?
>> 
>> I assume you are asking how to perform some operations on the actual system when some configuration elements are modified. This is the primary sysrepo use-case, you can do this by registering callbacks on the whole modules [1] or specific configuration nodes [2].
>> 
>> Regards,
>> Michal
>> 
>> [1] http://www.sysrepo.org/static/doc/html/group__cl.html#ga35341cf4bf9584127f7c5a79405a878f
>> [2] http://www.sysrepo.org/static/doc/html/group__cl.html#gad2af4031c4bc5e8a4f01437116f80167
>> 
>> 
>> 
>> Kind Regards,
>> Thanks,
>> 
>> 
>> 
>> On 19 Feb 2019, at 19:55, Jan Kundr?t <jan.kundrat at cesnet.cz<mailto:jan.kundrat at cesnet.cz><mailto:jan.kundrat at cesnet.cz>> wrote:
>> 
>> I prepared a yang model consisting a container and some RPCs. Then, I prepared a plugin corresponding to the yang model. Next, I am going to connect netopeer2-cli to the netopeer2-server which is connected to the sysrepo and read/write the value of my leaf in my container.
>> 
>> Actually, I am not sure about the approach. Should I  call an RPC then through the sr_set_item manually modify the value of my leaf. If this is the right approach how can I provide my new values to the netopeer2-cli.
>> 
>> It depends on how the YANG model looks like. All items that are `config: true` are returned by sysrepo itself; these are considered, well, configuration, and configuration is stored in a sysrepo datastore. All items that are `config: false` are considered operation data, and your application and/or plugin should register a dp_get_items callback. That callback will be invoked when a standard NETCONF <get> RPC arrives.
>> 
>> If you want to provide data from a user-defined RPC, then register a callback to be invoked when a remote user requests this RPC. This is all covered in the docs.
>> 
>> With kind regards,
>> Jan
>> _______________________________________________
>> sysrepo-devel mailing list
>> sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org><mailto:sysrepo-devel at sysrepo.org>
>> http://lists.sysrepo.org/listinfo/sysrepo-devel
>> 
>> _______________________________________________
>> sysrepo-devel mailing list
>> sysrepo-devel at sysrepo.org<mailto:sysrepo-devel at sysrepo.org><mailto:sysrepo-devel at sysrepo.org>
>> http://lists.sysrepo.org/listinfo/sysrepo-devel
>> 
> 
> 
>