On 27/11/17 19:50, Robert Varga wrote:
> - aaa needs to fixup its IT (which is a failure related to odlparent's
> upgrade of h2, as far as I can tell)

This is not accurate, as the shiro feature is broken. This requires
someone from AAA to drive it home.

Bye,
Robert


_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release

I pulled mdsal and controller upstream changes, built, then and attempted "mvn clean install" with the AAA patch [0].  This hung SFT.  So I did a "mvn -Pq clean install" and ran karaf.  Upon trying to "feature:install odl-aaa-shiro" I got huge MultiException stacktrace ultimately caused by this:

Error executing command: Error:

Error downloading mvn:org.apache.karaf.webconsole/org.apache.karaf.webconsole.http/4.1.3

I then attempted bundle installation manually and also came up with some errors:

karaf@root()> bundle:install mvn:org.apache.karaf.webconsole/org.apache.karaf.webconsole.http/4.1.3

Bundle IDs: 

11:48:32.895 [Karaf local console user karaf] ERROR org.apache.karaf.shell.support.ShellUtil - Exception caught while executing command

org.apache.karaf.shell.support.MultiException: Error installing bundles:

Unable to install bundle mvn:org.apache.karaf.webconsole/org.apache.karaf.webconsole.http/4.1.3: org.osgi.framework.BundleException: Error reading bundle content.

Is this where you got?  I have no clue what is causing this at the moment.  Want to make sure we are at the same point though...

Regards,

Ryan Goulding

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

On Wed, Nov 29, 2017 at 12:28 PM, Robert Varga <nite@...> wrote:

On 27/11/17 19:50, Robert Varga wrote:
> - aaa needs to fixup its IT (which is a failure related to odlparent's
> upgrade of h2, as far as I can tell)

This is not accurate, as the shiro feature is broken. This requires
someone from AAA to drive it home.

Bye,
Robert

_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release

On 30/11/17 17:52, Ryan Goulding wrote:
> Is this where you got?  I have no clue what is causing this at the
> moment.  Want to make sure we are at the same point though...

Yes. I think this is two separate issues, though. The SFT failure
initially was just about javax.ws.rs not being present and being
required by jackson. Once I added that, I saw that hang.

The distro seems to be ... interesting, as the basic structure in
system/ is present, but the directories are not populated with
corresponding jars...

Regards,
Robert

On Mon, 4 Dec 2017 12:54:53 -0500
Ryan Goulding <ryandgoulding@...> wrote:
> I see the same thing.
>
> Stephen, has this happened with any other testing w/ odlparent
> 2.0.5?  When I copy jars locally, I slowly get rid of error
> messages.  That obviously isn't desirable.  I also tried to take the
> default org.ops4j.pax.url.mvn.cfg and starting (in order to download
> the missing artifacts from remote repos) but that ran into many
> issues as well.

Not with 2.0.5 AFAICT.

With 3.0.1, there’s something messed up in the feature dependency
chain, or perhaps a mixture of the build and feature dependency chain.
I get the impression kar just gives up when it can’t converge
something, instead of failing the build, resulting in the empty
directories you’re seeing. Sticking to facts, if I add explicit
dependencies to aaa-karaf, I can progressively add more dependencies in
the distribution, and get further when building and/or loading
(building, because kar does resolve the OSGi dependencies, so
non-optional dependencies need to be fulfilled correctly).

So far, I’ve got webconsole.http, webconsole, servlet-api, pax-web-spi,
pax-web-api, commons-io, xbean-finder, asm-all, xbean-bundleutils,
commons-fileupload, and I’m at karaf.scr.management which is where
everything blows up because one part of the tree needs felix.scr >= 2
and another needs felix.scr < 2.

Since Karaf 4.1.3 itself can build a fully-populated distribution
correctly, I’m guessing this is related to one of the odlparent
patches, or perhaps an invalid version in our dependency (invalid as in
conflicting with Karaf).

I’m still digging...

Regards,

Spelunky

Stephen,

Yeah, I did the more rudimentary version of downloading jars manually and sticking them in system.  I started to unravel that and ran into similar results.

We identified two issues during yesterday's Kernel Project's call.

1) system/ is not populated properly, which Stephen is working as stated in the above email. [0]

