[controller-dev] Signing Off

[Ryan Goulding]

Hi ODL Community,


I have decided to make a career transition to an opportunity I could not
pass up, and will no longer contribute to ODL after this week.  This past 4
years has been great;  I saw this entire community grow, thrive and mature,
and I am very proud of what we collectively built.  I have learned so much
from everyone regarding technology and business fronts, and I am grateful
to all of you.


I wish you all the best of luck going forward.  Stay in touch.


Best Regards,

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

Re: [controller-dev] Which Release is the Most Recent in Stable State That Compiles

[Ryan Goulding]

>
> Thats weird, AFAIK ODL settings.xml is always required.
>

He still has settings.xml, he is stating he is using the one downloaded
from stable/oxygen, if I understand correctly.  The fact is, settings.xml
hardly ever changes, even between releases [0].  It hasn't changed in over
a year in fact.

The trick is to use stable release (never expires) instead of stable
> branch, you can download a given release by using a tag, for example:
>

If you are trying to contribute a delta back upstream to the open source
code base instead of maintaining a "permanent" fork, then you will want to
build and submit against master.  The stability of master has improved over
the years :).

Regards,

Ryan Goulding

[0] https://github.com/opendaylight/odlparent/commits/master/settings.xml

On Tue, Jun 19, 2018 at 5:40 PM, Luis Gomez  wrote:

>
>
> On Jun 19, 2018, at 2:26 PM, harry.zh...@us.fujitsu.com wrote:
>
> Hi Ecelgp,
>
> Thank you very much! It compiles now.
>
> May I ask whether settings.xml is common to all of the releases? After
> switched to stable/oxygen, it compiles even without changing the
> settings.xml file.
>
>
> Thats weird, AFAIK ODL settings.xml is always required.
>
>
> If I put some of my work under this stable/oxygen branch, someday later
> the branch is no longer supported as what happened to stable/boron, may I
> ask what the best strategy is for me to deal with the situation, in case I
> am not ready to merge my code to a new release?
>
>
> The trick is to use stable release (never expires) instead of stable
> branch, you can download a given release by using a tag, for example:
>
> git fetch --all --tags —prune
> git checkout tags/release/oxygen-sr2
>
>
> If I need to save my environment to share with a development team, may I
> ask which files and directories that I should save to a local storage so
> that our development efforts would not be effected by Opendaylight release
> supporting plan?
>
>
> I am not sure I full follow the question but you could save the entire git
> repo or just the changes you did.
>
>
>
> Best Regards,
>
> Harry
>
>
>
> *From:* Luis Gomez [mailto:ece...@gmail.com ]
> *Sent:* Tuesday, June 19, 2018 3:49 PM
> *To:* Zhang, Harry 
> *Cc:* controller-dev@lists.opendaylight.org
> *Subject:* Re: [controller-dev] Which Release is the Most Recent in
> Stable State That Compiles
>
> Hi Harry, stable/oxygen is the latest stable release.
>
>
> On Jun 19, 2018, at 1:46 PM, harry.zh...@us.fujitsu.com wrote:
>
> Hi Everybody,
>
> I am trying to find a recent stable branch to compile the controller and
> Netconf projects. I did,
>
> git clone https://git.opendaylight.org/gerrit/p/controller.git
> cd controller/
> git checkout stable/boron
>
> I saved the file https://github.com/opendaylight/odlparent/blob/
> stable/boron/settings.xml
> <https://github.com/opendaylight/odlparent/blob/stable/boron/settings.xml%20to%20my%20.m2>
>  to
> my local ~/.m2/
>
> When compiled, I got errors as following. Mr. Tom Pantelis
> <https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis> said
> “The Boron release is no longer maintained or supported. As such, the
> failed dependencies likely no longer exist on ODL nexus”.
>
> May I ask which stable release that is still supported I should use to
> continue my tests?
>
>
> Regards,
>
> Harry
>
>
>
> ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project org.opendaylight.controller:releasepom:0.4.5-SNAPSHOT
> (/home/hzhang/controller/pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM for 
> org.opendaylight.controller:releasepom:0.4.5-SNAPSHOT:
> Failure to find org.opendaylight.odlparent:odlparent-lite:pom:1.7.5-SNAPSHOT
> in https://nexus.opendaylight.org/content/repositories/
> opendaylight.snapshot/ was cached in the local repository,
>
>
>
>
> The Boron release is no longer maintained or supported. As such, the
> failed dependencies likely no longer exist on ODL nexus.
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] karaf user validation query

[Ryan Goulding]

I recommend you engage upstream Apache Karaf;  they maintain and are
familiar with those modules.  They are not written nor maintained by ODL
Developers.

HTH.

Regards,

Ryan Goulding

On Fri, Jun 8, 2018 at 6:37 AM, Steubert Ebenezer <
steuber...@altencalsoftlabs.com> wrote:

> Hi Ryan,
>
>
>
> Thanks for your response.
>
>
>
> We need to salt and hash the karaf CLI user passwords.
>
>
>
> We installed jasypt (feature:install jasypt) on controller and modified
> [karf.dir]/etc/org.apache.karaf.jaas.cfg as below.
>
> encryption.name = jasypt
>
> encryption.saltSizeBytes = 16
>
>
>
> Now we created two new karaf CLI users with same password.
>
> opendaylight-user@root>jaas:user-add steubert karaf
>
> opendaylight-user@root>jaas:user-add kathir karaf
>
> opendaylight-user@root>jaas:update
>
>
>
> Now if we check user [karf.dir]/etc/users.properties file we see the
> encrypted passwords are different
>
> steubert = {CRYPT}PH/RiJ/ZH2ss0TyKt/zY0qlrnYSHfCUsg4K3SODMfeQGDUD0
> fa944UKpJtQqxHyxf/8O66+Pyspk6SckxJswEza+sW+cIZ7U{CRYPT}
>
> kathir = {CRYPT}jqR3DDw6+RRuAbImxj46w4uunR3gLTENWi1JGzhcVr+ka1S9Tq1qFafGR/
> FyIc9FQGhGF7NyyGkqPf/gJKff45zbqvAEYaJZ{CRYPT}
>
>
>
> We have below questions on this.
>
>1. How can we ensure if salting is happening here
>2. Where are the salts stored
>3. How does the login module authenticate the users if the salts are
>not stored
>
>
>
> Regards,
>
> Steubert.
>
>
>
> *From:* Ryan Goulding 
> *Sent:* 07 June 2018 20:24
> *To:* Nishchya Gupta 
> *Cc:* controller-dev@lists.opendaylight.org; odl netvirt dev <
> netvirt-...@lists.opendaylight.org>; genius-...@lists.opendaylight.org;
> kathirve...@altencalsoftlabs.com; vijay.dan...@ericsson.com;
> steuber...@altencalsoftlabs.com; shashidh...@altencalsoftlabs.com
> *Subject:* Re: [controller-dev] karaf user validation query
>
>
>
> For karaf CLI or RESTCONF?
>
>
>
> karaf cli is managed through system.properties and other files in
> KARAF_ROOT/etc.
>
>
>
> HTH.
>
>
> Regards,
>
> Ryan Goulding
>
>
>
> On Thu, Jun 7, 2018 at 6:40 AM, Nishchya Gupta <
> nishch...@altencalsoftlabs.com> wrote:
>
> Hi,
>
>
>
> In apache/karaf for user validations we understood hashing has been used.
>
> Is there anyway or configuration change, to have this salted and hashed?
>
>
>
>
>
> Regards,
>
> Nishchya
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Kernel Call 6/5/2018

[Ryan Goulding]

Hi All,

Apologies, Due to unforeseen circumstances I am unable to make the call today.  
Please continue to utilize the Zoom meeting and mail me anything needed.

Ryan

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

Re: [controller-dev] Unable To Make Today's Kernel Projects Call

[Ryan Goulding]

Unfortunately unable to make it again.  Working on clearing up this time
slot in the future.

Please feel free to utilize the Zoom meeting without me.

Thanks,
Ryan

Regards,

Ryan Goulding

On Tue, Apr 24, 2018 at 11:53 AM, Ryan Goulding <ryandgould...@gmail.com>
wrote:

> Hi Devs,
>
> I am currently caught up, and cannot make the call today.  Please feel
> free to utilize the Zoom meeting without me.
>
> Thanks,
>
> Ryan
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Unable To Make Today's Kernel Projects Call

[Ryan Goulding]

Hi Devs,

I am currently caught up, and cannot make the call today.  Please feel free
to utilize the Zoom meeting without me.

Thanks,

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

Re: [controller-dev] Web Framework Discussion (continued from Kernel Call)

[Ryan Goulding]

For the sake of being open, this [0] is the partial AAA conversion patch,
and [1] is needed to test RESTCONF (RESTCONF currently depends on AAA
loading the jersey 1.17 runtime dependencies, which isn't correct and
should be fixed anyway).

Regards,

Ryan Goulding

[0] https://git.opendaylight.org/gerrit/#/c/70795/
[1] https://git.opendaylight.org/gerrit/#/c/70794/

On Wed, Apr 11, 2018 at 11:50 AM, Ryan Goulding <ryandgould...@gmail.com>
wrote:

> Hi All,
>
> During the Kernel call this past Tuesday, we talked about attempting an
> isolated transition of AAA restful web services from Jersey 1 to Jersey 2.
> I attempted this change yesterday, and was able to partially convert (I
> just temporarily removed non-essential code that would've required
> overhaul).  However, when I compiled NETCONF next to test RESTCONF, I
> quickly realized that:
>
> 1) jersey-2.26 won't behave well, since it relies on javax.ws.rs-api 2.1
> and jersey 1.17 relies on javax.ws.rs-api 2.0.1.  This leads to a Uses
> constraint violation since the dependency is provided via two chains (and
> two different versions too!).
>
> 2) jersey-2.25 won't work for a similar reason.  Even though it relies on
> the older javax.ws.rs-api 2.0.1 which is currently in place, jersey 1.17
> repackages javax.ws.rs-api.  This means that utilizing the off the shelf
> javax.ws.rs-api 2.0.1 causes another Uses constraint violation, since the
> dependency is provided via upstream properly and jersey 1.17 in a
> repackaged form.
>
> I am starting to really agree with the sentiment that we should just stick
> to only one implementation across the board.  Additionally, I believe that
> isolating this in an API (utility or not) will help the transition since
> there will be a single point to toggle the implementations.  We may want to
> also discuss the drawbacks of jersey 2.  Namely, it appears to require a
> ton of overhead dependencies and starts a bit slower in newer versions.
> Maybe that is fine, but we should fully understand the tradeoffs before
> investing more time.  We should also settle on what the intended version
> should be for jersey 2 if we go that route, since jersey-2.26 is a lot
> different than even jersey-2.25.
>
> Thoughts?
>
> Regards,
>
> Ryan
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Web Framework Discussion (continued from Kernel Call)

[Ryan Goulding]

Hi All,

During the Kernel call this past Tuesday, we talked about attempting an
isolated transition of AAA restful web services from Jersey 1 to Jersey 2.
I attempted this change yesterday, and was able to partially convert (I
just temporarily removed non-essential code that would've required
overhaul).  However, when I compiled NETCONF next to test RESTCONF, I
quickly realized that:

1) jersey-2.26 won't behave well, since it relies on javax.ws.rs-api 2.1
and jersey 1.17 relies on javax.ws.rs-api 2.0.1.  This leads to a Uses
constraint violation since the dependency is provided via two chains (and
two different versions too!).

2) jersey-2.25 won't work for a similar reason.  Even though it relies on
the older javax.ws.rs-api 2.0.1 which is currently in place, jersey 1.17
repackages javax.ws.rs-api.  This means that utilizing the off the shelf
javax.ws.rs-api 2.0.1 causes another Uses constraint violation, since the
dependency is provided via upstream properly and jersey 1.17 in a
repackaged form.

I am starting to really agree with the sentiment that we should just stick
to only one implementation across the board.  Additionally, I believe that
isolating this in an API (utility or not) will help the transition since
there will be a single point to toggle the implementations.  We may want to
also discuss the drawbacks of jersey 2.  Namely, it appears to require a
ton of overhead dependencies and starts a bit slower in newer versions.
Maybe that is fine, but we should fully understand the tradeoffs before
investing more time.  We should also settle on what the intended version
should be for jersey 2 if we go that route, since jersey-2.26 is a lot
different than even jersey-2.25.

Thoughts?

Regards,

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

Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

[Ryan Goulding]

Did you restart ODL after installing odl-jolikia? The issue is you have jolikia 
installed from karaf without auth, then try to install odl-jolikia which lays 
down org.jolikia.osgi.cfg with authMode set to delegate. That managed service 
won’t actually recognize the update to authmode without a restart of Karaf. You 
want to ONLY ever install odl-jolokia!!

Sent from my iPhone

> On Apr 7, 2018, at 12:19 PM, Jamo Luhrsen <jluhr...@gmail.com> wrote:
> 
> ok, I verified that carbon sr3 is working as we expect, but the recent 
> Fluorine
> snapshot distro I have is not behaving like I expect.
> 
> I am able to hit this 
> jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus
> endpoint after just installing features-aaa, nothing else. The user/password 
> doesn't
> seem to matter.
> 
> After installing odl-jolokia, it's the same behavior.
> 
> should I open a jira, or what other info can I gather?
> 
> Thanks,
> JamO
> 
>> On 4/5/18 3:45 PM, Ryan Goulding wrote:
>> for carbon-sr3 we still hadn't integrated jolokia with AAA;  it was still 
>> backed by etc/org.jolokia.osgi.cfg, hencewhy you need to use admin/admin 
>> after changing the password in AAA.
>> How did you install jolokia in Fluorine?  You must install using 
>> "odl-jolokia" feature from controller to get protection.  Standard off the 
>> shelf "jolokia" has NO auth by default...
>> Regards,
>> Ryan Goulding
>> On Thu, Apr 5, 2018 at 6:23 PM, Jamo Luhrsen <jluhr...@gmail.com 
>> <mailto:jluhr...@gmail.com>> wrote:
>>I don't have access to my setup at the moment. I can later.
>>but, I think it's based on carbon sr3.
>>I do have a recent (2/27) snapshot distro from Fluorine though,
>>and that actually doesn't even need creds to access that
>>jolokia diagstatus endpoint. restconf still behaves like I
>>expect, but the diagstatus endpoint takes any (or no)
>>username/password combo.
>>    JamO
>>On 4/5/18 12:06 PM, Ryan Goulding wrote:
>>Jamo, can you comment on code version?  Thanks!
>>Regards,
>>Ryan Goulding
>>On Thu, Apr 5, 2018 at 7:10 AM, Ryan Goulding 
>> <ryandgould...@gmail.com <mailto:ryandgould...@gmail.com>
>><mailto:ryandgould...@gmail.com <mailto:ryandgould...@gmail.com>>> 
>> wrote:
>> What version of code? This wasn’t tied to AAA until oxygen. 
>> Prior it was controlled by etc/or.jolokia.osgi.cfg.
>> Thanks,
>> Ryan
>> Sent from my iPhone
>> On Apr 5, 2018, at 12:32 AM, Michael Vorburger 
>> <vorbur...@redhat.com <mailto:vorbur...@redhat.com>
>><mailto:vorbur...@redhat.com <mailto:vorbur...@redhat.com>>> wrote:
>> JamO, +aaa-dev and +controller-dev and Stephen FYI:
>> On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen 
>> <jluhr...@gmail.com <mailto:jluhr...@gmail.com>
>><mailto:jluhr...@gmail.com <mailto:jluhr...@gmail.com>>>wrote:
>> Hi Utility folks,
>> I noticed in a local setup I have where I've changed the 
>> default username
>> and password for RESTCONF, that I still need to use the 
>> admin:admin creds
>> to hit the diagstatus endpoint.
>> I'm guessing that's just because this is not tied in to 
>> the magic of
>> AAA and/or RESTCONF creds.
>> Gotta just live with it, or would it be an easy thing to 
>> add, just to keep
>> things more intuitive?
>> This seems like a bug (bad one, security wise), but it's not 
>> for infrautils-dev - we don't actually do
>>anything
>> re. Jolokia in project infrautils, the diagstatus sub-module 
>> simply exposes a JMX bean... the code
>>related to the
>> Jolokia integration in ODL which then make makes this 
>> available via HTTP, and secures it with the AAA
>>creds (also
>> used by RESTCONF; there are no creds in RESTCONF itself 
>> FYI), is actually in controller and/or aaa (I'm
>>not 100%
>> sure myself what is where)... see 
>> https://jira.opendaylight.org/browse/AAA-147
>><https://jira.opendaylight.org/browse/AAA-147>
>> <https://jira.opendaylight.org/browse/AAA-147 
>> <https://jira.open

Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

[Ryan Goulding]

for carbon-sr3 we still hadn't integrated jolokia with AAA;  it was still
backed by etc/org.jolokia.osgi.cfg, hencewhy you need to use admin/admin
after changing the password in AAA.

How did you install jolokia in Fluorine?  You must install using
"odl-jolokia" feature from controller to get protection.  Standard off the
shelf "jolokia" has NO auth by default...

Regards,

Ryan Goulding

