Thanks Tom.
-Karthik
From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Wednesday, July 5, 2017 09:47 PM
To: Karthik Rajagopalan
Cc: controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] Cohorts not being triggered on reboot of server,
only DataTreeChangeListeners are trigger
Also don't forget to update any collections using the CSS netconf connector
- https://git.opendaylight.org/gerrit/#/c/59669/ will finally nix it in
Nitrogen :)
On Wed, Jul 5, 2017 at 3:55 PM, Ryan Goulding
wrote:
> at any rate it’s probably time I updated all my postman collections etc.
>> to Ca
>
> 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.
Any chance you are putting these in a public location? :)
Regards,
Ryan Goulding
On Wed, Jul 5, 2017 at 11
On Wed, Jul 5, 2017 at 10:07 AM, Karthik Rajagopalan <
krajagopa...@advaoptical.com> wrote:
> Controller after boot up triggers registered
> DataTreeChangeListeners, but doesn’t triggered the cohorts.
>
> Is this expected behaviour
>
yes - commit cohorts are triggered when
Yrineu has pushed [0] to fix this. I compiled locally and verified it
works properly for me, and I can again list operations. NETCONF
committers, can we get this merged?
Regards,
Ryan Goulding
[0] https://git.opendaylight.org/gerrit/59804
On Mon, Jun 26, 2017 at 5:58 PM, Stephen Kitt wrote:
+1 :)
From: controller-dev-boun...@lists.opendaylight.org
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Bijan
R.Rofoee
Sent: Wednesday, July 05, 2017 11:28 AM
To: Ryan Goulding
Cc: aaa-...@lists.opendaylight.org; controller-dev@lists.opendaylight.org
Subject: Re: [controll
I would also see a case for longer EOL from the community for recent
releases, migration to the newest versions is best for agile dev ecosystems
whilst ODL is for operators which are not agile as such (yet) by nature and
stability and longer support is what makes making business cases based on
open
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
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 of
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
wrote:
> How do you propose support would be handled? There are no scheduled or
> planned releases for ODL Boron ever again, and anyth
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 G
Not sure I’d define “last service release” as “now unsupported” :)
> On 5 Jul 2017, at 15:21, Ryan Goulding 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.ope
Glad to hear things worked. In general, you should not mix versions in
Boron or Carbon (i.e., stick with one version). In more modern releases
that won't exactly be true as we transition to using released artifacts
instead of SNAPSHOT artifacts.
Regards,
Ryan Goulding
On Wed, Jul 5, 2017 at 10
Thanks all
So I reverted back to Boron "0", and the problem is resolved. From my blind
experiment It appeared as when adding dluxapps next to dlux in the
features.xml in Boron SR3 the 401 started to appear.
Regards
Bijan
On 5 July 2017 at 15:21, Ryan Goulding wrote:
> The last service release
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 wrote:
> Is that correct re Boron
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 wrote:
>
> In particular, we added these three changes which stabilized loading behavior
> in Boron-S
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 | M
Controller after boot up triggers registered
DataTreeChangeListeners, but doesn't triggered the cohorts.
Is this expected behaviour
Regards,
Karthik
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://l
>
> 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.
Regar
+aaa-dev, if any AAAs would like to offer support for this:
Tx,
M.
--
Michael Vorburger, Red Hat
vorbur...@redhat.com | IRC: vorburger @freenode | ~ = http://vorburger.ch
On Mon, Jul 3, 2017 at 10:35 AM, Bijan R.Rofoee
wrote:
> Hi all
>
> I have built a project using base architype plus netcon
Hi Team,
A problem about yang current() confuses me.Could anyone help me to understand
the difference between mark 1 and mark 2.Any help is respect.
21 matches
Mail list logo
