[controller-dev] 401 unauthorized error for a new proect
|
Michael Vorburger <vorburger@...>
+aaa-dev, if any AAAs would like to offer support for this:
On Mon, Jul 3, 2017 at 10:35 AM, Bijan R.Rofoee <bijan.r.rofoee@...> wrote:
|
|
|
|
Ryan Goulding <ryandgoulding@...>
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.rofoee@...> wrote:
|
|
|
|
Ryan Goulding <ryandgoulding@...>
In particular, we added these three changes which stabilized loading behavior in Boron-SR1: HTH.* 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] Regards, Ryan Goulding
On Wed, Jul 5, 2017 at 10:00 AM, Ryan Goulding <ryandgoulding@...> wrote:
|
|
|
|
Giles Heron <giles.heron@...>
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.
toggle quoted messageShow quoted text
|
|
|
|
Ryan Goulding <ryandgoulding@...>
The last service release occurred [0]. Not sure I agree about Carbon being less stable, but to each his own ;).
On Wed, Jul 5, 2017 at 10:19 AM, Giles Heron <giles.heron@...> wrote:
|
|
|
|
Bijan R.Rofoee <bijan.r.rofoee@...>
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 <ryandgoulding@...> wrote:
|
|
|
|
Ryan Goulding <ryandgoulding@...>
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:38 AM, Bijan R.Rofoee <bijan.r.rofoee@...> wrote:
|
|
|
|
Giles Heron <giles.heron@...>
Not sure I’d define “last service release” as “now unsupported” :)
toggle quoted messageShow quoted text
|
|
|
|
Ryan Goulding <ryandgoulding@...>
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.heron@...> wrote:
|
|
|
|
Ryan Goulding <ryandgoulding@...>
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 <ryandgoulding@...> wrote:
|
|
|
|
Giles Heron <giles.heron@...>
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).
toggle quoted messageShow quoted text
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.
|
|
|
|
Ryan Goulding <ryandgoulding@...>
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.heron@...> wrote:
|
|
|
|
Bijan R.Rofoee <bijan.r.rofoee@...>
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 opensource more plausible. Regards Bijan
On 5 July 2017 at 16:13, Ryan Goulding <ryandgoulding@...> wrote:
|
|
|
|
FREEMAN, BRIAN D <bf1936@...>
+1 :)
From: controller-dev-bounces@... [mailto:controller-dev-bounces@...]
On Behalf Of Bijan R.Rofoee
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 opensource more plausible. Regards Bijan
On 5 July 2017 at 16:13, Ryan Goulding <ryandgoulding@...> wrote:
|
|
|
|
Ryan Goulding <ryandgoulding@...>
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:03 AM, Giles Heron <giles.heron@...> wrote:
|
|
|
|
Tom Pantelis
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 <ryandgoulding@...> wrote:
|
|
|
|
Giles Heron <giles.heron@...>
They’re all in https://github.com/CiscoDevNet/opendaylight-sample-apps (under postman-collections)
toggle quoted messageShow quoted text
so yeah - I need to do a major upgrade to get it all Nitrogen-ready. Might change one or two more literals to environment vars too. Giles
|
|
|
|
Colin Dixon <colin@...>
I'm on PTO at the moment, so I'll read through this in some more detail later, but wanted to chime in now to say that the TSC agreed a long time ago to support bug fixes in service releases for the previous release, e.g., Carbon while working toward releasing Nitrogen, and then off-cycle releases for security issues as needed for the privous two releases, e.g., Boron and Carbon while working toward releasing Nitrogen. This isn't a limit saying that we can'd do other things or that we can't still support them by helping with questions, but it's a statement of the minimum level of support we agree to provide to our releases. That being said, we have typically not had the gratuitious resources to provide heavy support for older releases and typically the community has had waning interest in fixing issues in releases older that 1-2 back. That being said, we're maturing as a community and platform, so the massive differences between releases have been somewhat less pronounced recently. We could re-evaluate it if need be. --Colin
On Wed, Jul 5, 2017 at 10:45 AM Giles Heron <giles.heron@...> wrote:
|
|
|