On Thu, Apr 5, 2018 at 6:23 PM, Jamo Luhrsen <jluhr...@gmail.com> wrote:

> I don't have access to my setup at the moment. I can later.
>
> but, I think it's based on carbon sr3.
>
> I do have a recent (2/27) snapshot distro from Fluorine though,
> and that actually doesn't even need creds to access that
> jolokia diagstatus endpoint. restconf still behaves like I
> expect, but the diagstatus endpoint takes any (or no)
> username/password combo.
>
> JamO
>
> On 4/5/18 12:06 PM, Ryan Goulding wrote:
>
>> Jamo, can you comment on code version?  Thanks!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> On Thu, Apr 5, 2018 at 7:10 AM, Ryan Goulding <ryandgould...@gmail.com
>> <mailto:ryandgould...@gmail.com>> wrote:
>>
>> What version of code? This wasn’t tied to AAA until oxygen. Prior it
>> was controlled by etc/or.jolokia.osgi.cfg.
>>
>> Thanks,
>> Ryan
>>
>> Sent from my iPhone
>>
>> On Apr 5, 2018, at 12:32 AM, Michael Vorburger <vorbur...@redhat.com
>> <mailto:vorbur...@redhat.com>> wrote:
>>
>> JamO, +aaa-dev and +controller-dev and Stephen FYI:
>>>
>>> On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen <jluhr...@gmail.com
>>> <mailto:jluhr...@gmail.com>>wrote:
>>>
>>> Hi Utility folks,
>>>
>>> I noticed in a local setup I have where I've changed the default
>>> username
>>> and password for RESTCONF, that I still need to use the
>>> admin:admin creds
>>> to hit the diagstatus endpoint.
>>>
>>> I'm guessing that's just because this is not tied in to the
>>> magic of
>>> AAA and/or RESTCONF creds.
>>>
>>> Gotta just live with it, or would it be an easy thing to add,
>>> just to keep
>>> things more intuitive?
>>>
>>>
>>> This seems like a bug (bad one, security wise), but it's not for
>>> infrautils-dev - we don't actually do anything
>>> re. Jolokia in project infrautils, the diagstatus sub-module simply
>>> exposes a JMX bean... the code related to the
>>> Jolokia integration in ODL which then make makes this available via
>>> HTTP, and secures it with the AAA creds (also
>>> used by RESTCONF; there are no creds in RESTCONF itself FYI), is
>>> actually in controller and/or aaa (I'm not 100%
>>> sure myself what is where)... see https://jira.opendaylight.org/
>>> browse/AAA-147
>>> <https://jira.opendaylight.org/browse/AAA-147> and
>>> https://jira.opendaylight.org/browse/CONTROLLER-1324
>>> <https://jira.opendaylight.org/browse/CONTROLLER-1324>.
>>>
>>> If you are right, we have this problem (that when changing the
>>> default username and password you can still use the
>>> previous one) on *ALL* /jolokia/ URLs, I'm guessing.
>>>
>>> Would you like to open a (Critical?) bug in JIRA against AAA about
>>> this?
>>>
>>> Tx,
>>> M.
>>> --
>>> Michael Vorburger, Red Hat
>>> vorbur...@redhat.com <mailto:vorbur...@redhat.com>| IRC: vorburger
>>> @freenode | ~ = http://vorburger.ch
>>> <http://vorburger.ch/>
>>>
>>> example curl:
>>>
>>> curl -u "admin:admin"
>>> http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infr
>>> autils.diagstatus:type=SvcStatus/acquireServiceStatus
>>> <http://192.168.24.11:8081/jolokia/exec/org.opendaylight.inf
>>> rautils.diagstatus:type=SvcStatus/acquireServiceStatus>
>>>
>>> Thanks,
>>> JamO
>>> ___
>>> infrautils-dev mailing list
>>> infrautils-...@lists.opendaylight.org >> infrautils-...@lists.opendaylight.org>
>>> https://lists.opendaylight.org/mailman/listinfo/infrautils-dev
>>> <https://lists.opendaylight.org/mailman/listinfo/infrautils-dev>
>>>
>>>
>>> ___
>>> controller-dev mailing list
>>> controller-dev@lists.opendaylight.org <mailto:controller-dev@lists.o
>>> pendaylight.org>
>>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>> <https://lists.opendaylight.org/mailman/listinfo/controller-dev>
>>>
>>
>>
>>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [infrautils-dev] credentials for REST to jolokia/exec/org.opendaylight.infrautils.diagstatus

[Ryan Goulding]

What version of code? This wasn’t tied to AAA until oxygen. Prior it was 
controlled by etc/or.jolokia.osgi.cfg.

Thanks,
Ryan

Sent from my iPhone

> On Apr 5, 2018, at 12:32 AM, Michael Vorburger  wrote:
> 
> JamO, +aaa-dev and +controller-dev and Stephen FYI:
> 
>> On Wed, Apr 4, 2018 at 10:24 PM, Jamo Luhrsen  wrote:
> 
>> Hi Utility folks,
>> 
>> I noticed in a local setup I have where I've changed the default username
>> and password for RESTCONF, that I still need to use the admin:admin creds
>> to hit the diagstatus endpoint.
>> 
>> I'm guessing that's just because this is not tied in to the magic of
>> AAA and/or RESTCONF creds.
>> 
>> Gotta just live with it, or would it be an easy thing to add, just to keep
>> things more intuitive?
> 
> This seems like a bug (bad one, security wise), but it's not for 
> infrautils-dev - we don't actually do anything re. Jolokia in project 
> infrautils, the diagstatus sub-module simply exposes a JMX bean... the code 
> related to the Jolokia integration in ODL which then make makes this 
> available via HTTP, and secures it with the AAA creds (also used by RESTCONF; 
> there are no creds in RESTCONF itself FYI), is actually in controller and/or 
> aaa (I'm not 100% sure myself what is where)... see 
> https://jira.opendaylight.org/browse/AAA-147 and 
> https://jira.opendaylight.org/browse/CONTROLLER-1324. 
> 
> If you are right, we have this problem (that when changing the default 
> username and password you can still use the previous one) on *ALL* /jolokia/ 
> URLs, I'm guessing.
> 
> Would you like to open a (Critical?) bug in JIRA against AAA about this?
> 
> Tx,
> M.
> --
> Michael Vorburger, Red Hat
> vorbur...@redhat.com | IRC: vorburger @freenode | ~ = http://vorburger.ch
>  
>> example curl:
>> 
>> curl -u "admin:admin" 
>> http://192.168.24.11:8081/jolokia/exec/org.opendaylight.infrautils.diagstatus:type=SvcStatus/acquireServiceStatus
>> 
>> Thanks,
>> JamO
>> ___
>> infrautils-dev mailing list
>> infrautils-...@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/infrautils-dev
> 
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Binding V1 codegen in Fluorine

[Ryan Goulding]

Although Robert already explained this well in his original email, there
are some additional notes [0] from the kernel call that also elaborate on
this proposal.  To summarize, no one raised much concern surrounding the
potential impacts, and the change seems straightforward and necessary.

Regards,

Ryan Goulding

[0]
https://meetings.opendaylight.org/opendaylight-meeting/2018/kernel_projects/opendaylight-meeting-kernel_projects.2018-03-06-17.00.html

On Wed, Mar 7, 2018 at 9:19 AM, Robert Varga <n...@hq.sk> wrote:

> On 01/03/18 18:31, Robert Varga wrote:
> > Hello everyone,
> >
> > TL;DR:
> > Implementation of Binding Specification V1 needs to be improved in a way
> > that breaks the ability to load Fluorine-generated code in older
> containers.
> >
> > Are there any objections to doing that?
>
> No objections have been raised thus far and we have a stack of patches
> depending on this.
>
> If no objections are raised this week, we will treat this as a plan of
> record and this change will get incorporated next week and release-noted
> in Fluorine SR release notes.
>
> If this is not agreeable to you, please speak up now.
>
> Thanks,
> Robert
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Kernel Projects Meeting

[Ryan Goulding]

Hi All,

Unfortunately, I cannot make the call today due to doctor's appointment.
Please feel free to utilize the existing zoom meeting without me.

King Regards,

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

Re: [controller-dev] [Odlparent-dev] odlparent 3.0.2 for CONTROLLER-1799: Archetype self test during Maven build

[Ryan Goulding]

If you end up taking this on let me know, and I will abandon [0].  I had
originally done this to avoid a ton of unused CLI related code in gen'd
code.

Regards,

Ryan Goulding

[0] https://git.opendaylight.org/gerrit/#/c/67070/

On Tue, Jan 23, 2018 at 10:45 AM, Michael Vorburger <vorbur...@redhat.com>
wrote:

> On Tue, Jan 23, 2018 at 5:03 AM, Sam Hague <sha...@redhat.com> wrote:
>
>> On Mon, Jan 22, 2018 at 9:30 PM, Tom Pantelis <tompante...@gmail.com>
>> wrote:
>>
>>> On Mon, Jan 22, 2018 at 9:26 PM, Michael Vorburger <vorbur...@redhat.com
>>> > wrote:
>>>
>>>> On Mon, Jan 22, 2018 at 7:17 PM, Michael Vorburger <
>>>> vorbur...@redhat.com> wrote:
>>>>
>>>>> On Thu, Jan 18, 2018 at 5:25 PM, Tom Pantelis <tompante...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Thu, Jan 18, 2018 at 10:45 AM, Michael Vorburger <
>>>>>> vorbur...@redhat.com> wrote:
>>>>>>
>>>>>>> On Wed, Nov 29, 2017 at 12:29 PM, Michael Vorburger <
>>>>>>> vorbur...@redhat.com> wrote:
>>>>>>>
>>>>>>>> On Mon, Nov 27, 2017 at 8:10 PM, Michael Vorburger <
>>>>>>>> vorbur...@redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> almost 3 months ago, on https://lists.opendaylight.
>>>>>>>>> org/pipermail/controller-dev/2017-September/013889.html, I had
>>>>>>>>> started a thread re. the mysterious problems hit in the controller
>>>>>>>>> archetype "self test", which occured on Gerrit and Jenkins, and only 
>>>>>>>>> there
>>>>>>>>> (it worked locally even 3 months ago).
>>>>>>>>>
>>>>>>>>> Today I finally made time to progress on this, and
>>>>>>>>> https://jira.opendaylight.org/browse/CONTROLLER-1799 has the
>>>>>>>>> write up what is going on there, documented for future reference.
>>>>>>>>>
>>>>>>>>> Is this feasible to get an odlparent 3.0.2 with
>>>>>>>>> https://git.opendaylight.org/gerrit/#/c/65940/ for
>>>>>>>>> https://git.opendaylight.org/gerrit/#/c/65941/ ?
>>>>>>>>>
>>>>>>>>> Tx,
>>>>>>>>> M.
>>>>>>>>>
>>>>>>>>> PS: I'm hoping to work on https://jira.opendaylight.org/
>>>>>>>>> browse/INFRAUTILS-17 in the coming days, which will likely also
>>>>>>>>> require a change in odlparent; perhaps this and that could be pooled
>>>>>>>>> together into a 3.0.2 - anything else?
>>>>>>>>>
>>>>>>>>
>>>>>>>> https://git.opendaylight.org/gerrit/#/c/66030/ and its related
>>>>>>>> changes are what I meant here; if all of this, together with
>>>>>>>> https://git.opendaylight.org/gerrit/#/c/65940/, could be released
>>>>>>>> as an odlparent 3.0.2, in the hopefully not-too-distant future, that 
>>>>>>>> would
>>>>>>>> be fabulous.
>>>>>>>>
>>>>>>>
>>>>>>> would any fellow controller commiter be willing to merge this
>>>>>>> https://git.opendaylight.org/gerrit/#/c/65941/ now?
>>>>>>>
>>>>>>> Tom, or even I volunteer to, then rebase https://git.opendayligh
>>>>>>> t.org/gerrit/#/c/66545/ on top of that c/65941 and then I'm happy
>>>>>>> to merge that one after.
>>>>>>>
>>>>>>> It would be good to get both of these archetype things into Oxygen
>>>>>>> still IMHO.
>>>>>>>
>>>>>>
>>>>>> Agree - I rebased - will merge after
>>>>>>
>>>>>
>>>>> just done, but hit https://jira.opendaylight.
>>>>> org/browse/CONTROLLER-1810 .. following the Big Bump, the Archetype
>>>>> IT is actually broken.. seems to have something to do with some (shutdown
>>>>> related?) problem in AAA ? Don't be shy to comment on CONTROLLER-1810 if
>>>>> you have any clue what could be

[controller-dev] Kernel Projects Call Agenda Topics

[Ryan Goulding]

Hi all,

Please update the agenda with relevant topics for tomorrows kernel projects
meeting.

Thanks!

Regards,

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

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

[Ryan Goulding]

17:26:54  [ERROR] Failed to execute goal
org.codehaus.mojo:findbugs-maven-plugin:3.0.4:findbugs (findbugs) on
project sal-distributed-datastore: Execution findbugs of goal
org.codehaus.mojo:findbugs-maven-plugin:3.0.4:findbugs failed: Java
returned: 137 -> [Help 1]


Exit Code 137: Probably OOM of some sort.  I would posit that this is an
environmental issue.


Regards,

Ryan Goulding

On Tue, Oct 24, 2017 at 1:27 PM, Jenkins <jenkins-dontre...@opendaylight.org
> wrote:

> Attention controller-devs,
>
> Autorelease nitrogen failed to build sal-distributed-datastore from
> controller in build
> 253. Attached is a snippet of the error message related to the
> failure that we were able to automatically parse as well as console logs.
>
>
> Console Logs:
> https://logs.opendaylight.org/releng/jenkins092/autorelease-
> release-nitrogen/253
>
> Jenkins Build:
> https://jenkins.opendaylight.org/releng/job/autorelease-
> release-nitrogen/253/
>
> Please review and provide an ETA on when a fix will be available.
>
> Thanks,
> ODL releng/autorelease team
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Out of Office during kernel projects call

[Ryan Goulding]

Hi Folks,

Unfortunately I have an existing appointment during the time slot for this
week's kernel projects meeting.  Please feel free to continue to use the
Zoom account for the meeting.

Thanks and Best Regards,

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

[controller-dev] Unable to make call today

[Ryan Goulding]

Hi all,

Unfortunately, I am unable to make the call. Please feel free to use my 
existing bridge.

Regards,
Ryan

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

Re: [controller-dev] [Odlparent-dev] configuration/logback.xml logging configuration used for what?

[Ryan Goulding]

Sometimes people spawn test appenders to do log collection in unit tests.
I have done this in AAA when i was expecting very specific accounting
messages.  I believe that is the point of some of this... I think its
better to not use a chainsaw...

Regards,

Ryan Goulding

On Thu, Jul 27, 2017 at 3:01 PM, Michael Vorburger <vorbur...@redhat.com>
wrote:

> On Thu, Jul 27, 2017 at 11:51 PM, Robert Varga <n...@hq.sk> wrote:
>
>> On 27/07/17 13:05, Michael Vorburger wrote:
>> > Hello parents,
>>
>> Hello Michael,
>>
>> > as I'm having a closer look at what we've done re. logging, I'm
>> > discovering that in an ODL $KARAF_HOME we have:
>> >
>> > 1. a etc/org.ops4j.pax.logging.cfg (from
>> > odlparent/karaf/opendaylight-karaf-resources/src/main/resour
>> ces/etc/org.ops4j.pax.logging.cfg)
>> >
>> > VS
>> >
>> > 2. configuration/logback.xml (from
>> > odlparent/karaf/opendaylight-karaf-resources/src/main/resour
>> ces/configuration/logback.xml)
>> >
>> >
>> > I thought we (Karaf) used Log4j v2 (through the slf4j API, with OPS4j's
>> > PAX Logging in the middle playing some role) - so that is that LogBack
>> > configuration used for??
>>
>> The logback piece should be removed from controller, as it did not work
>> since we moved to karaf, as far as I can tell...
>>
>
> I'm probably missing some history here, and didn't immediately get why you
> mentioned "from controller" here when I (just) asked about the odlparent
> karaf, but with a grep am seeing that there is (a lot) of logback related
> stuff in controller...
>
>
>> Michael, can you spare some time to cook up a patch?
>>
>
> sure, but full disclosure: I've no idea what I'm doing here, I just went
> in with a chainsaw, and:
>
> https://git.opendaylight.org/gerrit/#/c/60833/
>
> https://git.opendaylight.org/gerrit/#/c/60830/
>
>
>> Thanks,
>> Robert
>>
>>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [sfc-dev] ODL Boron for Load Balancer Scenaio

[Ryan Goulding]

Highly doubtful anyone is maintaining it;  if you look at the top of the
page there is a big warning message:

"This content was created for the Hydrogen release and is out-of-date and
is considered deprecated. It is unlikely to be updated in the future
either. Information here should be taken with that in mind."

Hydrogen was the first release of ODL and a lot has changed since those
times.

Regards,

Ryan Goulding

On Mon, Jul 17, 2017 at 6:52 AM, Jaime Caamaño Ruiz <
jaime.caamano.r...@ericsson.com> wrote:

> Hello Rahul
>
> The load balancer you reference seems to be an old ODL controller
> sample application that might no longer be available. Copying
> controller-dev in case anyone there can contribute.
>
> BR
> Jaime.
>
>
> On jue, 2017-07-13 at 03:35 +0530, Rahul Hada wrote:
> > Hi Brady,
> >
> > Thanks for the reply.
> >
> > I am basically looking for implementing the group table flow rules
> > which
> > could be taken care by the LbaaS with mininet.
> > I have found the reference doc for the ODL Hydrogen (
> > https://wiki.opendaylight.org/view/OpenDaylight_Controller:Load_Balan
> > cer_Service
> > ) and didn't find the reference doc for the Boron.
> >
> > Can you please tell me a way to execute the curl for Load Balancer
> > service
> > for Boron release?
> >
> > Again thanks for the quick response.
> >
> > With Best Regards,
> >
> > Rahul Hada
> >
> > On Thu, Jul 13, 2017 at 3:00 AM, Brady Johnson <bradyallenjohnson@gma
> > il.com>
> > wrote:
> >
> > >
> > > Rahul,
> > >
> > > I added the sfc-dev list so others can contribute to this topic
> > > too.
> > >
> > > Which sort of load balancing scenario are you referring to? There
> > > was talk
> > > about implementing load balancing across SFs in carbon, but it was
> > > never
> > > started.
> > >
> > > The Boron dev cycle is complete, and so is carbon. We're on
> > > nitrogen now,
> > > which should complete in September. So any work on this would have
> > > to be in
> > > nitrogen.
> > >
> > > Regards,
> > >
> > > Brady
> > >
> > > On Wed, Jul 12, 2017, 19:49 Rahul Hada <rahul.hada@criterionnetwork
> > > s.com>
> > > wrote:
> > >
> > > >
> > > > Hi Brady,
> > > >
> > > > Can you please let me know is Load Balancer scenario with mininet
> > > > can be
> > > > implemented with ODL Boron release?
> > > >
> > > > As I have gone through the mail archive and it says that its
> > > > still in the
> > > > progress state.
> > > >
> > > > With Best Regards,
> > > >
> > > >
> > > > Rahul Hada
> > > >
> > > >
> > ___
> > sfc-dev mailing list
> > sfc-...@lists.opendaylight.org
> > https://lists.opendaylight.org/mailman/listinfo/sfc-dev
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] 401 unauthorized error for a new proect