2) AAA SFT hangs.  [1] addresses the switch off jackson (fails dist-check due to the fact RESTCONF in NETCONF depended on import of some dependencies by AAA, so it will likely need a similar transition to GSON too ).  With [1] layered on the upgrade patch [2] I am still running into a terrible bundle refresh during SFT... surefire log snippet here:

Refreshing bundles:
    org.apache.aries.blueprint.cm/1.1.0 (Wired to org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
    org.apache.aries.blueprint.core/1.8.3 (Attached fragments changed: [org.apache.aries.blueprint.core.compatibility/1.0.0])
    org.apache.karaf.bundle.blueprintstate/4.1.3 (Wired to org.apache.karaf.bundle.core/4.1.3 which is being refreshed)
    org.apache.karaf.bundle.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.config.core/4.1.3 (Should be wired to: org.apache.felix.metatype/1.1.6 (through [org.apache.karaf.config.core/4.1.3] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.metatype)(version>=1.2.0)(!(version>=2.0.0)))"; resolution:=optional))
    org.apache.karaf.deployer.kar/4.1.3 (Wired to org.apache.karaf.kar.core/4.1.3 which is being refreshed)
    org.apache.karaf.diagnostic.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.features.command/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.instance.core/4.1.3 (Wired to org.apache.karaf.features.command/4.1.3 which is being refreshed)
    org.apache.karaf.jaas.blueprint.config/4.1.3 (Wired to org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
    org.apache.karaf.jaas.command/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.kar.core/4.1.3 (Wired to org.apache.karaf.features.command/4.1.3 which is being refreshed)
    org.apache.karaf.log.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.package.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.service.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.shell.commands/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.shell.console/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.shell.core/4.1.3 (Wired to org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
    org.apache.karaf.shell.ssh/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.system.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.servicemix.bundles.jasypt/1.9.2.1 (Should be wired to: javax.servlet-api/3.1.0 (through [org.apache.servicemix.bundles.jasypt/1.9.2.1] osgi.wiring.package; filter:="(osgi.wiring.package=javax.servlet)"; resolution:=optional))
    org.ops4j.pax.jdbc.config/1.1.0 (Wired to org.apache.servicemix.bundles.jasypt/1.9.2.1 which is being refreshed)
    org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 (Should be wired to: javax.mail/1.4.4 (through [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package; filter:="(osgi.wiring.package=javax.mail)"; resolution:=optional), com.lmax.disruptor/3.3.7 (through [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package; filter:="(osgi.wiring.package=com.lmax.disruptor)"; resolution:=optional), stax2-api/3.1.4 (through [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package; filter:="(osgi.wiring.package=org.codehaus.stax2)"; resolution:=optional))

 

I do not believe AAA even brings in servicemix bundles, since "servicemix" doesn't appear in the dependency tree.

dev@dev:/code/ar2/autorelease/aaa$ mvn dependency:tree | grep -i servicemix
dev@dev:/code/ar2/autorelease/aaa$

Any thoughts on why this may be happening/possible steps forward?  Anything is appreciated as I am frankly stumped.

Regards,

Ryan Goulding

[0] https://jira.opendaylight.org/browse/ODLPARENT-133

[1] https://git.opendaylight.org/gerrit/#/c/66056/

[2] https://git.opendaylight.org/gerrit/#/c/64196/

On Wed, Dec 6, 2017 at 4:57 AM, Stephen Kitt <skitt@...> wrote:

On Mon, 4 Dec 2017 12:54:53 -0500
Ryan Goulding <ryandgoulding@...> wrote:
> I see the same thing.
>
> Stephen, has this happened with any other testing w/ odlparent
> 2.0.5?  When I copy jars locally, I slowly get rid of error
> messages.  That obviously isn't desirable.  I also tried to take the
> default org.ops4j.pax.url.mvn.cfg and starting (in order to download
> the missing artifacts from remote repos) but that ran into many
> issues as well.

Not with 2.0.5 AFAICT.

With 3.0.1, there’s something messed up in the feature dependency
chain, or perhaps a mixture of the build and feature dependency chain.
I get the impression kar just gives up when it can’t converge
something, instead of failing the build, resulting in the empty
directories you’re seeing. Sticking to facts, if I add explicit
dependencies to aaa-karaf, I can progressively add more dependencies in
the distribution, and get further when building and/or loading
(building, because kar does resolve the OSGi dependencies, so
non-optional dependencies need to be fulfilled correctly).

So far, I’ve got webconsole.http, webconsole, servlet-api, pax-web-spi,
pax-web-api, commons-io, xbean-finder, asm-all, xbean-bundleutils,
commons-fileupload, and I’m at karaf.scr.management which is where
everything blows up because one part of the tree needs felix.scr >= 2
and another needs felix.scr < 2.

Since Karaf 4.1.3 itself can build a fully-populated distribution
correctly, I’m guessing this is related to one of the odlparent
patches, or perhaps an invalid version in our dependency (invalid as in
conflicting with Karaf).

I’m still digging...

Regards,

Spelunky

it’s worth looking for empty directories just after a build and again
after running.

Is there a reason we still have "4.0.9" version references for "patches" in "opendaylight-karaf-resources".  For example, here is karaf-javax-mail-4.1.3.patch that refers to karaf version 4.0.9 in the patch file [0]?

Regards,

Ryan Goulding

[0] https://github.com/opendaylight/odlparent/blob/v3.0.1/karaf/opendaylight-karaf-resources/src/main/patches/karaf-javax-mail-4.1.3.patch#L2

On Thu, Dec 7, 2017 at 9:38 AM, Stephen Kitt <skitt@...> wrote:

Hi Ryan,

I have no idea unfortunately, I’m as stymied as you by jasypt. I’m
still trying to figure out why we lose
org.apache.karaf.webconsole.http... (I’m also running into refresh
issues with jline, which has the nice side-effect of killing the
console and stopping Karaf. Ho hum.)

One interesting tid-bit is that the empty directories appear in system
when Karaf tries to resolve a bundle at runtime, not at build time, so
it’s worth looking for empty directories just after a build and again
after running.

Regards,

Stephen


On Thu, 7 Dec 2017 09:23:16 -0500
Ryan Goulding <ryandgoulding@...> wrote:

> Hi Stephen,
>
> Did you happen to get a chance to look at this bundle refresh?  I am
> asking since it seems to be referring to a *jasypt* refresh, which

> AAA doesn't install AFAICT.  Admittedly, it is strange if SFT works
> with controller and not AAA due to this issue, especially since AAA
> involves security (jasypt is security related).  I found the
> jasypt-encryption [0] feature in upstream karaf, but it is not
> installed as a part of "standard".  Do you have any knowledge as to
> why this bundle is even installed in our distribution?  From my
> understanding, we are using bouncycastle, not jasypt, for JCE
> Provider.  No worries if you don't have any idea, I will keep digging.
>
> Thanks,
>
> Ryan Goulding
>
> [0]
> https://github.com/apache/karaf/blob/karaf-4.1.3/assemblies/features/standard/src/main/feature/feature.xml#L923
>
> On Wed, Dec 6, 2017 at 11:28 AM, Ryan Goulding
> <ryandgoulding@...> wrote:
>
> > Stephen,
> >
> > Yeah, I did the more rudimentary version of downloading jars
> > manually and sticking them in system.  I started to unravel that
> > and ran into similar results.
> >
> > We identified two issues during yesterday's Kernel Project's call.
> > 1) system/ is not populated properly, which Stephen is working as
> > stated in the above email. [0]
> >
> > 2) AAA SFT hangs.  [1] addresses the switch off jackson (fails
> > dist-check due to the fact RESTCONF in NETCONF depended on import
> > of some dependencies by AAA, so it will likely need a similar
> > transition to GSON too ).  With [1] layered on the upgrade patch
> > [2] I am still running into a terrible bundle refresh during SFT...
> > surefire log snippet here:
> >
> > Refreshing bundles:
> >     org.apache.aries.blueprint.cm/1.1.0 (Wired to
> > org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
> >     org.apache.aries.blueprint.core/1.8.3 (Attached fragments
> > changed: [org.apache.aries.blueprint.core.compatibility/1.0.0])
> >     org.apache.karaf.bundle.blueprintstate/4.1.3 (Wired to
> > org.apache.karaf.bundle.core/4.1.3 which is being refreshed)
> >     org.apache.karaf.bundle.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> >     org.apache.karaf.config.core/4.1.3 (Should be wired to:
> > org.apache.felix.metatype/1.1.6 (through
> > [org.apache.karaf.config.core/4.1.3] osgi.wiring.package;
> > filter:="(&(osgi.wiring.package=org.osgi.service.
> > metatype)(version>=1.2.0)(!(version>=2.0.0)))";
> > resolution:=optional)) org.apache.karaf.deployer.kar/4.1.3 (Wired
> > to org.apache.karaf.kar.core/4.1.3 which is being refreshed)
> > org.apache.karaf.diagnostic.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.features.command/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.instance.core/4.1.3 (Wired to
> > org.apache.karaf.features.command/4.1.3 which is being refreshed)
> > org.apache.karaf.jaas.blueprint.config/4.1.3 (Wired to
> > org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
> > org.apache.karaf.jaas.command/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.kar.core/4.1.3 (Wired to

> > org.apache.karaf.features. command/4.1.3 which is being refreshed)

> > org.apache.karaf.log.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.package.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.service.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.shell.commands/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.shell.console/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.shell.core/4.1.3 (Wired to
> > org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
> > org.apache.karaf.shell.ssh/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.system.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.servicemix.bundles.jasypt/1.9.2.1 (Should be wired to:
> > javax.servlet-api/3.1.0 (through
> > [org.apache.servicemix.bundles.jasypt/ 1.9.2.1]
> > osgi.wiring.package; filter:="(osgi.wiring.package=javax.servlet)";
> > resolution:=optional)) org.ops4j.pax.jdbc.config/1.1.0 (Wired to
> > org.apache.servicemix.bundles.jasypt/1.9.2.1 which is being
> > refreshed) org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 (Should
> > be wired to: javax.mail/1.4.4 (through
> > [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1]
> > osgi.wiring.package; filter:="(osgi.wiring.package=javax.mail)";
> > resolution:=optional), com.lmax.disruptor/3.3.7 (through
> > [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1]
> > osgi.wiring.package;
> > filter:="(osgi.wiring.package=com.lmax.disruptor)";
> > resolution:=optional), stax2-api/3.1.4 (through
> > [org.ops4j.pax.logging.pax- logging-log4j2/1.10.1]
> > osgi.wiring.package;
> > filter:="(osgi.wiring.package=org.codehaus.stax2)";
> > resolution:=optional))
> >
> > I do not believe AAA even brings in servicemix bundles, since
> > "servicemix" doesn't appear in the dependency tree.
> >
> > dev@dev:/code/ar2/autorelease/aaa$ mvn dependency:tree | grep -i
> > servicemix
> > dev@dev:/code/ar2/autorelease/aaa$
> >
> > Any thoughts on why this may be happening/possible steps forward?
> > Anything is appreciated as I am frankly stumped.
> >
> > Regards,
> >
> > Ryan Goulding
> >
> > [0] https://jira.opendaylight.org/browse/ODLPARENT-133
> > [1] https://git.opendaylight.org/gerrit/#/c/66056/
> > [2] https://git.opendaylight.org/gerrit/#/c/64196/
> >
> > On Wed, Dec 6, 2017 at 4:57 AM, Stephen Kitt <skitt@...>
> > wrote:
> >> On Mon, 4 Dec 2017 12:54:53 -0500
> >> Ryan Goulding <ryandgoulding@...> wrote:
> >> > I see the same thing.
> >> >
> >> > Stephen, has this happened with any other testing w/ odlparent
> >> > 2.0.5?  When I copy jars locally, I slowly get rid of error
> >> > messages.  That obviously isn't desirable.  I also tried to take
> >> > the default org.ops4j.pax.url.mvn.cfg and starting (in order to
> >> > download the missing artifacts from remote repos) but that ran
> >> > into many issues as well.
> >>
> >> Not with 2.0.5 AFAICT.
> >>
> >> With 3.0.1, there’s something messed up in the feature dependency
> >> chain, or perhaps a mixture of the build and feature dependency
> >> chain. I get the impression kar just gives up when it can’t
> >> converge something, instead of failing the build, resulting in the
> >> empty directories you’re seeing. Sticking to facts, if I add
> >> explicit dependencies to aaa-karaf, I can progressively add more
> >> dependencies in the distribution, and get further when building
> >> and/or loading (building, because kar does resolve the OSGi
> >> dependencies, so non-optional dependencies need to be fulfilled
> >> correctly).
> >>
> >> So far, I’ve got webconsole.http, webconsole, servlet-api,
> >> pax-web-spi, pax-web-api, commons-io, xbean-finder, asm-all,
> >> xbean-bundleutils, commons-fileupload, and I’m at
> >> karaf.scr.management which is where everything blows up because
> >> one part of the tree needs felix.scr >= 2 and another needs
> >> felix.scr < 2.
> >>
> >> Since Karaf 4.1.3 itself can build a fully-populated distribution
> >> correctly, I’m guessing this is related to one of the odlparent
> >> patches, or perhaps an invalid version in our dependency (invalid
> >> as in conflicting with Karaf).
> >>
> >> I’m still digging...
> >>
> >> Regards,
> >>
> >> Spelunky
> >>
> >
> >

Exactly, I was going to check the situation without the patch, and if
we’re consistent, drop it entirely.


On Thu, 07 Dec 2017 19:25:14 +0100
Robert Varga <nite@...> wrote:

> Around javax.mail, I think we were downgrading  it to keep things
> consistent -- not sure with what. It may be the time to revisit /
> upgrade it...
>
>
>   Original Message  
> From: skitt@...
> Sent: December 7, 2017 6:57 PM
> To: ryandgoulding@...
> Cc: nite@...; aaa-dev@...;
> release@... Subject: Re: [release] Upgrading to
> yangtools-2.0.0/odlparent-3.0.1
>

> On Thu, 7 Dec 2017 10:10:33 -0500
> Ryan Goulding <ryandgoulding@...> wrote:
> > For this example, I looked in compiled
> > aaa/karaf/target/assembly/system/org/apache/karaf/features/standard/4.1.3/standard-4.1.3-features.xml
> > and see:
> >
> >         <bundle dependency="true"
> > start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>
> >
> > So if the intention was to maintain the downgrade of javax.mail in
> > our 4.1.3 odl-karaf-empty distribution, that patch is not actually
> > applied. Could be totally unrelated but I saw that javax.mail was in
> > the refresh wiring, so figured I'd point it out.
>
> Good catch, we’re patching the jetty 8 feature but using the jetty 9
> feature now AFAICT. So we need to patch that instead (or as well).
>
> Regards,
>
> Stephen

Yes, once I’ve figured out what all the changes are.

Regards,

Stephen


On Mon, 11 Dec 2017 09:38:51 -0500

Ryan Goulding <ryandgoulding@...> wrote:

> Are there plans to release new odlparent and yangtools artifacts with
> these changes?  It is getting a bit cumbersome to compile and set up
> a local build reactor for these changes.
>
> Regards,
>
> Ryan Goulding
>
> On Thu, Dec 7, 2017 at 2:06 PM, Stephen Kitt <skitt@...> wrote:
>
> > Exactly, I was going to check the situation without the patch, and
> > if we’re consistent, drop it entirely.
> >
> >
> > On Thu, 07 Dec 2017 19:25:14 +0100
> > Robert Varga <nite@...> wrote:
> >
> > > Around javax.mail, I think we were downgrading  it to keep things
> > > consistent -- not sure with what. It may be the time to revisit /
> > > upgrade it...
> > >
> > >
> > >   Original Message
> > > From: skitt@...
> > > Sent: December 7, 2017 6:57 PM
> > > To: ryandgoulding@...
> > > Cc: nite@...; aaa-dev@...;
> > > release@... Subject: Re: [release] Upgrading to
> > > yangtools-2.0.0/odlparent-3.0.1
> > >
> > > On Thu, 7 Dec 2017 10:10:33 -0500
> > > Ryan Goulding <ryandgoulding@...> wrote:
> > > > For this example, I looked in compiled
> > > > aaa/karaf/target/assembly/system/org/apache/karaf/
> > features/standard/4.1.3/standard-4.1.3-features.xml
> > > > and see:
> > > >
> > > >         <bundle dependency="true"
> > > > start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>
> > > >
> > > > So if the intention was to maintain the downgrade of javax.mail
> > > > in our 4.1.3 odl-karaf-empty distribution, that patch is not
> > > > actually applied. Could be totally unrelated but I saw that
> > > > javax.mail was in the refresh wiring, so figured I'd point it
> > > > out.
> > >
> > > Good catch, we’re patching the jetty 8 feature but using the
> > > jetty 9 feature now AFAICT. So we need to patch that instead (or
> > > as well).
> > >
> > > Regards,
> > >
> > > Stephen
> >
> >

AAA issues have been fixed by making a few changes to bouncycastle loading according to [0], and SFT now passes.

As discussed during the kernel projects call, we are going to start investigating the other critical projects identified here [1].  Unfortunately, I didn't realize our strategy didn't consider that doing the "critical priority" list projects like SFC involves doing it for all the various upstreams [2], so I am going to start on those first.

Regards,

Ryan Goulding

[0] https://jira.opendaylight.org/browse/ODLPARENT-134

[1] https://wiki.opendaylight.org/view/ODL_Root_Parent:BigBumpOfJan2018#To_Do_prio._critical

[2] https://logs.opendaylight.org/releng/jenkins092/autorelease-release-oxygen/77/dependencies.log.gz

On Mon, Dec 11, 2017 at 9:53 AM, Stephen Kitt <skitt@...> wrote:

Yes, once I’ve figured out what all the changes are.

Regards,

Stephen


On Mon, 11 Dec 2017 09:38:51 -0500

Ryan Goulding <ryandgoulding@...> wrote:

> Are there plans to release new odlparent and yangtools artifacts with
> these changes?  It is getting a bit cumbersome to compile and set up
> a local build reactor for these changes.
>
> Regards,
>
> Ryan Goulding
>
> On Thu, Dec 7, 2017 at 2:06 PM, Stephen Kitt <skitt@...> wrote:
>
> > Exactly, I was going to check the situation without the patch, and
> > if we’re consistent, drop it entirely.
> >
> >
> > On Thu, 07 Dec 2017 19:25:14 +0100
> > Robert Varga <nite@...> wrote:
> >
> > > Around javax.mail, I think we were downgrading  it to keep things
> > > consistent -- not sure with what. It may be the time to revisit /
> > > upgrade it...
> > >
> > >
> > >   Original Message
> > > From: skitt@...
> > > Sent: December 7, 2017 6:57 PM
> > > To: ryandgoulding@...
> > > Cc: nite@...; aaa-dev@...;
> > > release@... Subject: Re: [release] Upgrading to
> > > yangtools-2.0.0/odlparent-3.0.1
> > >
> > > On Thu, 7 Dec 2017 10:10:33 -0500
> > > Ryan Goulding <ryandgoulding@...> wrote:
> > > > For this example, I looked in compiled
> > > > aaa/karaf/target/assembly/system/org/apache/karaf/
> > features/standard/4.1.3/standard-4.1.3-features.xml
> > > > and see:
> > > >
> > > >         <bundle dependency="true"
> > > > start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>
> > > >
> > > > So if the intention was to maintain the downgrade of javax.mail
> > > > in our 4.1.3 odl-karaf-empty distribution, that patch is not
> > > > actually applied. Could be totally unrelated but I saw that
> > > > javax.mail was in the refresh wiring, so figured I'd point it
> > > > out.
> > >
> > > Good catch, we’re patching the jetty 8 feature but using the
> > > jetty 9 feature now AFAICT. So we need to patch that instead (or
> > > as well).
> > >
> > > Regards,
> > >
> > > Stephen
> >
> >

Would love a response from odlparent if those devs know something I am missing. I am more than happy to dig in Saturday also. On a plane almost all of tomorrow but have most of the weekend/ next week to explore. I “Reset” my local build reactor and still ran into the same issues in the previous mail... but admittedly didn’t deeply explore these failures due to competing time slots today with ONAP DDF.

Also a bit confused as to why in the current instructions we don’t have to version bump all projects’ odlparent dependencies to 3.0.2-SNAPSHOT. I may be missing something but AAA (and restconf) literally won’t work without these changes applied in step 1 of the instructions in [0] of the previous email... and the current patches listed assume 3.0.1. which was why we initially had issues with AAA. Please keep me honest if I am missing something completely here... or if I misunderstood the build instructions.

Very on board for getting us up and working on the new changes in odlparent and yangtools as soon as possible. Let’s keep this release on track! I’ll help whatever way possible, and will be on all next week to help us get there.

Thanks much in advance,

Ryan

On Dec 13, 2017, at 10:44 AM, Ryan Goulding <ryandgoulding@...> wrote:

Following instructions on [0] and running into this today:

dev@dev:/code/ar-odlparent3/controller$ mciq

[INFO] Scanning for projects...

[ERROR] [ERROR] Some problems were encountered while processing the POMs:

[WARNING] 'build.plugins.plugin.version' for org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 27, column 17

[WARNING] 'build.plugins.plugin.version' for org.codehaus.mojo:build-helper-maven-plugin is missing. @ org.opendaylight.controller.samples:clustering-it-config:[unknown-version], /code/ar-odlparent3/controller/opendaylight/md-sal/samples/clustering-test-app/configuration/pom.xml, line 21, column 17

[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-actor_${scala.version}:jar with value 'akka-actor_${scala.version}' does not match a valid id pattern. @ line 57, column 19

[ERROR] 'dependencies.dependency.version' for com.typesafe.akka:akka-actor_${scala.version}:jar is missing. @ line 55, column 17

[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-cluster_${scala.version}:jar with value 'akka-cluster_${scala.version}' does not match a valid id pattern. @ line 61, column 19

[ERROR] 'dependencies.dependency.version' for com.typesafe.akka:akka-cluster_${scala.version}:jar is missing. @ line 59, column 17

[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-osgi_${scala.version}:jar with value 'akka-osgi_${scala.version}' does not match a valid id pattern. 

Can someone confirm if the controller patch needs updates?

Best Regards,

Ryan Goulding

[0] https://wiki.opendaylight.org/view/ODL_Root_Parent:BigBumpOfJan2018

On Tue, Dec 12, 2017 at 2:19 PM, Ryan Goulding <ryandgoulding@...> wrote:

AAA issues have been fixed by making a few changes to bouncycastle loading according to [0], and SFT now passes.

As discussed during the kernel projects call, we are going to start investigating the other critical projects identified here [1].  Unfortunately, I didn't realize our strategy didn't consider that doing the "critical priority" list projects like SFC involves doing it for all the various upstreams [2], so I am going to start on those first.

Regards,

Ryan Goulding

[0] https://jira.opendaylight.org/browse/ODLPARENT-134

[1] https://wiki.opendaylight.org/view/ODL_Root_Parent:BigBumpOfJan2018#To_Do_prio._critical

[2] https://logs.opendaylight.org/releng/jenkins092/autorelease-release-oxygen/77/dependencies.log.gz

On Mon, Dec 11, 2017 at 9:53 AM, Stephen Kitt <skitt@...> wrote:

Yes, once I’ve figured out what all the changes are.

Regards,

Stephen


On Mon, 11 Dec 2017 09:38:51 -0500

Ryan Goulding <ryandgoulding@...> wrote:

> Are there plans to release new odlparent and yangtools artifacts with
> these changes?  It is getting a bit cumbersome to compile and set up
> a local build reactor for these changes.
>
> Regards,
>
> Ryan Goulding
>
> On Thu, Dec 7, 2017 at 2:06 PM, Stephen Kitt <skitt@...> wrote:
>
> > Exactly, I was going to check the situation without the patch, and
> > if we’re consistent, drop it entirely.
> >
> >
> > On Thu, 07 Dec 2017 19:25:14 +0100
> > Robert Varga <nite@...> wrote:
> >
> > > Around javax.mail, I think we were downgrading  it to keep things
> > > consistent -- not sure with what. It may be the time to revisit /
> > > upgrade it...
> > >
> > >
> > >   Original Message
> > > From: skitt@...
> > > Sent: December 7, 2017 6:57 PM
> > > To: ryandgoulding@...
> > > Cc: nite@...; aaa-dev@...;
> > > release@... Subject: Re: [release] Upgrading to
> > > yangtools-2.0.0/odlparent-3.0.1
> > >
> > > On Thu, 7 Dec 2017 10:10:33 -0500
> > > Ryan Goulding <ryandgoulding@...> wrote:
> > > > For this example, I looked in compiled
> > > > aaa/karaf/target/assembly/system/org/apache/karaf/
> > features/standard/4.1.3/standard-4.1.3-features.xml
> > > > and see:
> > > >
> > > >         <bundle dependency="true"
> > > > start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>
> > > >
> > > > So if the intention was to maintain the downgrade of javax.mail
> > > > in our 4.1.3 odl-karaf-empty distribution, that patch is not
> > > > actually applied. Could be totally unrelated but I saw that
> > > > javax.mail was in the refresh wiring, so figured I'd point it
> > > > out.
> > >
> > > Good catch, we’re patching the jetty 8 feature but using the
> > > jetty 9 feature now AFAICT. So we need to patch that instead (or
> > > as well).
> > >
> > > Regards,
> > >
> > > Stephen
> >
> >

_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release