[Ryan Goulding]

Ack... I agree and can sympathize with the pain behind doing major version
upgrades of products.  I have spent several weekends migrating this
software in my lifetime :), and I am sure others on here have too.

Most downstream vendors I have worked for maintain a self-supported
stability branch to do releases past what is supported upstream, but I do
want to point out that staying as up to date as possible is best suggested
practice.



Regards,

Ryan Goulding

On Wed, Jul 5, 2017 at 11:03 AM, Giles Heron <giles.he...@gmail.com> wrote:

> Well yeah - depends on what “supported” means.Most SP customers tend
> to deploy on the most stable release of any given platform that they can
> find (of those which have the features they need), and don’t tend to
> upgrade for a while (where “a while” may be years).
>
> so I’d expect any vendors offering commercial ODL distros to be very much
> supporting Boron at this stage - even if there will never be another SR.
> And yes - I’d hope in the open-source world that we still answer queries
> and still occasionally merge into stable/boron.
>
> at any rate it’s probably time I updated all my postman collections etc.
> to Carbon - the key pain-point there is the deprecation of the config API
> for BGP in favour of OpenConfig.
>
> On 5 Jul 2017, at 15:55, Ryan Goulding <ryandgould...@gmail.com> wrote:
>
> Unless you just mean answering questions/inquiries, in which case I 100%
> agree with you!
>
> Regards,
>
> Ryan Goulding
>
> On Wed, Jul 5, 2017 at 10:51 AM, Ryan Goulding <ryandgould...@gmail.com>
> wrote:
>
>> How do you propose support would be handled?  There are no scheduled or
>> planned releases for ODL Boron ever again, and anything merged to
>> stable/boron will never be realized in an upstream release barring an
>> emergency security release.  For all intents and purposes it is cooked...
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> On Wed, Jul 5, 2017 at 10:45 AM, Giles Heron <giles.he...@gmail.com>
>> wrote:
>>
>>> Not sure I’d define “last service release” as “now unsupported” :)
>>>
>>> On 5 Jul 2017, at 15:21, Ryan Goulding <ryandgould...@gmail.com> wrote:
>>>
>>> The last service release occurred [0].  Not sure I agree about Carbon
>>> being less stable, but to each his own ;).
>>>
>>> Regards,
>>>
>>> Ryan Goulding
>>>
>>> [0] https://wiki.opendaylight.org/view/Simultaneous_Release:
>>> Boron_Release_Plan
>>>
>>> On Wed, Jul 5, 2017 at 10:19 AM, Giles Heron <giles.he...@gmail.com>
>>> wrote:
>>>
>>>> Is that correct re Boron being unsupported?  In my experience Boron-SR3
>>>> was always pretty stable (more so than Carbon) so I’d be reluctant to move
>>>> off.
>>>>
>>>> On 5 Jul 2017, at 15:10, Ryan Goulding <ryandgould...@gmail.com> wrote:
>>>>
>>>> In particular, we added these three changes which stabilized loading
>>>> behavior in Boron-SR1:
>>>>
>>>> * 77ab012 2016-08-10 | Bug 6425: Move aaa-mdsal-store bundle to use
>>>> blueprint [Mohamed El-Serngawy]
>>>> * aa75018 2016-08-05 | Bug 6424: move aaa-idmlight to use blueprint
>>>> [melserngawy]
>>>> * b043d79 2016-08-04 | Move aaa-h2-store bundle to use blueprint
>>>> [melserngawy]
>>>>
>>>> HTH.
>>>>
>>>> Regards,
>>>>
>>>> Ryan Goulding
>>>>
>>>> On Wed, Jul 5, 2017 at 10:00 AM, Ryan Goulding <ryandgould...@gmail.com
>>>> > wrote:
>>>>
>>>>> Suspecting that might be Shiro problem, I tried to disable it at 
>>>>> etc/shiro.ini
>>>>>> however now Im getting 503 errors.
>>>>>
>>>>>
>>>>> How did you try to disable?  There were some known loading issues but
>>>>> 0.4.0.Boron is quite old.  In fact Boron is no longer in support at all.
>>>>> I'd recommend using Carbon.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Ryan Goulding
>>>>>
>>>>> On Mon, Jul 3, 2017 at 4:35 AM, Bijan R.Rofoee <
>>>>> bijan.r.rof...@gmail.com> wrote:
>>>>>
>>>>>> Hi all
>>>>>>
>>>>>> I have built a project using base architype plus netconf and bgp. The
>>>>>> project installs and have no errors, however when trying to access any of
>>>>>> the services I get 401 error(prin

Re: [controller-dev] 401 unauthorized error for a new proect

[Ryan Goulding]

Unless you just mean answering questions/inquiries, in which case I 100%
agree with you!

Regards,

Ryan Goulding

On Wed, Jul 5, 2017 at 10:51 AM, Ryan Goulding <ryandgould...@gmail.com>
wrote:

> How do you propose support would be handled?  There are no scheduled or
> planned releases for ODL Boron ever again, and anything merged to
> stable/boron will never be realized in an upstream release barring an
> emergency security release.  For all intents and purposes it is cooked...
>
> Regards,
>
> Ryan Goulding
>
> On Wed, Jul 5, 2017 at 10:45 AM, Giles Heron <giles.he...@gmail.com>
> wrote:
>
>> Not sure I’d define “last service release” as “now unsupported” :)
>>
>> On 5 Jul 2017, at 15:21, Ryan Goulding <ryandgould...@gmail.com> wrote:
>>
>> The last service release occurred [0].  Not sure I agree about Carbon
>> being less stable, but to each his own ;).
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://wiki.opendaylight.org/view/Simultaneous_Release:
>> Boron_Release_Plan
>>
>> On Wed, Jul 5, 2017 at 10:19 AM, Giles Heron <giles.he...@gmail.com>
>> wrote:
>>
>>> Is that correct re Boron being unsupported?  In my experience Boron-SR3
>>> was always pretty stable (more so than Carbon) so I’d be reluctant to move
>>> off.
>>>
>>> On 5 Jul 2017, at 15:10, Ryan Goulding <ryandgould...@gmail.com> wrote:
>>>
>>> In particular, we added these three changes which stabilized loading
>>> behavior in Boron-SR1:
>>>
>>> * 77ab012 2016-08-10 | Bug 6425: Move aaa-mdsal-store bundle to use
>>> blueprint [Mohamed El-Serngawy]
>>> * aa75018 2016-08-05 | Bug 6424: move aaa-idmlight to use blueprint
>>> [melserngawy]
>>> * b043d79 2016-08-04 | Move aaa-h2-store bundle to use blueprint
>>> [melserngawy]
>>>
>>> HTH.
>>>
>>> Regards,
>>>
>>> Ryan Goulding
>>>
>>> On Wed, Jul 5, 2017 at 10:00 AM, Ryan Goulding <ryandgould...@gmail.com>
>>> wrote:
>>>
>>>> Suspecting that might be Shiro problem, I tried to disable it at 
>>>> etc/shiro.ini
>>>>> however now Im getting 503 errors.
>>>>
>>>>
>>>> How did you try to disable?  There were some known loading issues but
>>>> 0.4.0.Boron is quite old.  In fact Boron is no longer in support at all.
>>>> I'd recommend using Carbon.
>>>>
>>>> Regards,
>>>>
>>>> Ryan Goulding
>>>>
>>>> On Mon, Jul 3, 2017 at 4:35 AM, Bijan R.Rofoee <
>>>> bijan.r.rof...@gmail.com> wrote:
>>>>
>>>>> Hi all
>>>>>
>>>>> I have built a project using base architype plus netconf and bgp. The
>>>>> project installs and have no errors, however when trying to access any of
>>>>> the services I get 401 error(printed below this email).
>>>>>
>>>>> Suspecting that might be Shiro problem, I tried to disable it at 
>>>>> etc/shiro.ini
>>>>> however now Im getting 503 errors.
>>>>>
>>>>> Any helps on this would be appreciated
>>>>>
>>>>> Regards
>>>>>
>>>>> *2017-07-03 09:26:56,633 | DEBUG | qtp1555942221-98 | TokenAuthRealm
>>>>> | 331 - org.opendaylight.aaa.shiro - 0.4.0.Boron | Unknown
>>>>> OAuth2 Token Access Request*
>>>>>
>>>>> *org.apache.shiro.authc.AuthenticationException: Could not validate
>>>>> the token admin*
>>>>>
>>>>> * at
>>>>> org.opendaylight.aaa.shiro.realm.TokenAuthRealm.validate(TokenAuthRealm.java:268)[331:org.opendaylight.aaa.shiro:0.4.0.Boron]*
>>>>>
>>>>> * at
>>>>> org.opendaylight.aaa.shiro.realm.TokenAuthRealm.doGetAuthenticationInfo(TokenAuthRealm.java:252)[331:org.opendaylight.aaa.shiro:0.4.0.Boron]*
>>>>>
>>>>> * at
>>>>> org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo(AuthenticatingRealm.java:568)[332:org.apache.shiro.core:1.2.5]*
>>>>>
>>>>> * at
>>>>> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doSingleRealmAuthentication(ModularRealmAuthenticator.java:180)[332:org.apache.shiro.core:1.2.5]*
>>>>>
>>>>> * at
>>>>> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:267)[33

Re: [controller-dev] 401 unauthorized error for a new proect

[Ryan Goulding]

How do you propose support would be handled?  There are no scheduled or
planned releases for ODL Boron ever again, and anything merged to
stable/boron will never be realized in an upstream release barring an
emergency security release.  For all intents and purposes it is cooked...

Regards,

Ryan Goulding

On Wed, Jul 5, 2017 at 10:45 AM, Giles Heron <giles.he...@gmail.com> wrote:

> Not sure I’d define “last service release” as “now unsupported” :)
>
> On 5 Jul 2017, at 15:21, Ryan Goulding <ryandgould...@gmail.com> wrote:
>
> The last service release occurred [0].  Not sure I agree about Carbon
> being less stable, but to each his own ;).
>
> Regards,
>
> Ryan Goulding
>
> [0] https://wiki.opendaylight.org/view/Simultaneous_Release:
> Boron_Release_Plan
>
> On Wed, Jul 5, 2017 at 10:19 AM, Giles Heron <giles.he...@gmail.com>
> wrote:
>
>> Is that correct re Boron being unsupported?  In my experience Boron-SR3
>> was always pretty stable (more so than Carbon) so I’d be reluctant to move
>> off.
>>
>> On 5 Jul 2017, at 15:10, Ryan Goulding <ryandgould...@gmail.com> wrote:
>>
>> In particular, we added these three changes which stabilized loading
>> behavior in Boron-SR1:
>>
>> * 77ab012 2016-08-10 | Bug 6425: Move aaa-mdsal-store bundle to use
>> blueprint [Mohamed El-Serngawy]
>> * aa75018 2016-08-05 | Bug 6424: move aaa-idmlight to use blueprint
>> [melserngawy]
>> * b043d79 2016-08-04 | Move aaa-h2-store bundle to use blueprint
>> [melserngawy]
>>
>> HTH.
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> On Wed, Jul 5, 2017 at 10:00 AM, Ryan Goulding <ryandgould...@gmail.com>
>> wrote:
>>
>>> Suspecting that might be Shiro problem, I tried to disable it at 
>>> etc/shiro.ini
>>>> however now Im getting 503 errors.
>>>
>>>
>>> How did you try to disable?  There were some known loading issues but
>>> 0.4.0.Boron is quite old.  In fact Boron is no longer in support at all.
>>> I'd recommend using Carbon.
>>>
>>> Regards,
>>>
>>> Ryan Goulding
>>>
>>> On Mon, Jul 3, 2017 at 4:35 AM, Bijan R.Rofoee <bijan.r.rof...@gmail.com
>>> > wrote:
>>>
>>>> Hi all
>>>>
>>>> I have built a project using base architype plus netconf and bgp. The
>>>> project installs and have no errors, however when trying to access any of
>>>> the services I get 401 error(printed below this email).
>>>>
>>>> Suspecting that might be Shiro problem, I tried to disable it at 
>>>> etc/shiro.ini
>>>> however now Im getting 503 errors.
>>>>
>>>> Any helps on this would be appreciated
>>>>
>>>> Regards
>>>>
>>>> *2017-07-03 09:26:56,633 | DEBUG | qtp1555942221-98 | TokenAuthRealm
>>>> | 331 - org.opendaylight.aaa.shiro - 0.4.0.Boron | Unknown
>>>> OAuth2 Token Access Request*
>>>>
>>>> *org.apache.shiro.authc.AuthenticationException: Could not validate the
>>>> token admin*
>>>>
>>>> * at
>>>> org.opendaylight.aaa.shiro.realm.TokenAuthRealm.validate(TokenAuthRealm.java:268)[331:org.opendaylight.aaa.shiro:0.4.0.Boron]*
>>>>
>>>> * at
>>>> org.opendaylight.aaa.shiro.realm.TokenAuthRealm.doGetAuthenticationInfo(TokenAuthRealm.java:252)[331:org.opendaylight.aaa.shiro:0.4.0.Boron]*
>>>>
>>>> * at
>>>> org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo(AuthenticatingRealm.java:568)[332:org.apache.shiro.core:1.2.5]*
>>>>
>>>> * at
>>>> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doSingleRealmAuthentication(ModularRealmAuthenticator.java:180)[332:org.apache.shiro.core:1.2.5]*
>>>>
>>>> * at
>>>> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:267)[332:org.apache.shiro.core:1.2.5]*
>>>>
>>>> * at
>>>> org.apache.shiro.authc.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:198)[332:org.apache.shiro.core:1.2.5]*
>>>>
>>>> * at
>>>> org.apache.shiro.mgt.AuthenticatingSecurityManager.authenticate(AuthenticatingSecurityManager.java:106)[332:org.apache.shiro.core:1.2.5]*
>>>>
>>>> * at
>>>> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:270)[332:org.apache.shiro.core:1.2.5]*
>>>>
>>>> * at
>>>> org

Re: [controller-dev] 401 unauthorized error for a new proect

[Ryan Goulding]

The last service release occurred [0].  Not sure I agree about Carbon being
less stable, but to each his own ;).

Regards,

Ryan Goulding

[0]
https://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan

On Wed, Jul 5, 2017 at 10:19 AM, Giles Heron <giles.he...@gmail.com> wrote:

> Is that correct re Boron being unsupported?  In my experience Boron-SR3
> was always pretty stable (more so than Carbon) so I’d be reluctant to move
> off.
>
> On 5 Jul 2017, at 15:10, Ryan Goulding <ryandgould...@gmail.com> wrote:
>
> In particular, we added these three changes which stabilized loading
> behavior in Boron-SR1:
>
> * 77ab012 2016-08-10 | Bug 6425: Move aaa-mdsal-store bundle to use
> blueprint [Mohamed El-Serngawy]
> * aa75018 2016-08-05 | Bug 6424: move aaa-idmlight to use blueprint
> [melserngawy]
> * b043d79 2016-08-04 | Move aaa-h2-store bundle to use blueprint
> [melserngawy]
>
> HTH.
>
> Regards,
>
> Ryan Goulding
>
> On Wed, Jul 5, 2017 at 10:00 AM, Ryan Goulding <ryandgould...@gmail.com>
> wrote:
>
>> Suspecting that might be Shiro problem, I tried to disable it at 
>> etc/shiro.ini
>>> however now Im getting 503 errors.
>>
>>
>> How did you try to disable?  There were some known loading issues but
>> 0.4.0.Boron is quite old.  In fact Boron is no longer in support at all.
>> I'd recommend using Carbon.
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> On Mon, Jul 3, 2017 at 4:35 AM, Bijan R.Rofoee <bijan.r.rof...@gmail.com>
>> wrote:
>>
>>> Hi all
>>>
>>> I have built a project using base architype plus netconf and bgp. The
>>> project installs and have no errors, however when trying to access any of
>>> the services I get 401 error(printed below this email).
>>>
>>> Suspecting that might be Shiro problem, I tried to disable it at 
>>> etc/shiro.ini
>>> however now Im getting 503 errors.
>>>
>>> Any helps on this would be appreciated
>>>
>>> Regards
>>>
>>> *2017-07-03 09:26:56,633 | DEBUG | qtp1555942221-98 | TokenAuthRealm
>>>   | 331 - org.opendaylight.aaa.shiro - 0.4.0.Boron | Unknown
>>> OAuth2 Token Access Request*
>>>
>>> *org.apache.shiro.authc.AuthenticationException: Could not validate the
>>> token admin*
>>>
>>> * at
>>> org.opendaylight.aaa.shiro.realm.TokenAuthRealm.validate(TokenAuthRealm.java:268)[331:org.opendaylight.aaa.shiro:0.4.0.Boron]*
>>>
>>> * at
>>> org.opendaylight.aaa.shiro.realm.TokenAuthRealm.doGetAuthenticationInfo(TokenAuthRealm.java:252)[331:org.opendaylight.aaa.shiro:0.4.0.Boron]*
>>>
>>> * at
>>> org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo(AuthenticatingRealm.java:568)[332:org.apache.shiro.core:1.2.5]*
>>>
>>> * at
>>> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doSingleRealmAuthentication(ModularRealmAuthenticator.java:180)[332:org.apache.shiro.core:1.2.5]*
>>>
>>> * at
>>> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:267)[332:org.apache.shiro.core:1.2.5]*
>>>
>>> * at
>>> org.apache.shiro.authc.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:198)[332:org.apache.shiro.core:1.2.5]*
>>>
>>> * at
>>> org.apache.shiro.mgt.AuthenticatingSecurityManager.authenticate(AuthenticatingSecurityManager.java:106)[332:org.apache.shiro.core:1.2.5]*
>>>
>>> * at
>>> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:270)[332:org.apache.shiro.core:1.2.5]*
>>>
>>> * at
>>> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)[332:org.apache.shiro.core:1.2.5]*
>>>
>>> * at org.apache.shiro.web.filter.au
>>> <http://org.apache.shiro.web.filter.au/>thc.AuthenticatingFilter.executeLogin(AuthenticatingFilter.java:53)[333:org.apache.shiro.web:1.2.5]*
>>>
>>> * at org.apache.shiro.web.filter.au
>>> <http://org.apache.shiro.web.filter.au/>thc.BasicHttpAuthenticationFilter.onAccessDenied(BasicHttpAuthenticationFilter.java:190)[333:org.apache.shiro.web:1.2.5]*
>>>
>>> * at org.apache.shiro.web.filter.Ac
>>> <http://org.apache.shiro.web.filter.ac/>cessControlFilter.onAccessDenied(AccessControlFilter.java:133)[333:org.apache.shiro.web:1.2.5]*
>>>
>>> * at org.apache.shiro.web.filter.Ac
>>> <http://org.apache.shiro.web.filter.ac/>cessControlFilter.onPreHandle(AccessControlFilter.ja

Re: [controller-dev] 401 unauthorized error for a new proect

[Ryan Goulding]

In particular, we added these three changes which stabilized loading
behavior in Boron-SR1:

* 77ab012 2016-08-10 | Bug 6425: Move aaa-mdsal-store bundle to use
blueprint [Mohamed El-Serngawy]
* aa75018 2016-08-05 | Bug 6424: move aaa-idmlight to use blueprint
[melserngawy]
* b043d79 2016-08-04 | Move aaa-h2-store bundle to use blueprint
[melserngawy]

HTH.

Regards,

Ryan Goulding

On Wed, Jul 5, 2017 at 10:00 AM, Ryan Goulding <ryandgould...@gmail.com>
wrote:

> Suspecting that might be Shiro problem, I tried to disable it at etc/shiro.ini
>> however now Im getting 503 errors.
>
>
> How did you try to disable?  There were some known loading issues but
> 0.4.0.Boron is quite old.  In fact Boron is no longer in support at all.
> I'd recommend using Carbon.
>
> Regards,
>
> Ryan Goulding
>
> On Mon, Jul 3, 2017 at 4:35 AM, Bijan R.Rofoee <bijan.r.rof...@gmail.com>
> wrote:
>
>> Hi all
>>
>> I have built a project using base architype plus netconf and bgp. The
>> project installs and have no errors, however when trying to access any of
>> the services I get 401 error(printed below this email).
>>
>> Suspecting that might be Shiro problem, I tried to disable it at 
>> etc/shiro.ini
>> however now Im getting 503 errors.
>>
>> Any helps on this would be appreciated
>>
>> Regards
>>
>> *2017-07-03 09:26:56,633 | DEBUG | qtp1555942221-98 | TokenAuthRealm
>>   | 331 - org.opendaylight.aaa.shiro - 0.4.0.Boron | Unknown
>> OAuth2 Token Access Request*
>>
>> *org.apache.shiro.authc.AuthenticationException: Could not validate the
>> token admin*
>>
>> * at
>> org.opendaylight.aaa.shiro.realm.TokenAuthRealm.validate(TokenAuthRealm.java:268)[331:org.opendaylight.aaa.shiro:0.4.0.Boron]*
>>
>> * at
>> org.opendaylight.aaa.shiro.realm.TokenAuthRealm.doGetAuthenticationInfo(TokenAuthRealm.java:252)[331:org.opendaylight.aaa.shiro:0.4.0.Boron]*
>>
>> * at
>> org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo(AuthenticatingRealm.java:568)[332:org.apache.shiro.core:1.2.5]*
>>
>> * at
>> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doSingleRealmAuthentication(ModularRealmAuthenticator.java:180)[332:org.apache.shiro.core:1.2.5]*
>>
>> * at
>> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:267)[332:org.apache.shiro.core:1.2.5]*
>>
>> * at
>> org.apache.shiro.authc.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:198)[332:org.apache.shiro.core:1.2.5]*
>>
>> * at
>> org.apache.shiro.mgt.AuthenticatingSecurityManager.authenticate(AuthenticatingSecurityManager.java:106)[332:org.apache.shiro.core:1.2.5]*
>>
>> * at
>> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:270)[332:org.apache.shiro.core:1.2.5]*
>>
>> * at
>> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)[332:org.apache.shiro.core:1.2.5]*
>>
>> * at org.apache.shiro.web.filter.au
>> <http://org.apache.shiro.web.filter.au>thc.AuthenticatingFilter.executeLogin(AuthenticatingFilter.java:53)[333:org.apache.shiro.web:1.2.5]*
>>
>> * at org.apache.shiro.web.filter.au
>> <http://org.apache.shiro.web.filter.au>thc.BasicHttpAuthenticationFilter.onAccessDenied(BasicHttpAuthenticationFilter.java:190)[333:org.apache.shiro.web:1.2.5]*
>>
>> * at org.apache.shiro.web.filter.Ac
>> <http://org.apache.shiro.web.filter.Ac>cessControlFilter.onAccessDenied(AccessControlFilter.java:133)[333:org.apache.shiro.web:1.2.5]*
>>
>> * at org.apache.shiro.web.filter.Ac
>> <http://org.apache.shiro.web.filter.Ac>cessControlFilter.onPreHandle(AccessControlFilter.java:162)[333:org.apache.shiro.web:1.2.5]*
>>
>> * at org.apache.shiro.web.filter.Pa
>> <http://org.apache.shiro.web.filter.Pa>thMatchingFilter.isFilterChainContinued(PathMatchingFilter.java:203)[333:org.apache.shiro.web:1.2.5]*
>>
>> * at org.apache.shiro.web.filter.Pa
>> <http://org.apache.shiro.web.filter.Pa>thMatchingFilter.preHandle(PathMatchingFilter.java:178)[333:org.apache.shiro.web:1.2.5]*
>>
>> * at
>> org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:131)[333:org.apache.shiro.web:1.2.5]*
>>
>> * at
>> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)[333:org.apache.shiro.web:1.2.5]*
>>
>> * at
>> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)[333:org.apache.shiro.web:1.2.5]*
>>
>> * at
>> org.apache.shiro.web.servlet

Re: [controller-dev] 401 unauthorized error for a new proect

[Ryan Goulding]

>
> Suspecting that might be Shiro problem, I tried to disable it at etc/shiro.ini
> however now Im getting 503 errors.


How did you try to disable?  There were some known loading issues but
0.4.0.Boron is quite old.  In fact Boron is no longer in support at all.
I'd recommend using Carbon.

Regards,

Ryan Goulding

On Mon, Jul 3, 2017 at 4:35 AM, Bijan R.Rofoee <bijan.r.rof...@gmail.com>
wrote:

> Hi all
>
> I have built a project using base architype plus netconf and bgp. The
> project installs and have no errors, however when trying to access any of
> the services I get 401 error(printed below this email).
>
> Suspecting that might be Shiro problem, I tried to disable it at etc/shiro.ini
> however now Im getting 503 errors.
>
> Any helps on this would be appreciated
>
> Regards
>
> *2017-07-03 09:26:56,633 | DEBUG | qtp1555942221-98 | TokenAuthRealm
> | 331 - org.opendaylight.aaa.shiro - 0.4.0.Boron | Unknown
> OAuth2 Token Access Request*
>
> *org.apache.shiro.authc.AuthenticationException: Could not validate the
> token admin*
>
> * at
> org.opendaylight.aaa.shiro.realm.TokenAuthRealm.validate(TokenAuthRealm.java:268)[331:org.opendaylight.aaa.shiro:0.4.0.Boron]*
>
> * at
> org.opendaylight.aaa.shiro.realm.TokenAuthRealm.doGetAuthenticationInfo(TokenAuthRealm.java:252)[331:org.opendaylight.aaa.shiro:0.4.0.Boron]*
>
> * at
> org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo(AuthenticatingRealm.java:568)[332:org.apache.shiro.core:1.2.5]*
>
> * at
> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doSingleRealmAuthentication(ModularRealmAuthenticator.java:180)[332:org.apache.shiro.core:1.2.5]*
>
> * at
> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:267)[332:org.apache.shiro.core:1.2.5]*
>
> * at
> org.apache.shiro.authc.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:198)[332:org.apache.shiro.core:1.2.5]*
>
> * at
> org.apache.shiro.mgt.AuthenticatingSecurityManager.authenticate(AuthenticatingSecurityManager.java:106)[332:org.apache.shiro.core:1.2.5]*
>
> * at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:270)[332:org.apache.shiro.core:1.2.5]*
>
> * at
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)[332:org.apache.shiro.core:1.2.5]*
>
> * at
> org.apache.shiro.web.filter.authc.AuthenticatingFilter.executeLogin(AuthenticatingFilter.java:53)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.web.filter.authc.BasicHttpAuthenticationFilter.onAccessDenied(BasicHttpAuthenticationFilter.java:190)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.web.filter.AccessControlFilter.onAccessDenied(AccessControlFilter.java:133)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.web.filter.AccessControlFilter.onPreHandle(AccessControlFilter.java:162)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.web.filter.PathMatchingFilter.isFilterChainContinued(PathMatchingFilter.java:203)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.web.filter.PathMatchingFilter.preHandle(PathMatchingFilter.java:178)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:131)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)[332:org.apache.shiro.core:1.2.5]*
>
> * at
> org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)[332:org.apache.shiro.core:1.2.5]*
>
> * at
> org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)[332:org.apache.shiro.core:1.2.5]*
>
> * at
> org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)[333:org.apache.shiro.web:1.2.5]*
>
> * at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)[227:org.eclipse.jetty.aggregate.jetty-all-server:8.1.19.v20160209]*
>
> *

Re: [controller-dev] [netconf-dev] [opendaylight-dev] [ODL | Restconf | Unable to list operations on swagger and receive DataTreeChange events]

[Ryan Goulding]

Didn’t try it… I encourage you to open an appropriate bug against MD-SAL with a 
log.

Regards,
Ryan

> On Jun 26, 2017, at 2:41 PM, Yrineu Rodrigues <yrineu.rodrig...@serro.com> 
> wrote:
> 
> Thanks all for pay attention on that.
> 
> Ryan, are you facing issues with MD-SAL events after try to evaluate a REST 
> call? I don't know if those two issues are co-related or independent.
> 
> It follows the but: 8751 <https://bugs.opendaylight.org/show_bug.cgi?id=8750> 
> (please, let me know if it's addressed correctly)
> 
> regards,
> 
> On Mon, Jun 26, 2017 at 3:30 PM, Ryan Goulding <ryandgould...@gmail.com 
> <mailto:ryandgould...@gmail.com>> wrote:
> I can confirm that I am seeing the same behavior where "show/hide" no longer 
> appears to work either.  I have opened a bug [0] for this.
> 
> Regards,
> 
> Ryan Goulding
> 
> [0] https://bugs.opendaylight.org/show_bug.cgi?id=8752 
> <https://bugs.opendaylight.org/show_bug.cgi?id=8752>
> On Mon, Jun 26, 2017 at 2:05 PM, Robert Varga <n...@hq.sk 
> <mailto:n...@hq.sk>> wrote:
> On 26/06/17 15:47, Yrineu Rodrigues wrote:
> > Hi controller-dev, odl-dev and release team,
> >
> > After update NIC to odl-parent 2.0.0, we aren't able to list operations
> > on swagger, also, I don't know that issue is related to
> > DataTreeChangeListener implementation, once we aren't receiving
> > notification for changes in tree after odl-parent 2.0.0. Please, can
> > someone help us?
> 
> I think swagger is part of netconf, +netconf-dev.
> 
> Stephen, might this have something to do with your switching to jackson?
> 
> At any rate, I think we need a BZ entry and some logs...
> 
> Regards,
> Robert
> 
> 
> ___
> netconf-dev mailing list
> netconf-...@lists.opendaylight.org <mailto:netconf-...@lists.opendaylight.org>
> https://lists.opendaylight.org/mailman/listinfo/netconf-dev 
> <https://lists.opendaylight.org/mailman/listinfo/netconf-dev>
> 
> 
> 
> 
> 
> -- 
> Yrineu Rodrigues 
> Software Engineer
> 
> SERRO
> www.serro.com <http://www.serro.com/> 
> LinkedIn • Facebook • YouTube • Vimeo • Twitter  @TeamSerro
>  
> Disclaimer: This e-mail message contains information intended solely for the 
> intended recipient and is confidential or private in nature. If you are not 
> the intended recipient, you must not read, disseminate, distribute, copy or 
> otherwise use this message or any file attached to this message. Any such 
> unauthorized use is prohibited and may be unlawful. If you have received this 
> message in error, please notify the sender immediately by email, facsimile or 
> telephone and then delete the original message from your machine.
> 
> San Francisco  |  Santa Clara  |  New York  |  Toronto  |  Mumbai  |  Pune

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

Re: [controller-dev] [netconf-dev] [opendaylight-dev] [ODL | Restconf | Unable to list operations on swagger and receive DataTreeChange events]

[Ryan Goulding]

I can confirm that I am seeing the same behavior where "show/hide" no
longer appears to work either.  I have opened a bug [0] for this.

Regards,

Ryan Goulding

[0] https://bugs.opendaylight.org/show_bug.cgi?id=8752

On Mon, Jun 26, 2017 at 2:05 PM, Robert Varga <n...@hq.sk> wrote:

> On 26/06/17 15:47, Yrineu Rodrigues wrote:
> > Hi controller-dev, odl-dev and release team,
> >
> > After update NIC to odl-parent 2.0.0, we aren't able to list operations
> > on swagger, also, I don't know that issue is related to
> > DataTreeChangeListener implementation, once we aren't receiving
> > notification for changes in tree after odl-parent 2.0.0. Please, can
> > someone help us?
>
> I think swagger is part of netconf, +netconf-dev.
>
> Stephen, might this have something to do with your switching to jackson?
>
> At any rate, I think we need a BZ entry and some logs...
>
> Regards,
> Robert
>
>
> ___
> netconf-dev mailing list
> netconf-...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/netconf-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Unable to make the call today

[Ryan Goulding]

At OpenStack summit 

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

Re: [controller-dev] mvn clean install error

[Ryan Goulding]

>
> Maven 3.3.9.


I should clarify, 3.3.9+.  I recommended 3.3.9 in particular as I haven't
had the chance to evaluate newer versions myself.  Maybe someone else can
share experiences about newer versions.

Regards,

Ryan Goulding

On Tue, May 2, 2017 at 4:21 PM, Ryan Goulding <ryandgould...@gmail.com>
wrote:

> JDK 1.7+ and Maven 3+
>
>
> You will want JDK 8 and Maven 3.3.9.
>
>  Could not find artifact org.opendaylight.odlparent:odl
>> parent-lite:pom:1.9.0-SNAPSHOT
>
>
> Strange...it appears to be in Nexus [0].  Are you using -nsu or -o?  To be
> sure I'd force an update after you ensure you have the proper JDK/Maven:
>
> > mvn clean install -U
>
> Hope this helps.
>
> Regards,
>
> Ryan Goulding
>
> [0] https://nexus.opendaylight.org/service/local/repositories/
> opendaylight.snapshot/content/org/opendaylight/odlparent/
> odlparent-lite/1.9.0-SNAPSHOT/odlparent-lite-1.9.0-20170502.005852-18.pom
>
> On Tue, May 2, 2017 at 4:00 PM, Daniel Feferman <dlfefer...@gmail.com>
> wrote:
>
>> Hi everybody,
>>
>> I'm new into opendaylight, I've just checked that I have JDK 1.7+ and
>> Maven 3+ and I'm trying to install ODL, but I'm getting the following
>> errors:
>>
>>  [INFO] Scanning for projects...
>> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
>> [FATAL] Non-resolvable parent POM for 
>> org.opendaylight.controller:releasepom:0.6.0-SNAPSHOT:
>> Could not find artifact 
>> org.opendaylight.odlparent:odlparent-lite:pom:1.9.0-SNAPSHOT
>> and 'parent.relativePath' points at no local POM @ line 4, column 11
>>  @
>> [ERROR] The build could not read 1 project -> [Help 1]
>> [ERROR]
>> [ERROR]   The project org.opendaylight.controller:releasepom:0.6.0-SNAPSHOT
>> (/home/fefer/Desktop/odl/controller/pom.xml) has 1 error
>> [ERROR] Non-resolvable parent POM for 
>> org.opendaylight.controller:releasepom:0.6.0-SNAPSHOT:
>> Could not find artifact 
>> org.opendaylight.odlparent:odlparent-lite:pom:1.9.0-SNAPSHOT
>> and 'parent.relativePath' points at no local POM @ line 4, column 11 ->
>> [Help 2]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>> -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1] http://cwiki.apache.org/conflu
>> ence/display/MAVEN/ProjectBuildingException
>> [ERROR] [Help 2] http://cwiki.apache.org/conflu
>> ence/display/MAVEN/UnresolvableModelException
>>
>> Can anyone give me a hint?
>>
>> Best regards,
>> Daniel
>>
>> ___
>> controller-dev mailing list
>> controller-dev@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>
>>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] mvn clean install error

[Ryan Goulding]

>
> JDK 1.7+ and Maven 3+


You will want JDK 8 and Maven 3.3.9.

 Could not find artifact org.opendaylight.odlparent:
> odlparent-lite:pom:1.9.0-SNAPSHOT


Strange...it appears to be in Nexus [0].  Are you using -nsu or -o?  To be
sure I'd force an update after you ensure you have the proper JDK/Maven:

> mvn clean install -U

Hope this helps.

Regards,

Ryan Goulding

[0]
https://nexus.opendaylight.org/service/local/repositories/opendaylight.snapshot/content/org/opendaylight/odlparent/odlparent-lite/1.9.0-SNAPSHOT/odlparent-lite-1.9.0-20170502.005852-18.pom

On Tue, May 2, 2017 at 4:00 PM, Daniel Feferman <dlfefer...@gmail.com>
wrote:

> Hi everybody,
>
> I'm new into opendaylight, I've just checked that I have JDK 1.7+ and
> Maven 3+ and I'm trying to install ODL, but I'm getting the following
> errors:
>
>  [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for 
> org.opendaylight.controller:releasepom:0.6.0-SNAPSHOT:
> Could not find artifact org.opendaylight.odlparent:
> odlparent-lite:pom:1.9.0-SNAPSHOT and 'parent.relativePath' points at no
> local POM @ line 4, column 11
>  @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project org.opendaylight.controller:releasepom:0.6.0-SNAPSHOT
> (/home/fefer/Desktop/odl/controller/pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM for 
> org.opendaylight.controller:releasepom:0.6.0-SNAPSHOT:
> Could not find artifact org.opendaylight.odlparent:
> odlparent-lite:pom:1.9.0-SNAPSHOT and 'parent.relativePath' points at no
> local POM @ line 4, column 11 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/
> ProjectBuildingException
> [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/
> UnresolvableModelException
>
> Can anyone give me a hint?
>
> Best regards,
> Daniel
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [Aaa-dev] [int/test] 401 from isolated cluster member?

[Ryan Goulding]

My guess is it is failing the isAccessAllowed(...) test in the
MDSALDynamicAuthorizationFilter.  Will look a bit closer.

Regards,

Ryan Goulding

On Thu, Apr 27, 2017 at 1:58 PM, Vratko Polak -X (vrpolak - PANTHEON
TECHNOLOGIES at Cisco) <vrpo...@cisco.com> wrote:

> Hello AAA devs.
>
>
>
> I have a question, originally mentioned as a comment
>
> in a Bug ... I am unable to locate right now.
>
> Anyway, it is related to various bugs
>
> such as 7792 [1] and 8209 [2].
>
> As more specific symptoms (8214 [3], 8062 [4])
>
> are fixed now, I begin to suspect the 401 status
>
> is actually expected from an isolated cluster member.
>
>
>
> I think AAA is storing some data to mdsal datastore,
>
> which is of course inaccessible on minority partition.
>
>
>
> Now, other http status codes (503) might be better,
>
> but 401 is fine as long as it gets documented.
>
>
>
> We will update suites to expect the agreed upon response.
>
>
>
> Vratko.
>
> [1] https://bugs.opendaylight.org/show_bug.cgi?id=7792
>
> [2] https://bugs.opendaylight.org/show_bug.cgi?id=8209
>
> [3] https://bugs.opendaylight.org/show_bug.cgi?id=8214
>
> [4] https://bugs.opendaylight.org/show_bug.cgi?id=8062
>
>
>
> ___
> aaa-dev mailing list
> aaa-...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [yangtools-dev] Kernel Projects Call on Bluejeans instead of WebEx from next week on

[Ryan Goulding]

+ Casey

Regards,

Ryan Goulding

On Tue, Apr 11, 2017 at 10:58 AM, Colin Dixon <co...@colindixon.com> wrote:

> I'm not going to be able to attend today—I have a conflicting internal
> meeting, but I look forward to hearing about the experience with Blue Jeans.
>
> --Colin
>
>
> On Mon, Apr 10, 2017 at 8:11 AM, Ryan Goulding <ryandgould...@gmail.com>
> wrote:
>
>> As a reminder to everyone, myself included, the meeting tomorrow will be
>> held on bluejeans instead of webex.  Please let us know if you have any
>> issues!  Thanks @MikeV for setting this up.
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> On Tue, Apr 4, 2017 at 12:05 PM, Michael Vorburger <vorbur...@redhat.com>
>> wrote:
>>
>>> Hello,
>>>
>>> re. today's Kernel Call, https://wiki.opendaylight.org/
>>> view/Kernel_Projects_Call, with many of you at ONS I was assuming it
>>> wasn't happening today?
>>>
>>> For the one in a week, do you guys want to try meeting using BlueJeans
>>> instead of WebEx, like we said last week?
>>> <https://bluejeans.com/214473479>
>>>
>>> I've just set up https://bluejeans.com/214473479 for this; Moderator
>>> Passcode to start it is 3347. Let's consider it a test and see if it works
>>> well for everyone..
>>>
>>> Tx,
>>> M.
>>> --
>>> Michael Vorburger, Red Hat
>>> vorbur...@redhat.com | IRC: vorburger @freenode | ~ =
>>> http://vorburger.ch
>>>
>>> ___
>>> yangtools-dev mailing list
>>> yangtools-...@lists.opendaylight.org
>>> https://lists.opendaylight.org/mailman/listinfo/yangtools-dev
>>>
>>>
>>
>> ___
>> controller-dev mailing list
>> controller-dev@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>
>>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] InvalidActorNameException

[Ryan Goulding]

I'd guess timing.

Sent from my iPhone

> On Apr 10, 2017, at 2:23 PM, Srini Seetharaman  
> wrote:
> 
> Ok. thanks!  Likely that is my issue. Any reason this didn't make it to Boron?
> 
>> On Mon, Apr 10, 2017 at 11:17 AM, Tom Pantelis  wrote:
>> Yes - that second patch was the final fix but didn't make Boron SR3.
>> 
>>> On Mon, Apr 10, 2017 at 1:53 PM, Srini Seetharaman 
>>>  wrote:
>>> Perhaps the second patch https://git.opendaylight.org/gerrit/#/c/53646/ was 
>>> not merged into Boron-SR3 causing my issue?
>>> 
 On Mon, Apr 10, 2017 at 10:08 AM, Srini Seetharaman 
  wrote:
 Hi Tom
 I see that you put in a fix for ODL bug 7814 and it's been merged with 
 Boron-SR3. But, I still hit that issue in my current run with Boron-SR3. 
 Is there a possibility that the issue is fixed for operational shard and 
 not config shard?
 
 
 Caused by: java.lang.Exception: Error creating READ_ONLY transaction on 
 shard default
 at 
 org.opendaylight.controller.cluster.datastore.RemoteTransactionContextSupport.createTransactionContext(RemoteTransactionContextSupport.java:224)
 ... 20 more
 Caused by: akka.actor.InvalidActorNameException: actor name 
 [shard-default-member-3:datastore-config@0:3] is not unique!
 at 
 akka.actor.dungeon.ChildrenContainer$NormalChildrenContainer.reserve(ChildrenContainer.scala:129)
 at 
 akka.actor.dungeon.Children$class.reserveChild(Children.scala:130)
 at akka.actor.ActorCell.reserveChild(ActorCell.scala:374)
 at akka.actor.dungeon.Children$class.makeChild(Children.scala:268)
 at akka.actor.dungeon.Children$class.actorOf(Children.scala:42)
 at akka.actor.ActorCell.actorOf(ActorCell.scala:374)
 at 
 org.opendaylight.controller.cluster.datastore.ShardTransactionActorFactory.newShardTransaction(ShardTransactionFactory.java:82)
 at 
 org.opendaylight.controller.cluster.datastore.Shard.createTransaction(Shard.java:520)
 at 
 org.opendaylight.controller.cluster.datastore.Shard.createTransaction(Shard.java:508)
 at 
 org.opendaylight.controller.cluster.datastore.Shard.handleCreateTransaction(Shard.java:488)
 at 
 org.opendaylight.controller.cluster.datastore.Shard.handleNonRaftCommand(Shard.java:237)
 at 
 org.opendaylight.controller.cluster.raft.RaftActor.handleCommand(RaftActor.java:291)
 at 
 org.opendaylight.controller.cluster.common.actor.AbstractUntypedPersistentActor.onReceiveCommand(AbstractUntypedPersistentActor.java:29)
 at 
 akka.persistence.UntypedPersistentActor.onReceive(PersistentActor.scala:170)
 at 
 org.opendaylight.controller.cluster.common.actor.MeteringBehavior.apply(MeteringBehavior.java:97)
 at 
 akka.actor.ActorCell$$anonfun$become$1.applyOrElse(ActorCell.scala:544)
 at akka.actor.Actor$class.aroundReceive(Actor.scala:484)
 at 
 akka.persistence.UntypedPersistentActor.akka$persistence$Eventsourced$$super$aroundReceive(PersistentActor.scala:168)
 at 
 akka.persistence.Eventsourced$$anon$1.stateReceive(Eventsourced.scala:633)
 at 
 akka.persistence.Eventsourced$class.aroundReceive(Eventsourced.scala:179)
 at 
 akka.persistence.UntypedPersistentActor.aroundReceive(PersistentActor.scala:168)
 at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)
 at akka.actor.ActorCell.invoke(ActorCell.scala:495)
 at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)
 at akka.dispatch.Mailbox.run(Mailbox.scala:224)
 at akka.dispatch.Mailbox.exec(Mailbox.scala:234)
 ... 4 more
 
 
 Thanks
 Srini.
>>> 
>> 
> 
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [yangtools-dev] Kernel Projects Call on Bluejeans instead of WebEx from next week on

[Ryan Goulding]

I've had poor experiences with blue jeans in the past, but I'm open to giving 
anything a go.  I'm sure it has improved in 3 years :).

Sent from my iPhone

> On Apr 4, 2017, at 9:05 AM, Michael Vorburger  wrote:
> 
> Hello,
> 
> re. today's Kernel Call, 
> https://wiki.opendaylight.org/view/Kernel_Projects_Call, with many of you at 
> ONS I was assuming it wasn't happening today?
> 
> For the one in a week, do you guys want to try meeting using BlueJeans 
> instead of WebEx, like we said last week?
> 
> I've just set up https://bluejeans.com/214473479 for this; Moderator Passcode 
> to start it is 3347. Let's consider it a test and see if it works well for 
> everyone..
> 
> Tx,
> M.
> --
> Michael Vorburger, Red Hat
> vorbur...@redhat.com | IRC: vorburger @freenode | ~ = http://vorburger.ch
> ___
> yangtools-dev mailing list
> yangtools-...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/yangtools-dev
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] MD-SAL Binding Generator API Change Waiver

[Ryan Goulding]

Might want to:
1) wait for the mdsal patches to get merged
2) wait for the merge jobs to complete successfully
3) then recheck the controller patch
4) then merge

I believe that is how we usually handle it...  others chime in if this is
trivial enough to remove jenkins-releng and avoid possible build
breakages.  I have no real philosophy on this one.

Regards,

Ryan Goulding

On Thu, Mar 2, 2017 at 11:41 AM, Tom Pantelis <tompante...@gmail.com> wrote:

> I added +2. What's the next step? I can remove jenkins-releng and merge
> that way.
>
> On Thu, Mar 2, 2017 at 11:35 AM, Ryan Goulding <ryandgould...@gmail.com>
> wrote:
>
>> Hi Martin,
>>
>> I reached out to Tom offline and asked him to review these changes, and
>> explained that they won't get +1 from jenkins-releng until the mdsal
>> patches are merged.  I have added +1.  After he gives his approval, please
>> coordinate the merge directly with him.
>>
>> Tom, can you please take a look at the package refactoring here?
>>
>> Thanks,
>>
>> Ryan
>>
>> On Thu, Mar 2, 2017 at 10:59 AM, Martin Ciglan -X (mciglan - PANTHEON
>> TECHNOLOGIES at Cisco) <mcig...@cisco.com> wrote:
>>
>>> Hi
>>>
>>>
>>> We've got approval from one BGPCEP representative, waiting for rest
>>> of Controller & BGPCEP commiters.
>>>
>>>
>>> Please verify & update:
>>> https://wiki.opendaylight.org/view/Simultaneous_Release/Carb
>>> on/Waiver/API/Records#MD-SAL_Binding_Generator_API_Change_Waiver
>>>
>>> Many thanks in advance
>>>
>>>
>>>   Best Regards
>>>
>>>
>>> Martin
>>>
>>> --
>>> *Od:* controller-dev-boun...@lists.opendaylight.org <
>>> controller-dev-boun...@lists.opendaylight.org> v mene používateľa Jakub
>>> Toth -X (jatoth - PANTHEON TECHNOLOGIES at Cisco)
>>> *Odoslané:* 24. februára 2017 11:21
>>> *Komu:* mdsal-...@lists.opendaylight.org; controller-dev; '
>>> rele...@lists.opendaylight.org'; d...@lists.opendaylight.org
>>> *Predmet:* [controller-dev] MD-SAL Binding Generator API Change Waiver
>>>
>>>
>>> Hi,
>>>
>>> Based on transfer of Binding generator v1 from Yangtools project to
>>> MDSAL in past, we need to finalize this process by refactoring package
>>> naming:
>>>
>>> ·org.opendaylight.yangtools -> org.mdsal.binding
>>>
>>> ·org.opendaylight.yangtools.sal -> org.mdsal.binding
>>>
>>>
>>> This refactoring is done in subsequent steps, covering all necessary
>>> modules. Based on experience, this should also help users to address
>>> possible Binding generator v1 issues in MDSAL project, not in Yangtools.
>>>
>>> Impacted project is OpenDaylight controller & BGPCEP.
>>>
>>> ·MD-SAL Binding Generator API Change Waiver
>>>
>>> o   https://wiki.opendaylight.org/view/Simultaneous_Release/Carb
>>> on/Waiver/API/Records#MD-SAL_Binding_Generator_API_Change_Waiver
>>>
>>> ·MD-SAL: Model-Driven Service Adaptation Layer
>>>
>>> o   Gerrit
>>>
>>> §  https://git.opendaylight.org/gerrit/#/c/52107
>>>
>>> §  https://git.opendaylight.org/gerrit/#/c/52108
>>>
>>> §  https://git.opendaylight.org/gerrit/#/c/52109
>>>
>>> §  https://git.opendaylight.org/gerrit/#/c/52110
>>>
>>> §  https://git.opendaylight.org/gerrit/#/c/52158
>>>
>>> o   Bug
>>>
>>> §  https://bugs.opendaylight.org/show_bug.cgi?id=6859
>>>
>>> ·OpenDaylight controller
>>>
>>>- https://git.opendaylight.org/gerrit/#/c/52170/
>>>
>>>
>>>
>>>- ​BGP/PCEP protocol library
>>>  - https://git.opendaylight.org/gerrit/#/c/52561/
>>>  - https://bugs.opendaylight.org/show_bug.cgi?id=6859
>>>  - Representative: Claudio D. Gasparini
>>>
>>>
>>>
>>> Regards,
>>>
>>> Jakub Toth
>>>
>>>
>>>
>>> [image: logo_Grey]
>>>
>>>
>>>
>>> *Jakub Toth*
>>>
>>> Engineer - Software
>>>
>>> jat...@cisco.com
>>>
>>> Tel:
>>>
>>> *Cisco Systems, Inc.*
>>>
>>>
>>>
>>>
>>> Slovakia
>>> cisco.com
>>>
>>>
>>&g

Re: [controller-dev] How to upgrade the odl when my switch is connected the controller

[Ryan Goulding]

Hi Xiaohongaifeng,

ISSU is not supported at present.

Regards,

Ryan

On Thu, Feb 23, 2017 at 8:00 PM, xiaohongaifeng 
wrote:

> Hello everyone
>I use the odl to  manage my switch flow,  and  the switch works
> well,  but right now I want to upgrade the contoller since I fix some bugs,
> you know, if I replace the JAR file, I must stop the controller and the
> switch will disconnect the odl, but I do not want the switch disconnect
> the controller, does anyone have ideas?
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] JunOS netconf problem with ODL netconf

[Ryan Goulding]

Three things:

1) The restart is needed to initiate re-parse of the yang files and schema
context assembly
2) You are mounting using an old method.  Please use [0].  Please also
consider specifying a custom schema cache so that device yang is honored
over ODL yang (just in case).
3) Please attach a log.  It is very hard to say without having access to
karaf.log.

Regards,

Ryan Goulding

[0]
https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Spawning_netconf_connectors_via_topology_configuration

On Mon, Feb 20, 2017 at 9:28 AM, Roman Mavrichev <roman.mavric...@gmail.com>
wrote:

> I got usable NETCONF ODL (0.5.2-Boron-SR2) connector with Junos (VMX
> 16.1r10).
>
> 1. Get yang model for Junos from https://forums.juniper.net/t5/
> Automation/Yang-Labs-Tools/ta-p/294320 (https://forums.juniper.net/
> jnet/attachments/jnet/Automation_Scripting/591.2/1/
> configuration-142.yang.txt)
>
> 2. Put it to cache/schema as configurat...@2014-11-13.yang
>
> 3. Restart ODL (I don`t sure what it`s really need, but I did it)
>
> 4. Use POSTMAN to add NetconfDevice (POST):
> 
>   prefix:sal-
> netconf-connector
>   PE-1
>   172.16.16.1
>   830
>   root
>   passw0rd
>   false
>   
> http://xml.juniper.net/xnm/1.1/xnm?module=configuration;
> revision=2014-11-13
> 
>   
> prefix:netty-event-executor
> global-event-executor
>   
>   
> prefix:binding-broker-osgi-registry
> binding-osgi-broker
>   
>   
> prefix:dom-broker-osgi-registry
> dom-broker
>   
>   
> prefix:netconf-client-dispatcher
> global-netconf-dispatcher
>   
>   
> prefix:threadpool
> global-netconf-processing-executor
>   
>   
> prefix:scheduled-threadpool
> global-netconf-ssh-scheduled-executor
>   
> 
>
> 4. Use POSTMAN to view Netconf topology (GET) http://192.168.5.199:8181/
> restconf/operational/network-topology:network-topology/
> topology/topology-netconf/ , device should have status "connected" with
> some capabilities like this:
> {
>   "node-id": "PE-1",
>   "netconf-node-topology:available-capabilities": {
> "available-capability": [
>   "urn:ietf:params:netconf:capability:confirmed-commit:1.0",
>   "urn:ietf:params:netconf:capability:candidate:1.0",
>   "urn:ietf:params:xml:ns:netconf:capability:confirmed-
> commit:1.0",
>   "urn:ietf:params:netconf:capability:validate:1.0",
>   "http://xml.juniper.net/netconf/junos/1.0;,
>   "urn:ietf:params:xml:ns:netconf:base:1.0",
>   "urn:ietf:params:xml:ns:netconf:capability:url:1.0?
> protocol=http,ftp,file",
>   "urn:ietf:params:netconf:base:1.0",
>   "urn:ietf:params:xml:ns:netconf:capability:validate:1.0",
>   "urn:ietf:params:xml:ns:netconf:capability:candidate:1.0",
>   "(http://xml.juniper.net/xnm/1.1/xnm?revision=2014-11-13)
> configuration",
>   "http://xml.juniper.net/dmi/system/1.0;,
>   "urn:ietf:params:netconf:capability:url:1.0?scheme=
> http,ftp,file"
> ]
>   },
>   "netconf-node-topology:host": "172.16.16.1",
>   "netconf-node-topology:unavailable-capabilities": {},
>   "netconf-node-topology:connection-status": "connected",
>   "netconf-node-topology:port": 830
> },
>
> 5. Try to get some config portion of device via REST (Use POSTMAN: GET
> http://192.168.5.199:8181/restconf/config/network-
> topology:network-topology/topology/topology-netconf/
> node/PE-1/yang-ext:mount/configuration:configuration/system/services )
> Result:
>
> {
>   "services": {
> "ssh": {
>   "protocol-version": [
> "v2"
>   ]
> },
> "netconf": {
>   "ssh": {
> "port": 830
>   }
> }
>   }
> }
>
>
> I also tried to use with ODL a newer yang models from Juniper ( available
> from https://github.com/Juniper/yang/tree/master/16.1) ,
> configuration.yang and junos-extension.yang, but withous success.
> I had put it to cache/schema, add revision strings (to filenames and also
> inside yang file), succesfull register device with ODL - but can`t get any
> config data. Sad but true.
>
> Sample:
> root@osboxes:~/odl/cache/schema# head -21 configurat...@2017-02-20.yang
> /*
>  * Copyright (c) 2016 Junip

[controller-dev] No kernel projects call today 12/27/2016

[Ryan Goulding]

Due to the holidays, there will be no call today.

Thanks,
Ryan

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

Re: [controller-dev] Question about opendaylight-karaf-empty

[Ryan Goulding]

I just wanted to raise that we have also discussed removing
opendaylight-karaf-empty altogether, which is tied to transitioning the
remaining projects over to inherit from features-parent IIRC (including the
main line integration/distribution which currently uses
opendaylight-karaf-empty).  It has been a long time since I have had time
to look at this issue, so I could be a little bit off with my description
here...

>From a Brocade standpoint, we came to grips with the fact that it is large
for now and can be improved in the future, but haven't prioritized that
work.  I also know multiple vendors (us included) inherit from
opendaylight-karaf-empty to produce our downstream distributions, so please
keep me in the loop with what is decided going forward!

Regards,

Ryan Goulding

On Mon, Dec 5, 2016 at 11:23 AM, Robert Varga <n...@hq.sk> wrote:

> On 12/05/2016 05:17 PM, Michael Vorburger wrote:
> > Does opendaylight-karaf-empty's version *HAVE* to identical to the
> > odlparent version? Why? How about odlparent/karaf has a separate
> > versioning than the rest of odlparent?
>
> Having separate versioning is fine, having a separate release cycle is
> not -- at that point it becomes a separate project and should be treated
> as such.
>
> Regards,
> Robert
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] InvalidAlgorithmParameterException during SSH key exchange

[Ryan Goulding]

Hi Vikram,

I have run into this too before.  You need to make sure you are using
bouncy castle JCE, which is described here [0].  Basically, even though the
default JCE + Unlimited Strength Policy + JDK8 "allows" for 2K DHE keys,
they do not work in Ubuntu.. no idea why.  They do work in CentOS.  I tried
copying over some of the settings to the Ubuntu from the CentOS config, but
still never got it to cough up a 2K key.  However, after enabling bouncy
castle all is well again :).

Hope this helps.

Regards,

Ryan Goulding

On Tue, Nov 22, 2016 at 9:25 AM, Vikram Darsi <vda...@advaoptical.com>
wrote:

> Hi Team
>
>
>
> We are using ODL Boron and facing below exception while SSH Key exchange
> is happening between Netconf Client (SSH Client) and Netconf based device
> (SSH Server)
>
>
>
> 1.   SSH Server is a NETCONF based device (SSH-2.0-OpenSSH_6.4)
>
> 2.   SSH Client is based on Apache Mina SSHD 0.14.0  & Mina Core
> 2.0.9 running on JAVA (1.8.0_45)  (SSH handshake failed with below
> exception)
>
> 3.   In beryllium, SSH Client is based on Apache Mina SSHD 0.12.0  &
> Mina Core 2.0.7running on JAVA (1.8.0_45) (SSH handshake is successful)
>
>
>
>
>
> java.security.InvalidAlgorithmParameterException: Prime size must be
> multiple of 64, and can only range from 512 to 2048 (inclusive)
>
> at com.sun.crypto.provider.DHKeyPairGenerator.initialize(
> DHKeyPairGenerator.java:120)[sunjce_provider.jar:1.8.0_51]
>
> at java.security.KeyPairGenerator$Delegate.
> initialize(KeyPairGenerator.java:674)[:1.8.0_45]
>
> at java.security.KeyPairGenerator.initialize(
> KeyPairGenerator.java:411)[:1.8.0_45]
>
> at org.apache.sshd.common.kex.DH.getE(DH.java:65)[31:org.
> apache.sshd.core:0.14.0]
>
> at org.apache.sshd.client.kex.
> DHGEX.next(DHGEX.java:118)[31:org.apache.sshd.core:0.14.0]
>
> at org.apache.sshd.common.session.AbstractSession.
> doHandleMessage(AbstractSession.java:425)[31:org.apache.sshd.core:0.14.0]
>
> at org.apache.sshd.common.session.AbstractSession.
> handleMessage(AbstractSession.java:326)[31:org.apache.sshd.core:0.14.0]
>
> at org.apache.sshd.client.session.ClientSessionImpl.
> handleMessage(ClientSessionImpl.java:306)[31:org.apache.sshd.core:0.14.0]
>
> at org.apache.sshd.common.session.AbstractSession.
> decode(AbstractSession.java:780)[31:org.apache.sshd.core:0.14.0]
>
> at org.apache.sshd.common.session.AbstractSession.
> messageReceived(AbstractSession.java:308)[31:org.apache.sshd.core:0.14.0]
>
> at com.adva.ensemble.controller.callhome.impl.
> ReversedAsyncSshHandler$MyAsyncSshHandlerReader.operationComplete(
> ReversedAsyncSshHandler.java:138)[286:com.adva.ensemble.
> controller.callhome-config-dispatcher:17.1.1.1]
>
> at com.adva.ensemble.controller.callhome.impl.
> ReversedAsyncSshHandler$MyAsyncSshHandlerReader.operationComplete(
> ReversedAsyncSshHandler.java:111)[286:com.adva.ensemble.
> controller.callhome-config-dispatcher:17.1.1.1]
>
> at org.apache.mina.core.future.DefaultIoFuture.
> notifyListener(DefaultIoFuture.java:375)[30:org.apache.mina.core:2.0.9]
>
> at org.apache.mina.core.future.DefaultIoFuture.
> notifyListeners(DefaultIoFuture.java:360)[30:org.apache.mina.core:2.0.9]
>
> at org.apache.mina.core.future.DefaultIoFuture.setValue(
> DefaultIoFuture.java:288)[30:org.apache.mina.core:2.0.9]
>
> at org.apache.mina.core.future.DefaultReadFuture.setRead(
> DefaultReadFuture.java:102)[30:org.apache.mina.core:2.0.9]
>
> at org.apache.mina.core.session.AbstractIoSession.
> offerReadFuture(AbstractIoSession.java:372)[30:org.apache.mina.core:2.0.9]
>
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$
> TailFilter.messageReceived(DefaultIoFilterChain.java:857)
> [30:org.apache.mina.core:2.0.9]
>
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.
> callNextMessageReceived(DefaultIoFilterChain.java:542)
> [30:org.apache.mina.core:2.0.9]
>
> at org.apache.mina.core.filterchain.
> DefaultIoFilterChain.access$1300(DefaultIoFilterChain.
> java:48)[30:org.apache.mina.core:2.0.9]
>
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$
> EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943)
> [30:org.apache.mina.core:2.0.9]
>
> at org.apache.mina.core.filterchain.IoFilterAdapter.
> messageReceived(IoFilterAdapter.java:109)[30:org.apache.mina.core:2.0.9]
>
>  

[controller-dev] No Kernel Projects Meeting Tomorrow 11/22/2016

[Ryan Goulding]

Hi All,

Due to the fact that this is a holiday for many folks, including myself,
there will be no Kernel Projects Call tomorrow, 11/22/2016.  Please feel
free to reach out via email.

Thanks & Best Regards,

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

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

[Ryan Goulding]

WRT migration of existing projects, we have a very good users guide which
Tom Pantelis put together here [0], which actually contains a migration
guide [1], for those who are attempting to make the move.  Along with the
documentation, there are a great number of patches that many folks have
worked on to migrate projects already [2].  Hopefully this helps existing
applications' contributors, both open source and proprietary, to make the
move from CSS to blueprint.

Regards,

Ryan

[0] https://wiki.opendaylight.org/view/Using_Blueprint
[1]
https://wiki.opendaylight.org/view/Using_Blueprint#Migrating_from_config_subsytem_.28CSS.29
[2] https://git.opendaylight.org/gerrit/#/q/status:merged+topic:blueprint

On Thu, Nov 17, 2016 at 8:57 AM, FREEMAN, BRIAN D <bf1...@att.com> wrote:

> I agree with Ryan that the problem is more existing applications that use
> the config system – ones that we wouldn’t normally be re-using the mvn
> archetype but have to re-factor the app to use blueprint instead of Config
> subsystem.
>
>
>
> Brian
>
>
>
>
>
> *From:* Ryan Goulding [mailto:ryandgould...@gmail.com]
> *Sent:* Thursday, November 17, 2016 8:06 AM
> *To:* Colin Dixon
> *Cc:* FREEMAN, BRIAN D; controller-dev
>
> *Subject:* Re: [controller-dev] deprecating the config subsystem in
> Carbon?
>
>
>
> You could thus deprecate the generated class: in this case
> org.opendaylight.yang.gen.v1.urn.opendaylight.lacp.lacp.main.rev141216.
> AbstractLacpMainModule
>
>
> Yeah because LCAP team modified the Module and thus copied it into src/.
> The @Deprecated generation would never traverse to this file... it would
> just be present in new generated Module(s) (in target), which is really
> only helpful to projects that:
>
> 1) don't modify the Module
> 2) are implementing a new service from scratch without using the archetype.
>
> Since the archetypes have already been modified to utilize blueprint,  I'd
> wager that most people wouldn't see any effect from making a change to the
> code generator.  Not to mention the fact that I highly doubt it would be
> "simple"... it would probably require special casing code generation for
> provider yang since I believe it utilizes the standard
> mdsal-binding-java-api-generator.
>
> Just my $0.02, someone else may have a good idea for this.  IMHO the best
> approach is to advertise this loud and clear across mailing lists and
> release notes, since most people ignore deprecated notices anyway (coming
> from someone who did the initial work to deprecate DCL, which is still used
> EVERYWHERE).
>
>
>
>
> Best Regards,
>
> Ryan
>
>
>
> On Wed, Nov 16, 2016 at 9:33 PM, Colin Dixon <co...@colindixon.com> wrote:
>
> So, even though the file is in src/ it imports a generated file, see here:
> https://github.com/opendaylight/lacp/blob/master/
> lacp-main/implementation/src/main/java/org/opendaylight/
> yang/gen/v1/urn/opendaylight/lacp/lacp/main/rev141216/
> LacpMainModule.java#L35
>
> You could thus deprecate the generated class: in this case
> org.opendaylight.yang.gen.v1.urn.opendaylight.lacp.lacp.main.rev141216.
> AbstractLacpMainModule
>
>
>
> That would work with a relatively simple change in the code generator and
> apply everywhere, right?
>
>
>
> --Colin
>
>
>
> On Wed, Nov 16, 2016 at 7:11 PM, Ryan Goulding <ryandgould...@gmail.com>
> wrote:
>
> You mean the Provider?  Most people adapt the Provider and put it in src/
> anyway;  I would guess this wouldn't really raise much awareness but that
> is my own $0.02.  The easiest path forward is probably to make sweeping
> announcements via email and strong suggestions in the release notes... but
> I could be wrong.  Open to discussion on the strategy going forward.  Tom
> Pantelis may have a clever suggestion for this too...
>
>
> Regards,
>
> Ryan Goulding
>
>
>
> On Wed, Nov 16, 2016 at 2:50 PM, Colin Dixon <co...@colindixon.com> wrote:
>
> That sounds good to me. What's the right way for us to "deprecate" the
> config subsystem. I guess the simplest thing would be add an @deprecated
> decorator to the relevant classes that get generated with a pointer to the
> docs on how to migrate.
>
> --Colin
>
>
>
> On Tue, Nov 15, 2016 at 5:07 PM, FREEMAN, BRIAN D <bf1...@att.com> wrote:
>
> I think Option 2 is a reasonable approach.
>
> Brian
>
>
>
> -Original Message-
> From: controller-dev-boun...@lists.opendaylight.org [mailto:
> controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga
> Sent: Tuesday, November 15, 2016 4:46 PM
> To: Alexis de Talhouët; thomas nadeau
> Cc: controller-dev
> Subject: Re: [control

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

[Ryan Goulding]

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


Yeah because LCAP team modified the Module and thus copied it into src/.
The @Deprecated generation would never traverse to this file... it would
just be present in new generated Module(s) (in target), which is really
only helpful to projects that:

1) don't modify the Module
2) are implementing a new service from scratch without using the archetype.

Since the archetypes have already been modified to utilize blueprint,  I'd
wager that most people wouldn't see any effect from making a change to the
code generator.  Not to mention the fact that I highly doubt it would be
"simple"... it would probably require special casing code generation for
provider yang since I believe it utilizes the standard
mdsal-binding-java-api-generator.

Just my $0.02, someone else may have a good idea for this.  IMHO the best
approach is to advertise this loud and clear across mailing lists and
release notes, since most people ignore deprecated notices anyway (coming
from someone who did the initial work to deprecate DCL, which is still used
EVERYWHERE).


Best Regards,

Ryan

On Wed, Nov 16, 2016 at 9:33 PM, Colin Dixon <co...@colindixon.com> wrote:

> So, even though the file is in src/ it imports a generated file, see here:
> https://github.com/opendaylight/lacp/blob/master/
> lacp-main/implementation/src/main/java/org/opendaylight/
> yang/gen/v1/urn/opendaylight/lacp/lacp/main/rev141216/
> LacpMainModule.java#L35
>
> You could thus deprecate the generated class: in this case
> org.opendaylight.yang.gen.v1.urn.opendaylight.lacp.lacp.main.rev141216.
> AbstractLacpMainModule
>
> That would work with a relatively simple change in the code generator and
> apply everywhere, right?
>
> --Colin
>
>
> On Wed, Nov 16, 2016 at 7:11 PM, Ryan Goulding <ryandgould...@gmail.com>
> wrote:
>
>> You mean the Provider?  Most people adapt the Provider and put it in src/
>> anyway;  I would guess this wouldn't really raise much awareness but that
>> is my own $0.02.  The easiest path forward is probably to make sweeping
>> announcements via email and strong suggestions in the release notes... but
>> I could be wrong.  Open to discussion on the strategy going forward.  Tom
>> Pantelis may have a clever suggestion for this too...
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> On Wed, Nov 16, 2016 at 2:50 PM, Colin Dixon <co...@colindixon.com>
>> wrote:
>>
>>> That sounds good to me. What's the right way for us to "deprecate" the
>>> config subsystem. I guess the simplest thing would be add an @deprecated
>>> decorator to the relevant classes that get generated with a pointer to the
>>> docs on how to migrate.
>>>
>>> --Colin
>>>
>>>
>>> On Tue, Nov 15, 2016 at 5:07 PM, FREEMAN, BRIAN D <bf1...@att.com>
>>> wrote:
>>>
>>>> I think Option 2 is a reasonable approach.
>>>>
>>>> Brian
>>>>
>>>>
>>>> -Original Message-
>>>> From: controller-dev-boun...@lists.opendaylight.org [mailto:
>>>> controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert
>>>> Varga
>>>> Sent: Tuesday, November 15, 2016 4:46 PM
>>>> To: Alexis de Talhouët; thomas nadeau
>>>> Cc: controller-dev
>>>> Subject: Re: [controller-dev] deprecating the config subsystem in
>>>> Carbon?
>>>>
>>>> On 11/15/2016 10:08 PM, Alexis de Talhouët wrote:
>>>> >
>>>> > Option 2:
>>>> > Deprecation notice in Carbon
>>>> > Adaptation in Nitrogen
>>>> > Removal in Oxygen
>>>> >
>>>> > During the kernel meeting I was more after option 3, but I think
>>>> option
>>>> > 2 make sense so downstream consumer can be notified earlier in the
>>>> > process and start migrating things to blueprint.
>>>>
>>>> I think option 2 works best, especially since we can decide on when the
>>>> actual removal takes place -- which I think should be one release after
>>>> we have shipped without internal projects using it.
>>>>
>>>> Bye,
>>>> Robert
>>>>
>>>> ___
>>>> controller-dev mailing list
>>>> controller-dev@lists.opendaylight.org
>>>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>>>
>>>
>>>
>>> ___
>>> controller-dev mailing list
>>> controller-dev@lists.opendaylight.org
>>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>>
>>>
>>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

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

[Ryan Goulding]

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

Regards,

Ryan Goulding

On Wed, Nov 16, 2016 at 2:50 PM, Colin Dixon <co...@colindixon.com> wrote:

> That sounds good to me. What's the right way for us to "deprecate" the
> config subsystem. I guess the simplest thing would be add an @deprecated
> decorator to the relevant classes that get generated with a pointer to the
> docs on how to migrate.
>
> --Colin
>
>
> On Tue, Nov 15, 2016 at 5:07 PM, FREEMAN, BRIAN D <bf1...@att.com> wrote:
>
>> I think Option 2 is a reasonable approach.
>>
>> Brian
>>
>>
>> -Original Message-
>> From: controller-dev-boun...@lists.opendaylight.org [mailto:
>> controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga
>> Sent: Tuesday, November 15, 2016 4:46 PM
>> To: Alexis de Talhouët; thomas nadeau
>> Cc: controller-dev
>> Subject: Re: [controller-dev] deprecating the config subsystem in Carbon?
>>
>> On 11/15/2016 10:08 PM, Alexis de Talhouët wrote:
>> >
>> > Option 2:
>> > Deprecation notice in Carbon
>> > Adaptation in Nitrogen
>> > Removal in Oxygen
>> >
>> > During the kernel meeting I was more after option 3, but I think option
>> > 2 make sense so downstream consumer can be notified earlier in the
>> > process and start migrating things to blueprint.
>>
>> I think option 2 works best, especially since we can decide on when the
>> actual removal takes place -- which I think should be one release after
>> we have shipped without internal projects using it.
>>
>> Bye,
>> Robert
>>
>> ___
>> controller-dev mailing list
>> controller-dev@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [release] CONTROLLER Carbon Autorelease Build Failure

[Ryan Goulding]

I'd like to point out that this is really a maintenance patch;  the
function will not change.  We simply moved the artifacts.  Functionality
shouldn't change at all.  Similar patches have been pushed to ~45 other
projects.  I tried to explain this in several emails to these projects, but
got no response.  I didn't need to take the time to submit patches to every
downstream consumer;  I did so to try to provide continuity and to not get
in trouble for busting autorelease.

We need to solve the broader issue here;  there are several projects here
that are for all intents and purposes inactive.  If a project doesn't have
someone who can respond to a needed patch, it is a security threat.  If
projects are not active, they should probably be archived.  Just my $0.02.

Thanks.

Regards,

Ryan Goulding

On Mon, Oct 31, 2016 at 1:14 PM, Thanh Ha <thanh...@linuxfoundation.org>
wrote:

> On Thu, Oct 27, 2016 at 1:05 PM, An Ho <an...@huawei.com> wrote:
>
>> Hi CONTROLLER CLUSTERING Team,
>>
>> There are Carbon Autorelease Build Failures in sal-clustering-commons.
>> Could someone from your team please take a look and confirm if the issue is
>> related to your project and if so identify an ETA for a fix?
>>
>> 00:48:33 [ERROR] Failed to execute goal 
>> org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile
>> (default-compile) on project sal-clustering-commons: Compilation failure:
>> Compilation failure:
>> 00:48:33 [ERROR] /w/workspace/autorelease-relea
>> se-carbon/controller/opendaylight/md-sal/sal-clustering-
>> commons/src/main/java/org/opendaylight/controller/
>> cluster/datastore/node/utils/stream/AbstractNormalizedNodeDataOutput.java:[11,39]
>> package edu.umd.cs.findbugs.annotations does not exist
>> 00:48:33 [ERROR] /w/workspace/autorelease-relea
>> se-carbon/controller/opendaylight/md-sal/sal-clustering-
>> commons/src/main/java/org/opendaylight/controller/
>> cluster/datastore/node/utils/stream/AbstractNormalizedNodeDataOutput.java:[365,6]
>> cannot find symbol
>> 00:48:33 [ERROR] symbol:   class SuppressFBWarnings
>> 00:48:33 [ERROR] location: class org.opendaylight.controller.cl
>> uster.datastore.node.utils.stream.AbstractNormalizedNodeDataOutput
>>
>> Best Regards,
>> An Ho
>>
>> [1] https://jenkins.opendaylight.org/releng/view/autorelease/job
>> /autorelease-release-carbon/41/consoleFull
>> [1] https://bugs.opendaylight.org/show_bug.cgi?id=7053
>>
>
> I merged I think the underlying issue is fixed with
> https://git.opendaylight.org/gerrit/47755 today so lets see if that fixes
> the build issue in tonight's build.
>
> Regards,
> Thanh
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Kernel Projects call Agenda Topics

[Ryan Goulding]

Hi All,

Please add any topics you wish to discuss during tomorrow's call here [0]
or email me and I can handle it.

Thanks,

Ryan

[0] https://wiki.opendaylight.org/view/Kernel_Projects_Call#
Upcoming_Agenda_Topics
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Stepping Down as Controller PTL, PTL Election

[Ryan Goulding]

Congrats :).  Well deserved.

Regards,

Ryan Goulding

On Thu, Oct 27, 2016 at 6:42 PM, Tom Pantelis <tompante...@gmail.com> wrote:

> So that's 3 of 5 committers voting +1, that's a majority. I'm declaring
> victory
>
> On Wed, Oct 26, 2016 at 8:24 AM, Anil Vishnoi <vishnoia...@gmail.com>
> wrote:
>
>> +1 for Tom Pantelis Nomination for PTL.
>>
>> On Tue, Oct 25, 2016 at 9:50 AM, Edward Warnicke <hagb...@gmail.com>
>> wrote:
>>
>>> +1
>>>
>>> On Thu, Oct 13, 2016 at 8:42 AM, Tom Pantelis <tompante...@gmail.com>
>>> wrote:
>>>
>>>> I'd like to nominate myself.
>>>>
>>>> Tom
>>>>
>>>> On Thu, Oct 13, 2016 at 11:35 AM, Anton Tkáčik <tony.tka...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> As you noticed for  I was not able to participate as PTL during last
>>>>> months..
>>>>> For Carbon this situation will not change, and I will be unable to
>>>>> participate as PTL for Controller project, so:
>>>>>
>>>>> - I am stepping down from role of  Controller PTL
>>>>>
>>>>> I want to open PTL nominations / election for Controller project lead.
>>>>>
>>>>> Thanks for understanding,
>>>>> Tony Tkacik
>>>>>
>>>>> ___
>>>>> controller-dev mailing list
>>>>> controller-dev@lists.opendaylight.org
>>>>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>>>>
>>>>>
>>>>
>>>> ___
>>>> controller-dev mailing list
>>>> controller-dev@lists.opendaylight.org
>>>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>>>
>>>>
>>>
>>> ___
>>> controller-dev mailing list
>>> controller-dev@lists.opendaylight.org
>>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>>
>>>
>>
>>
>> --
>> Thanks
>> Anil
>>
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Kernel Projects call Agenda Topics

[Ryan Goulding]

Hi All,

I have updated the Kernel Projects Call page to allow input of agenda items
for next Tuesday, November 1, 2016;  please feel free to start reporting
topics here [0].

Thanks,

Rya

[0]
https://wiki.opendaylight.org/view/Kernel_Projects_Call#Upcoming_Agenda_Topics
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Kernel Projects Call Upcoming Agenda Topics

[Ryan Goulding]

Hi All,

Please report any topics you wish to discuss during tomorrow's Kernel
Projects call (October, 25, 2016) here [1], or email me and I can do it for
you.

Thanks,

Ryan

[1]
https://wiki.opendaylight.org/view/Kernel_Projects_Call#Upcoming_Agenda_Topics
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Kernel Projects Call Agenda Topics

[Ryan Goulding]

Hi All,

Please add any topics you wish to discuss during today's Kernel Projects
Meeting here [0].

Thanks,

Ryan

[0]
https://wiki.opendaylight.org/view/Kernel_Projects_Call#Upcoming_Agenda_Topics
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [yangtools-dev] Yang 1.1 call

[Ryan Goulding]

Hi Viera,

Please let me know when you publish an initial draft to
wiki.opendaylight.org.  I would like to specifically add Bug 4784 (adding
copyright info to java generated files) to the release plan, which will
require yangtools and mdsal changes;  please let me know the link when it
is available so I may add this item specifically.  I have a prototype
already, but it needs some obvious work surrounding configuration which I
have discussed with Robert and folks on another thread.  This feature/bug
is very important for code static analysis, and even though it isn't Yang
1.1 specific, I believe it is very necessary and achievable in Carbon.  It
has been tracked for quite a long time, and progress has been slow (mostly
my fault admittedly).

Thanks,

Ryan Goulding

On Mon, Oct 17, 2016 at 1:24 PM, Viera Zelcamova -X (vzelcamo - PANTHEON
TECHNOLOGIES at Cisco) <vzelc...@cisco.com> wrote:

> Hi Ryan,
>
>
>
> Working on it.
>
> Yang 1.1 is our target, coming up in more details (we can start discussing
> it on Yang meetings). The bugs are created, targeted in Bugzilla, for now.
>
>
>
> Thanks.
>
>
>
> *From:* Ryan Goulding [mailto:ryandgould...@gmail.com]
> *Sent:* Monday, October 17, 2016 5:15 PM
> *To:* Alexis de Talhouët
> *Cc:* Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco); Viera
> Zelcamova -X (vzelcamo - PANTHEON TECHNOLOGIES at Cisco); Robert Varga -X
> (rovarga - PANTHEON TECHNOLOGIES at Cisco); rele...@lists.opendaylight.org;
> yangtools-dev; controller-dev
> *Subject:* Re: [yangtools-dev] [controller-dev] Yang 1.1 call
>
>
>
> Is there a draft Release Plan available for Yangtools?  M1 is Thursday and
> I'd like to see the plan.
>
>
> Regards,
>
> Ryan Goulding
>
>
>
> On Mon, Oct 17, 2016 at 10:55 AM, Alexis de Talhouët <
> adetalho...@inocybe.com> wrote:
>
> Rashmi is on PTO for two weeks, but she would agree, so by delegation,
> here is her +1.
>
>
>
> Thanks,
>
> Alexis
>
>
>
> On Oct 17, 2016, at 10:44 AM, Ryan Goulding <ryandgould...@gmail.com>
> wrote:
>
>
>
> +1 this works great for me.  Others please chime in so we can resolve this
> for next week and have our first meeting.
>
>
> Regards,
>
> Ryan Goulding
>
>
>
> On Mon, Oct 17, 2016 at 9:58 AM, Martin Ciglan -X (mciglan - PANTHEON
> TECHNOLOGIES at Cisco) <mcig...@cisco.com> wrote:
>
> ​Hi all
>
>
>
> As a first proposal, I suggest 3PM CET (1PM UTC daylight saving, it should
> be 7AM Denver, 9AM Montreal), 1 hour duration on Monday, weekly basis.
>
> It doesn't seem to collide with anything in https://wiki.opendaylight.
> org/view/Meetings
>
> I assume we should use Webex with recording feature as we always do.
>
> Please let me know your opinions.
>
>
>
>    Best Regards
>
>
>
> Martin
>
>
> --
>
> *Od:* yangtools-dev-boun...@lists.opendaylight.org  ols-dev-boun...@lists.opendaylight.org> v mene používateľa Peter Verthez <
> peter.vert...@nokia.com>
> *Odoslané:* 14. októbra 2016 13:33
> *Komu:* Ryan Goulding; Rashmi Pujar
> *Kópia:* controller-dev; Viera Zelcamova -X (vzelcamo - PANTHEON
> TECHNOLOGIES at Cisco); yangtools-dev
> *Predmet:* Re: [yangtools-dev] [controller-dev] Yang 1.1 call
>
>
>
> Hi all,
>
> Thanks for starting this discussion, because we are looking forward to the
> support of YANG 1.1 in OpenDaylight.
>
> Unfortunately we don't have resources in our company that can help in the
> development of this, but if it may help in priority setting for the
> different subtasks: the YANG 1.1 features that we're encountering in the
> IETF models, and which we have to comment out for the moment, are:
> - actions
> - use of derived-from-or-self function in when conditions
>
> The models in question are from https://datatracker.ietf.
> org/doc/draft-ietf-netmod-routing-cfg/
>
> Other people may have different priorities of course.  This is just as our
> input.
>
> We will be happy to test intermediate builds if possible.
>
> Best regards,
> Peter.
>
>
> On 14/10/2016 13:04, Ryan Goulding wrote:
>
> Thanks, Rashmi.  We will include you going forward.
>
>
>
> Martin, have you had any luck setting up a meeting time slot for this
> endeavor?  If not, I can take a stab at it based on available upstream
> meeting times derived from the meetings wiki page [0].
>
>
> Thanks,
>
> Ryan
>
>
>
> [0] https://wiki.opendaylight.org/view/Meetings
>
>
>
> On Tue, Oct 11, 2016 at 10:20 AM, Rashmi Pujar <rpu...@inocybe.com> wrote:
>
> Hi Ryan, Martin,
>
>
>
> I am interested to participate in Yang1.1 effort

Re: [controller-dev] [yangtools-dev] Yang 1.1 call

[Ryan Goulding]

Is there a draft Release Plan available for Yangtools?  M1 is Thursday and
I'd like to see the plan.

Regards,

Ryan Goulding

On Mon, Oct 17, 2016 at 10:55 AM, Alexis de Talhouët <
adetalho...@inocybe.com> wrote:

> Rashmi is on PTO for two weeks, but she would agree, so by delegation,
> here is her +1.
>
> Thanks,
> Alexis
>
> On Oct 17, 2016, at 10:44 AM, Ryan Goulding <ryandgould...@gmail.com>
> wrote:
>
> +1 this works great for me.  Others please chime in so we can resolve this
> for next week and have our first meeting.
>
> Regards,
>
> Ryan Goulding
>
> On Mon, Oct 17, 2016 at 9:58 AM, Martin Ciglan -X (mciglan - PANTHEON
> TECHNOLOGIES at Cisco) <mcig...@cisco.com> wrote:
>
>> ​Hi all
>>
>>
>> As a first proposal, I suggest 3PM CET (1PM UTC daylight saving, it
>> should be 7AM Denver, 9AM Montreal), 1 hour duration on Monday, weekly
>> basis.
>>
>> It doesn't seem to collide with anything in https://wiki.opendaylight.o
>> rg/view/Meetings
>>
>> I assume we should use Webex with recording feature as we always do.
>>
>> Please let me know your opinions.
>>
>>
>>Best Regards
>>
>>
>> Martin
>>
>>
>> --
>> *Od:* yangtools-dev-boun...@lists.opendaylight.org > ols-dev-boun...@lists.opendaylight.org> v mene používateľa Peter Verthez
>> <peter.vert...@nokia.com>
>> *Odoslané:* 14. októbra 2016 13:33
>> *Komu:* Ryan Goulding; Rashmi Pujar
>> *Kópia:* controller-dev; Viera Zelcamova -X (vzelcamo - PANTHEON
>> TECHNOLOGIES at Cisco); yangtools-dev
>> *Predmet:* Re: [yangtools-dev] [controller-dev] Yang 1.1 call
>>
>> Hi all,
>>
>> Thanks for starting this discussion, because we are looking forward to
>> the support of YANG 1.1 in OpenDaylight.
>>
>> Unfortunately we don't have resources in our company that can help in the
>> development of this, but if it may help in priority setting for the
>> different subtasks: the YANG 1.1 features that we're encountering in the
>> IETF models, and which we have to comment out for the moment, are:
>> - actions
>> - use of derived-from-or-self function in when conditions
>>
>> The models in question are from https://datatracker.ietf.
>> org/doc/draft-ietf-netmod-routing-cfg/
>>
>> Other people may have different priorities of course.  This is just as
>> our input.
>>
>> We will be happy to test intermediate builds if possible.
>>
>> Best regards,
>> Peter.
>>
>>
>> On 14/10/2016 13:04, Ryan Goulding wrote:
>>
>> Thanks, Rashmi.  We will include you going forward.
>>
>> Martin, have you had any luck setting up a meeting time slot for this
>> endeavor?  If not, I can take a stab at it based on available upstream
>> meeting times derived from the meetings wiki page [0].
>>
>> Thanks,
>>
>> Ryan
>>
>> [0] https://wiki.opendaylight.org/view/Meetings
>>
>> On Tue, Oct 11, 2016 at 10:20 AM, Rashmi Pujar <rpu...@inocybe.com> wro
>> te:
>>
>>> Hi Ryan, Martin,
>>>
>>> I am interested to participate in Yang1.1 effort. Please forward the
>>> meeting details once you have them.
>>> Is there a Trello board that I need to subscribe to or the activity is
>>> tracked on bugzilla?
>>>
>>> Thanks,
>>>
>>> On Tue, Oct 11, 2016 at 9:39 AM, Ryan Goulding <ryandgould...@gmail.com>
>>>  wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> I have included +yangtools-dev and +controller-dev in the cc list in
>>>> attempt to recruit more people for this effort :).  My main point behind
>>>> this is that these meetings should be open to the public community so we
>>>> can drive inclusion and hopefully spread the workload for this big effort.
>>>>
>>>> I am available to do work on Yang 1.1, as I stated in our last kernel
>>>> projects call.  Similar to others, I split my time on many endeavors, but
>>>> this is my main area of focus for this release.
>>>>
>>>> Please let me know where/when this call will happen.  If we need help
>>>> finding a time slot for webex, I can communicate with LF staff to set up
>>>> the appropriate tools.
>>>>
>>>> Thanks,
>>>>
>>>> Ryan
>>>>
>>>> On Tue, Oct 11, 2016 at 8:40 AM, Martin Ciglan -X (mciglan - PANTHEON
>>>> TECHNOLOGIES at Cisco) <mcig...@cisco.com> wrote:
>

Re: [controller-dev] [yangtools-dev] Yang 1.1 call

[Ryan Goulding]

+1 this works great for me.  Others please chime in so we can resolve this
for next week and have our first meeting.

Regards,

Ryan Goulding

On Mon, Oct 17, 2016 at 9:58 AM, Martin Ciglan -X (mciglan - PANTHEON
TECHNOLOGIES at Cisco) <mcig...@cisco.com> wrote:

> ​Hi all
>
>
> As a first proposal, I suggest 3PM CET (1PM UTC daylight saving, it should
> be 7AM Denver, 9AM Montreal), 1 hour duration on Monday, weekly basis.
>
> It doesn't seem to collide with anything in https://wiki.opendaylight.
> org/view/Meetings
>
> I assume we should use Webex with recording feature as we always do.
>
> Please let me know your opinions.
>
>
>Best Regards
>
>
> Martin
>
>
> --
> *Od:* yangtools-dev-boun...@lists.opendaylight.org <
> yangtools-dev-boun...@lists.opendaylight.org> v mene používateľa Peter
> Verthez <peter.vert...@nokia.com>
> *Odoslané:* 14. októbra 2016 13:33
> *Komu:* Ryan Goulding; Rashmi Pujar
> *Kópia:* controller-dev; Viera Zelcamova -X (vzelcamo - PANTHEON
> TECHNOLOGIES at Cisco); yangtools-dev
> *Predmet:* Re: [yangtools-dev] [controller-dev] Yang 1.1 call
>
> Hi all,
>
> Thanks for starting this discussion, because we are looking forward to the
> support of YANG 1.1 in OpenDaylight.
>
> Unfortunately we don't have resources in our company that can help in the
> development of this, but if it may help in priority setting for the
> different subtasks: the YANG 1.1 features that we're encountering in the
> IETF models, and which we have to comment out for the moment, are:
> - actions
> - use of derived-from-or-self function in when conditions
>
> The models in question are from https://datatracker.ietf.org/
> doc/draft-ietf-netmod-routing-cfg/
>
> Other people may have different priorities of course.  This is just as our
> input.
>
> We will be happy to test intermediate builds if possible.
>
> Best regards,
> Peter.
>
>
> On 14/10/2016 13:04, Ryan Goulding wrote:
>
> Thanks, Rashmi.  We will include you going forward.
>
> Martin, have you had any luck setting up a meeting time slot for this
> endeavor?  If not, I can take a stab at it based on available upstream
> meeting times derived from the meetings wiki page [0].
>
> Thanks,
>
> Ryan
>
> [0] https://wiki.opendaylight.org/view/Meetings
>
> On Tue, Oct 11, 2016 at 10:20 AM, Rashmi Pujar <rpu...@inocybe.com> wrote:
>
>> Hi Ryan, Martin,
>>
>> I am interested to participate in Yang1.1 effort. Please forward the
>> meeting details once you have them.
>> Is there a Trello board that I need to subscribe to or the activity is
>> tracked on bugzilla?
>>
>> Thanks,
>>
>> On Tue, Oct 11, 2016 at 9:39 AM, Ryan Goulding <ryandgould...@gmail.com>
>> wrote:
>>
>>> Hi Martin,
>>>
>>> I have included +yangtools-dev and +controller-dev in the cc list in
>>> attempt to recruit more people for this effort :).  My main point behind
>>> this is that these meetings should be open to the public community so we
>>> can drive inclusion and hopefully spread the workload for this big effort.
>>>
>>> I am available to do work on Yang 1.1, as I stated in our last kernel
>>> projects call.  Similar to others, I split my time on many endeavors, but
>>> this is my main area of focus for this release.
>>>
>>> Please let me know where/when this call will happen.  If we need help
>>> finding a time slot for webex, I can communicate with LF staff to set up
>>> the appropriate tools.
>>>
>>> Thanks,
>>>
>>> Ryan
>>>
>>> On Tue, Oct 11, 2016 at 8:40 AM, Martin Ciglan -X (mciglan - PANTHEON
>>> TECHNOLOGIES at Cisco) <mcig...@cisco.com> wrote:
>>>
>>>> Hi Colin & Ryan
>>>>
>>>>
>>>> 'Yang 1.1 meetings' is still TO DO, we should be able to come up with
>>>> more information next week.
>>>>
>>>> For time being, can you specify how many people can participate, %
>>>> commitment to be able to finish assigned bug(s), etc... ?
>>>>
>>>>
>>>> Thank you in advance.
>>>>
>>>>
>>>> Best Regards
>>>>
>>>>
>>>>   Martin
>>>>
>>>
>>>
>>> ___
>>> controller-dev mailing list
>>> controller-dev@lists.opendaylight.org
>>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>>
>>>
>>
>
>

Re: [controller-dev] Yang 1.1 call

[Ryan Goulding]

Thanks, Rashmi.  We will include you going forward.

Martin, have you had any luck setting up a meeting time slot for this
endeavor?  If not, I can take a stab at it based on available upstream
meeting times derived from the meetings wiki page [0].

Thanks,

Ryan

[0] https://wiki.opendaylight.org/view/Meetings

On Tue, Oct 11, 2016 at 10:20 AM, Rashmi Pujar <rpu...@inocybe.com> wrote:

> Hi Ryan, Martin,
>
> I am interested to participate in Yang1.1 effort. Please forward the
> meeting details once you have them.
> Is there a Trello board that I need to subscribe to or the activity is
> tracked on bugzilla?
>
> Thanks,
>
> On Tue, Oct 11, 2016 at 9:39 AM, Ryan Goulding <ryandgould...@gmail.com>
> wrote:
>
>> Hi Martin,
>>
>> I have included +yangtools-dev and +controller-dev in the cc list in
>> attempt to recruit more people for this effort :).  My main point behind
>> this is that these meetings should be open to the public community so we
>> can drive inclusion and hopefully spread the workload for this big effort.
>>
>> I am available to do work on Yang 1.1, as I stated in our last kernel
>> projects call.  Similar to others, I split my time on many endeavors, but
>> this is my main area of focus for this release.
>>
>> Please let me know where/when this call will happen.  If we need help
>> finding a time slot for webex, I can communicate with LF staff to set up
>> the appropriate tools.
>>
>> Thanks,
>>
>> Ryan
>>
>> On Tue, Oct 11, 2016 at 8:40 AM, Martin Ciglan -X (mciglan - PANTHEON
>> TECHNOLOGIES at Cisco) <mcig...@cisco.com> wrote:
>>
>>> Hi Colin & Ryan
>>>
>>>
>>> 'Yang 1.1 meetings' is still TO DO, we should be able to come up with
>>> more information next week.
>>>
>>> For time being, can you specify how many people can participate, %
>>> commitment to be able to finish assigned bug(s), etc... ?
>>>
>>>
>>> Thank you in advance.
>>>
>>>
>>> Best Regards
>>>
>>>
>>>   Martin
>>>
>>
>>
>> ___
>> controller-dev mailing list
>> controller-dev@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>>
>>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Yang 1.1 call

[Ryan Goulding]

Hi Martin,

I have included +yangtools-dev and +controller-dev in the cc list in
attempt to recruit more people for this effort :).  My main point behind
this is that these meetings should be open to the public community so we
can drive inclusion and hopefully spread the workload for this big effort.

I am available to do work on Yang 1.1, as I stated in our last kernel
projects call.  Similar to others, I split my time on many endeavors, but
this is my main area of focus for this release.

Please let me know where/when this call will happen.  If we need help
finding a time slot for webex, I can communicate with LF staff to set up
the appropriate tools.

Thanks,

Ryan

On Tue, Oct 11, 2016 at 8:40 AM, Martin Ciglan -X (mciglan - PANTHEON
TECHNOLOGIES at Cisco)  wrote:

> Hi Colin & Ryan
>
>
> 'Yang 1.1 meetings' is still TO DO, we should be able to come up with
> more information next week.
>
> For time being, can you specify how many people can participate, %
> commitment to be able to finish assigned bug(s), etc... ?
>
>
> Thank you in advance.
>
>
> Best Regards
>
>
>   Martin
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Kernel Projects Call Meeting Agenda

[Ryan Goulding]

Hi All,

Please report any topics you wish to discuss in what is now being called
the "Kernel Projects Call" to the upcoming agenda [1], or email me and I
can do it for you.

Thanks,

Ryan

[1]
https://wiki.opendaylight.org/view/Kernel_Projects_Call#Upcoming_Agenda_Topics
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Core Projects Call Weekly Meeting Cancelled 9/27/2016

[Ryan Goulding]

+controller-dev for exposure.

Regards,

Ryan Goulding

On Fri, Sep 23, 2016 at 10:16 AM, Ryan Goulding <ryandgould...@gmail.com>
wrote:

> Hi All,
>
> The Core Projects call is cancelled for 9/27/2016 in order to allow people
> to concentrate on ODL Summit activities.  Please continue to use the
> mailing lists to communicate any pressing issues!
>
> Thanks,
>
> Ryan
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Core Projects Meeting Agenda Topics

[Ryan Goulding]

As an aside, Colin will be leading the call today.  I currently have
flooring contractors replacing flooring, which is causing too much noise to
play a useful role today.  I will still join the call but will have limited
audio access;  sorry for any inconveniences.

Regards,

Ryan

On Tue, Sep 20, 2016 at 9:47 AM, Ryan Goulding <ryandgould...@gmail.com>
wrote:

> Hi All,
>
> Please add your topics for today's core projects meeting here [1] or email
> me and I will do so.
>
> Regards,
>
> Ryan
>
> [1] https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Core Projects Meeting Agenda Topics

[Ryan Goulding]

Hi All,

Please add your topics for today's core projects meeting here [1] or email
me and I will do so.

Regards,

Ryan

[1] https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Core Projects Meeting Agenda Topics

[Ryan Goulding]

Additionally, I have discovered (albeit later than most) that many Carbon
DDF topics are being tracked here [1].  Thanks, Stephen!

Regards,

Ryan Goulding

On Mon, Sep 12, 2016 at 8:54 AM, Ryan Goulding <ryandgould...@gmail.com>
wrote:

> Hi All,
>
> Please report any topics you wish to discuss during tomorrow's meeting
> here [1].  I believe we should likely start talking about Carbon planning
> and iron out some possible topics for discussion during DDF.
>
> Thanks,
>
> Ryan
>
> [1] https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#
> Upcoming_Agenda_Topics
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] config subsystem question

[Ryan Goulding]

Once upon a time this implied ordering;  thats not how it works anymore
though.  The numbers are there mostly as a result of history.

HTH!

Regards,

Ryan Goulding

On Wed, Sep 7, 2016 at 8:55 PM, xiaohongaifeng <xiaohongaiw...@163.com>
wrote:

>  hi all:
>
>   Do you know what is the 00 number in the "00-netty.xml" represent for?  
> I see there are some config files such
> as 00-netty.xml 01-md-sal.xml 05-clustering.xml in the 
> /etc/opendaylight/karaf folder, but I don't know what the number in
> the prefix of file name means ?  Does it represent the module startup order? 
> can you give me some explanations on wiki， thanks！
>
>
>
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] Core Projects Call Agenda Topics

[Ryan Goulding]

Hi All,

Please report any topics you want to discuss during today's core projects
call here [1] or email me and I will.  As a reminder, please continue to
file bugs for any issues that may be classified as release blockers, so we
can get appropriate attention on them as soon as possible!

Thanks,

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

[controller-dev] Core Projects Weekly Call Agenda Topics

[Ryan Goulding]

Hi All,

Please report any topics you wish to discuss to the agenda tracker [1], or
email me and I will.

Thanks,

Ryan

[1]
https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Upcoming_Agenda_Topics
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev