[release] Help with karaf4 features for AAA


Robert Varga
 

On 26/04/17 15:26, Ryan Goulding wrote:
Hi Release team,

After putting some serious effort into trying to fix this, I am unable
to figure out why it is failing in the first place:

20:34:17 -------------------------------------------------------
20:34:17 T E S T S
20:34:17 -------------------------------------------------------
20:34:22 Running org.opendaylight.odlparent.featuretest.SingleFeatureTest
20:37:41 Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 198.433 sec <<< FAILURE! - in org.opendaylight.odlparent.featuretest.SingleFeatureTest
20:37:41 installFeatureCatchAndLog(org.opendaylight.odlparent.featuretest.SingleFeatureTest)[repoUrl: file:/w/workspace/aaa-verify-carbon-mvn33-openjdk8/features/authn/features4-aaa/target/feature/feature.xml, Feature: odl-aaa-encryption-service 0.5.0.SNAPSHOT] Time elapsed: 25.312 sec <<< FAILURE!
20:37:41 java.lang.AssertionError: diag: Stopping {Failure=0, GracePeriod=0, Starting=0, Resolved=4, Stopping=1, Unknown=0, Waiting=0, Active=223, Installed=0}
https://logs.opendaylight.org/releng/jenkins092/aaa-verify-carbon-mvn33-openjdk8/397/archives/features/authn/features4-aaa/target/surefire-reports/org.opendaylight.odlparent.featuretest.SingleFeatureTest-output.txt.gz

Root cause:

4. NOK org.opendaylight.controller.sal-binding-broker-impl: OSGi state =
Active, Karaf bundleState = GracePeriod, due to: Blueprint
4/25/17 8:35 PM
Missing dependencies:
(objectClass=org.opendaylight.mdsal.binding.generator.api.ClassLoadingStrategy)


I think config-manager's activator is supposed to publish that service.

Bye,
Robert


Ryan Goulding <ryandgoulding@...>
 

Thanks Robert.  You mean that the Service is published here [0]?  So should I add a WaitingServiceTacker to the AAAShiroProvider.newInstance(...) [1], something like:

final WaitingServiceTracker<ClassLoadingStrategy> clsServiceTracker =
                WaitingServiceTracker.create(ClassLoadingStrategy.class, bundleContext);
clsServiceTracker.waitForService(WaitingServiceTracker.FIVE_MINUTES);

Please confirm I am at least on the right track here :).

On Wed, Apr 26, 2017 at 9:59 AM, Robert Varga <nite@...> wrote:


On 26/04/17 15:26, Ryan Goulding wrote:
> Hi Release team,
>
> After putting some serious effort into trying to fix this, I am unable
> to figure out why it is failing in the first place:
>
> 20:34:17  -------------------------------------------------------
> 20:34:17   T E S T S
> 20:34:17  -------------------------------------------------------
> 20:34:22  Running org.opendaylight.odlparent.featuretest.SingleFeatureTest
> 20:37:41  Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 198.433 sec <<< FAILURE! - in org.opendaylight.odlparent.featuretest.SingleFeatureTest
> 20:37:41  installFeatureCatchAndLog(org.opendaylight.odlparent.featuretest.SingleFeatureTest)[repoUrl: file:/w/workspace/aaa-verify-carbon-mvn33-openjdk8/features/authn/features4-aaa/target/feature/feature.xml, Feature: odl-aaa-encryption-service 0.5.0.SNAPSHOT]  Time elapsed: 25.312 sec  <<< FAILURE!
> 20:37:41  java.lang.AssertionError: diag: Stopping {Failure=0, GracePeriod=0, Starting=0, Resolved=4, Stopping=1, Unknown=0, Waiting=0, Active=223, Installed=0}

https://logs.opendaylight.org/releng/jenkins092/aaa-verify-carbon-mvn33-openjdk8/397/archives/features/authn/features4-aaa/target/surefire-reports/org.opendaylight.odlparent.featuretest.SingleFeatureTest-output.txt.gz

Root cause:

4. NOK org.opendaylight.controller.sal-binding-broker-impl: OSGi state =
Active, Karaf bundleState = GracePeriod, due to: Blueprint
4/25/17 8:35 PM
Missing dependencies:
(objectClass=org.opendaylight.mdsal.binding.generator.api.ClassLoadingStrategy)


I think config-manager's activator is supposed to publish that service.

Bye,
Robert



Ryan Goulding <ryandgoulding@...>
 

Something along the lines of this [0] (stable/carbon), which just sits and waits for the service to become available?  Let me know if I am way off base here.

Also, more reasons we should try to rip that bespoke system out in the future :).

On Wed, Apr 26, 2017 at 10:23 AM, Ryan Goulding <ryandgoulding@...> wrote:
Thanks Robert.  You mean that the Service is published here [0]?  So should I add a WaitingServiceTacker to the AAAShiroProvider.newInstance(...) [1], something like:

final WaitingServiceTracker<ClassLoadingStrategy> clsServiceTracker =
                WaitingServiceTracker.create(ClassLoadingStrategy.class, bundleContext);
clsServiceTracker.waitForService(WaitingServiceTracker.FIVE_MINUTES);

Please confirm I am at least on the right track here :).

On Wed, Apr 26, 2017 at 9:59 AM, Robert Varga <nite@...> wrote:


On 26/04/17 15:26, Ryan Goulding wrote:
> Hi Release team,
>
> After putting some serious effort into trying to fix this, I am unable
> to figure out why it is failing in the first place:
>
> 20:34:17  -------------------------------------------------------
> 20:34:17   T E S T S
> 20:34:17  -------------------------------------------------------
> 20:34:22  Running org.opendaylight.odlparent.featuretest.SingleFeatureTest
> 20:37:41  Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 198.433 sec <<< FAILURE! - in org.opendaylight.odlparent.featuretest.SingleFeatureTest
> 20:37:41  installFeatureCatchAndLog(org.opendaylight.odlparent.featuretest.SingleFeatureTest)[repoUrl: file:/w/workspace/aaa-verify-carbon-mvn33-openjdk8/features/authn/features4-aaa/target/feature/feature.xml, Feature: odl-aaa-encryption-service 0.5.0.SNAPSHOT]  Time elapsed: 25.312 sec  <<< FAILURE!
> 20:37:41  java.lang.AssertionError: diag: Stopping {Failure=0, GracePeriod=0, Starting=0, Resolved=4, Stopping=1, Unknown=0, Waiting=0, Active=223, Installed=0}

https://logs.opendaylight.org/releng/jenkins092/aaa-verify-carbon-mvn33-openjdk8/397/archives/features/authn/features4-aaa/target/surefire-reports/org.opendaylight.odlparent.featuretest.SingleFeatureTest-output.txt.gz

Root cause:

4. NOK org.opendaylight.controller.sal-binding-broker-impl: OSGi state =
Active, Karaf bundleState = GracePeriod, due to: Blueprint
4/25/17 8:35 PM
Missing dependencies:
(objectClass=org.opendaylight.mdsal.binding.generator.api.ClassLoadingStrategy)


I think config-manager's activator is supposed to publish that service.

Bye,
Robert




Robert Varga
 

On 26/04/17 16:23, Ryan Goulding wrote:
Thanks Robert. You mean that the Service is published here [0]? So
should I add a WaitingServiceTacker to the
AAAShiroProvider.newInstance(...) [1], something like:

final WaitingServiceTracker<ClassLoadingStrategy> clsServiceTracker =
WaitingServiceTracker.create(ClassLoadingStrategy.class,
bundleContext);
clsServiceTracker.waitForService(WaitingServiceTracker.FIVE_MINUTES);

Please confirm I am at least on the right track here :).
Scratch that, looking further into the logs, I am finding:

2017-04-25 20:37:04,465 | INFO | rint Extender: 1 |
BlueprintContainerImpl | 12 - org.apache.aries.blueprint.core
- 1.7.1 | Bundle org.opendaylight.aaa.encrypt-service/0.5.0.SNAPSHOT is
waiting for dependencies
[(&(|(type=default)(!(type=*)))(objectClass=org.opendaylight.mdsal.binding.dom.codec.api.BindingNormalizedNodeSerializer))]
2017-04-25 20:37:04,609 | INFO | ntAdminThread #7 |
BlueprintBundleTracker | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Blueprint
container for bundle
org.opendaylight.mdsal.eos-binding-adapter_2.2.0.SNAPSHOT [171] was
successfully created
2017-04-25 20:37:04,672 | INFO | ntAdminThread #8 |
BlueprintBundleTracker | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Blueprint
container for bundle
org.opendaylight.controller.sal-binding-broker-impl_1.5.0.SNAPSHOT [135]
was successfully created
2017-04-25 20:37:04,720 | INFO | config-pusher | ConfigPusherImpl
| 127 - org.opendaylight.controller.config-persister-impl -
0.6.0.SNAPSHOT | Pushing configuration snapshot
00-netty.xml(odl-mdsal-broker-local,odl-mdsal-broker-local)
2017-04-25 20:37:04,879 | INFO | ntAdminThread #9 |
BlueprintBundleTracker | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Blueprint
container for bundle
org.opendaylight.controller.sal-cluster-admin-impl_1.5.0.SNAPSHOT [140]
was successfully created


... wheee, we are almost up and running ...


2017-04-25 20:37:05,002 | INFO | rint Extender: 3 | MdsalUtils
| 116 - org.opendaylight.aaa.encrypt-service -
0.5.0.SNAPSHOT | initDatastore: data populated: CONFIGURATION,
InstanceIdentifier{targetType=interface
org.opendaylight.yang.gen.v1.config.aaa.authn.encrypt.service.config.rev160915.AaaEncryptServiceConfig,
path=[org.opendaylight.yang.gen.v1.config.aaa.authn.encrypt.service.config.rev160915.AaaEncryptServiceConfig]},
AaaEncryptServiceConfig [_cipherTransforms=AES/CBC/PKCS5Padding,
_encryptIterationCount=32768, _encryptKey=eJeSv5DojahZ,
_encryptKeyLength=128, _encryptMethod=PBKDF2WithHmacSHA1,
_encryptSalt=m/oyP5GB2x9TxdqzK/VPAQ==, _encryptType=AES,
_passwordLength=12, augmentation=[]]


... so we are executing in the context of this bundle and have populated
the data...


2017-04-25 20:37:05,062 | INFO | erRestartService |
printContainerRestartServiceImpl | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Restarting
blueprint containers for bundle
org.opendaylight.aaa.encrypt-service_0.5.0.SNAPSHOT [116] and its
dependent bundles []
2017-04-25 20:37:05,177 | INFO | ainer-ThreadPool | BlueprintExtender
| 12 - org.apache.aries.blueprint.core - 1.7.1 | Destroying
BlueprintContainer for bundle
org.opendaylight.aaa.encrypt-service/0.5.0.SNAPSHOT

... but now blueprint extender is restarting the container... Tom, why
is that happening?

2017-04-25 20:37:05,195 | INFO | BundleDiagInfos] | TestBundleDiag
| 73 - PAXEXAM-PROBE-cb8b0f14-763c-4e20-bcc8-0cd2a8a7c141 -
0.0.0 | checkBundleDiagInfos: Elapsed time 1s, remaining time 298s,
diag: Stopping {Failure=0, GracePeriod=0, Starting=0, Resolved=4,
Stopping=1, Unknown=0, Waiting=0, Active=223, Installed=0}

... and that restarting thing is caught by SFT, leading to a very loud
failure.

Bye,
Robert


Colin Dixon <colin@...>
 

I created this blocking bug to help us track the issue:

Really, it's just a nice ID to reference that is easy to navigate back to, e.g., when it's blocking other issues and I want to know when I can make progress on those again.

--Colin


On Wed, Apr 26, 2017 at 10:48 AM, Robert Varga <nite@...> wrote:


On 26/04/17 16:23, Ryan Goulding wrote:
> Thanks Robert.  You mean that the Service is published here [0]?  So
> should I add a WaitingServiceTacker to the
> AAAShiroProvider.newInstance(...) [1], something like:
>
> final WaitingServiceTracker<ClassLoadingStrategy> clsServiceTracker =
>                 WaitingServiceTracker.create(ClassLoadingStrategy.class,
> bundleContext);
> clsServiceTracker.waitForService(WaitingServiceTracker.FIVE_MINUTES);
>
> Please confirm I am at least on the right track here :).

Scratch that, looking further into the logs, I am finding:

2017-04-25 20:37:04,465 | INFO  | rint Extender: 1 |
BlueprintContainerImpl           | 12 - org.apache.aries.blueprint.core
- 1.7.1 | Bundle org.opendaylight.aaa.encrypt-service/0.5.0.SNAPSHOT is
waiting for dependencies
[(&(|(type=default)(!(type=*)))(objectClass=org.opendaylight.mdsal.binding.dom.codec.api.BindingNormalizedNodeSerializer))]
2017-04-25 20:37:04,609 | INFO  | ntAdminThread #7 |
BlueprintBundleTracker           | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Blueprint
container for bundle
org.opendaylight.mdsal.eos-binding-adapter_2.2.0.SNAPSHOT [171] was
successfully created
2017-04-25 20:37:04,672 | INFO  | ntAdminThread #8 |
BlueprintBundleTracker           | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Blueprint
container for bundle
org.opendaylight.controller.sal-binding-broker-impl_1.5.0.SNAPSHOT [135]
was successfully created
2017-04-25 20:37:04,720 | INFO  | config-pusher    | ConfigPusherImpl
             | 127 - org.opendaylight.controller.config-persister-impl -
0.6.0.SNAPSHOT | Pushing configuration snapshot
00-netty.xml(odl-mdsal-broker-local,odl-mdsal-broker-local)
2017-04-25 20:37:04,879 | INFO  | ntAdminThread #9 |
BlueprintBundleTracker           | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Blueprint
container for bundle
org.opendaylight.controller.sal-cluster-admin-impl_1.5.0.SNAPSHOT [140]
was successfully created


... wheee, we are almost up and running ...


2017-04-25 20:37:05,002 | INFO  | rint Extender: 3 | MdsalUtils
             | 116 - org.opendaylight.aaa.encrypt-service -
0.5.0.SNAPSHOT | initDatastore: data populated: CONFIGURATION,
InstanceIdentifier{targetType=interface
org.opendaylight.yang.gen.v1.config.aaa.authn.encrypt.service.config.rev160915.AaaEncryptServiceConfig,
path=[org.opendaylight.yang.gen.v1.config.aaa.authn.encrypt.service.config.rev160915.AaaEncryptServiceConfig]},
AaaEncryptServiceConfig [_cipherTransforms=AES/CBC/PKCS5Padding,
_encryptIterationCount=32768, _encryptKey=eJeSv5DojahZ,
_encryptKeyLength=128, _encryptMethod=PBKDF2WithHmacSHA1,
_encryptSalt=m/oyP5GB2x9TxdqzK/VPAQ==, _encryptType=AES,
_passwordLength=12, augmentation=[]]


... so we are executing in the context of this bundle and have populated
the data...


2017-04-25 20:37:05,062 | INFO  | erRestartService |
printContainerRestartServiceImpl | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Restarting
blueprint containers for bundle
org.opendaylight.aaa.encrypt-service_0.5.0.SNAPSHOT [116] and its
dependent bundles []
2017-04-25 20:37:05,177 | INFO  | ainer-ThreadPool | BlueprintExtender
             | 12 - org.apache.aries.blueprint.core - 1.7.1 | Destroying
BlueprintContainer for bundle
org.opendaylight.aaa.encrypt-service/0.5.0.SNAPSHOT

... but now blueprint extender is restarting the container... Tom, why
is that happening?

2017-04-25 20:37:05,195 | INFO  | BundleDiagInfos] | TestBundleDiag
             | 73 - PAXEXAM-PROBE-cb8b0f14-763c-4e20-bcc8-0cd2a8a7c141 -
0.0.0 | checkBundleDiagInfos: Elapsed time 1s, remaining time 298s,
diag: Stopping {Failure=0, GracePeriod=0, Starting=0, Resolved=4,
Stopping=1, Unknown=0, Waiting=0, Active=223, Installed=0}

... and that restarting thing is caught by SFT, leading to a very loud
failure.

Bye,
Robert


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



Tom Pantelis
 



On Wed, Apr 26, 2017 at 10:48 AM, Robert Varga <nite@...> wrote:

... so we are executing in the context of this bundle and have populated
the data...


2017-04-25 20:37:05,062 | INFO  | erRestartService |
printContainerRestartServiceImpl | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Restarting
blueprint containers for bundle
org.opendaylight.aaa.encrypt-service_0.5.0.SNAPSHOT [116] and its
dependent bundles []
2017-04-25 20:37:05,177 | INFO  | ainer-ThreadPool | BlueprintExtender
             | 12 - org.apache.aries.blueprint.core - 1.7.1 | Destroying
BlueprintContainer for bundle
org.opendaylight.aaa.encrypt-service/0.5.0.SNAPSHOT

... but now blueprint extender is restarting the container... Tom, why
is that happening?

 
It seems like the  app config data changed which triggered the DTCL for <clustered-app-config> to restart the BP container.  "org.opendaylight.aaa.encrypt-service - 0.5.0.SNAPSHOT | initDatastore: data populated: CONFIGURATION,"... hmm... does that mean it updated the app config data?
 
2017-04-25 20:37:05,195 | INFO  | BundleDiagInfos] | TestBundleDiag
             | 73 - PAXEXAM-PROBE-cb8b0f14-763c-4e20-bcc8-0cd2a8a7c141 -
0.0.0 | checkBundleDiagInfos: Elapsed time 1s, remaining time 298s,
diag: Stopping {Failure=0, GracePeriod=0, Starting=0, Resolved=4,
Stopping=1, Unknown=0, Waiting=0, Active=223, Installed=0}

... and that restarting thing is caught by SFT, leading to a very loud
failure.

Bye,
Robert



Mohamed ElSerngawy <melserngawy@...>
 

Yes, it is doing that, updating the config data 

On Wed, Apr 26, 2017 at 11:56 AM, Tom Pantelis <tompantelis@...> wrote:


On Wed, Apr 26, 2017 at 10:48 AM, Robert Varga <nite@...> wrote:

... so we are executing in the context of this bundle and have populated
the data...


2017-04-25 20:37:05,062 | INFO  | erRestartService |
printContainerRestartServiceImpl | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Restarting
blueprint containers for bundle
org.opendaylight.aaa.encrypt-service_0.5.0.SNAPSHOT [116] and its
dependent bundles []
2017-04-25 20:37:05,177 | INFO  | ainer-ThreadPool | BlueprintExtender
             | 12 - org.apache.aries.blueprint.core - 1.7.1 | Destroying
BlueprintContainer for bundle
org.opendaylight.aaa.encrypt-service/0.5.0.SNAPSHOT

... but now blueprint extender is restarting the container... Tom, why
is that happening?

 
It seems like the  app config data changed which triggered the DTCL for <clustered-app-config> to restart the BP container.  "org.opendaylight.aaa.encrypt-service - 0.5.0.SNAPSHOT | initDatastore: data populated: CONFIGURATION,"... hmm... does that mean it updated the app config data?
 
2017-04-25 20:37:05,195 | INFO  | BundleDiagInfos] | TestBundleDiag
             | 73 - PAXEXAM-PROBE-cb8b0f14-763c-4e20-bcc8-0cd2a8a7c141 -
0.0.0 | checkBundleDiagInfos: Elapsed time 1s, remaining time 298s,
diag: Stopping {Failure=0, GracePeriod=0, Starting=0, Resolved=4,
Stopping=1, Unknown=0, Waiting=0, Active=223, Installed=0}

... and that restarting thing is caught by SFT, leading to a very loud
failure.

Bye,
Robert



_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



Ryan Goulding <ryandgoulding@...>
 

Yes, for security reasons we update the config data with some generated values for salt etc.

Regards,

Ryan Goulding

On Wed, Apr 26, 2017 at 12:05 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
Yes, it is doing that, updating the config data 

On Wed, Apr 26, 2017 at 11:56 AM, Tom Pantelis <tompantelis@...> wrote:


On Wed, Apr 26, 2017 at 10:48 AM, Robert Varga <nite@...> wrote:

... so we are executing in the context of this bundle and have populated
the data...


2017-04-25 20:37:05,062 | INFO  | erRestartService |
printContainerRestartServiceImpl | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Restarting
blueprint containers for bundle
org.opendaylight.aaa.encrypt-service_0.5.0.SNAPSHOT [116] and its
dependent bundles []
2017-04-25 20:37:05,177 | INFO  | ainer-ThreadPool | BlueprintExtender
             | 12 - org.apache.aries.blueprint.core - 1.7.1 | Destroying
BlueprintContainer for bundle
org.opendaylight.aaa.encrypt-service/0.5.0.SNAPSHOT

... but now blueprint extender is restarting the container... Tom, why
is that happening?

 
It seems like the  app config data changed which triggered the DTCL for <clustered-app-config> to restart the BP container.  "org.opendaylight.aaa.encrypt-service - 0.5.0.SNAPSHOT | initDatastore: data populated: CONFIGURATION,"... hmm... does that mean it updated the app config data?
 
2017-04-25 20:37:05,195 | INFO  | BundleDiagInfos] | TestBundleDiag
             | 73 - PAXEXAM-PROBE-cb8b0f14-763c-4e20-bcc8-0cd2a8a7c141 -
0.0.0 | checkBundleDiagInfos: Elapsed time 1s, remaining time 298s,
diag: Stopping {Failure=0, GracePeriod=0, Starting=0, Resolved=4,
Stopping=1, Unknown=0, Waiting=0, Active=223, Installed=0}

... and that restarting thing is caught by SFT, leading to a very loud
failure.

Bye,
Robert



_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



Tom Pantelis
 

OK - that explains it. I assume it only updates the config data once on initial start and not on every restart?

 Restarting the BP container is OK.  Ideally <clustered-app-config> could be embedded in a bean and invoke an update method when it changes (similar to <cm:managed-properties>). That's on my TODO list....

On Wed, Apr 26, 2017 at 12:06 PM, Ryan Goulding <ryandgoulding@...> wrote:
Yes, for security reasons we update the config data with some generated values for salt etc.

Regards,

Ryan Goulding

On Wed, Apr 26, 2017 at 12:05 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
Yes, it is doing that, updating the config data 

On Wed, Apr 26, 2017 at 11:56 AM, Tom Pantelis <tompantelis@...> wrote:


On Wed, Apr 26, 2017 at 10:48 AM, Robert Varga <nite@...> wrote:

... so we are executing in the context of this bundle and have populated
the data...


2017-04-25 20:37:05,062 | INFO  | erRestartService |
printContainerRestartServiceImpl | 117 -
org.opendaylight.controller.blueprint - 0.6.0.SNAPSHOT | Restarting
blueprint containers for bundle
org.opendaylight.aaa.encrypt-service_0.5.0.SNAPSHOT [116] and its
dependent bundles []
2017-04-25 20:37:05,177 | INFO  | ainer-ThreadPool | BlueprintExtender
             | 12 - org.apache.aries.blueprint.core - 1.7.1 | Destroying
BlueprintContainer for bundle
org.opendaylight.aaa.encrypt-service/0.5.0.SNAPSHOT

... but now blueprint extender is restarting the container... Tom, why
is that happening?

 
It seems like the  app config data changed which triggered the DTCL for <clustered-app-config> to restart the BP container.  "org.opendaylight.aaa.encrypt-service - 0.5.0.SNAPSHOT | initDatastore: data populated: CONFIGURATION,"... hmm... does that mean it updated the app config data?
 
2017-04-25 20:37:05,195 | INFO  | BundleDiagInfos] | TestBundleDiag
             | 73 - PAXEXAM-PROBE-cb8b0f14-763c-4e20-bcc8-0cd2a8a7c141 -
0.0.0 | checkBundleDiagInfos: Elapsed time 1s, remaining time 298s,
diag: Stopping {Failure=0, GracePeriod=0, Starting=0, Resolved=4,
Stopping=1, Unknown=0, Waiting=0, Active=223, Installed=0}

... and that restarting thing is caught by SFT, leading to a very loud
failure.

Bye,
Robert



_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev




Robert Varga
 

On 26/04/17 18:35, Tom Pantelis wrote:
OK - that explains it. I assume it only updates the config data once on
initial start and not on every restart?

Restarting the BP container is OK. Ideally <clustered-app-config>
could be embedded in a bean and invoke an update method when it changes
(similar to <cm:managed-properties>). That's on my TODO list....
So how do we deal with this in a reasonable time frame?

I think SFT's expectation of not observing bundle stops is reasonable,
but we obviously have a restart happening for a very valid reason.

Bye,
Robert


Tom Pantelis
 



On Wed, Apr 26, 2017 at 12:38 PM, Robert Varga <nite@...> wrote:
On 26/04/17 18:35, Tom Pantelis wrote:
> OK - that explains it. I assume it only updates the config data once on
> initial start and not on every restart?
>
>  Restarting the BP container is OK.  Ideally <clustered-app-config>
> could be embedded in a bean and invoke an update method when it changes
> (similar to <cm:managed-properties>). That's on my TODO list....

So how do we deal with this in a reasonable time frame?

I think SFT's expectation of not observing bundle stops is reasonable,
but we obviously have a restart happening for a very valid reason.



We could disable SFT for AAA for now as a temporary stop gap. Or somehow configure something in SFT telling it to expect a restart of that particular BP container?

Shorter term,
  - Disable restarting container for <clustered-app-config> (set update-strategy="none"). However that would require a manual restart for changes to take.
  - Don't use <clustered-app-config> - read/watch the data in the app

Longer term 
   - allow <clustered-app-config> to be embedded in a <bean> as I mentioned before.


Ryan Goulding <ryandgoulding@...>
 

We can also just hardcode those values now and suggest users change them on their own. Something like [0].  Thoughts??

On Wed, Apr 26, 2017 at 12:54 PM, Tom Pantelis <tompantelis@...> wrote:


On Wed, Apr 26, 2017 at 12:38 PM, Robert Varga <nite@...> wrote:
On 26/04/17 18:35, Tom Pantelis wrote:
> OK - that explains it. I assume it only updates the config data once on
> initial start and not on every restart?
>
>  Restarting the BP container is OK.  Ideally <clustered-app-config>
> could be embedded in a bean and invoke an update method when it changes
> (similar to <cm:managed-properties>). That's on my TODO list....

So how do we deal with this in a reasonable time frame?

I think SFT's expectation of not observing bundle stops is reasonable,
but we obviously have a restart happening for a very valid reason.



We could disable SFT for AAA for now as a temporary stop gap. Or somehow configure something in SFT telling it to expect a restart of that particular BP container?

Shorter term,
  - Disable restarting container for <clustered-app-config> (set update-strategy="none"). However that would require a manual restart for changes to take.
  - Don't use <clustered-app-config> - read/watch the data in the app

Longer term 
   - allow <clustered-app-config> to be embedded in a <bean> as I mentioned before.



Mohamed ElSerngawy <melserngawy@...>
 

Hi Tom,

I assume it only updates the config data once on initial start and not on every restart?
 It is not updating every restart, only at the first time to generate the random values.   
 



On Wed, Apr 26, 2017 at 1:16 PM, Ryan Goulding <ryandgoulding@...> wrote:
We can also just hardcode those values now and suggest users change them on their own. Something like [0].  Thoughts??

Regards,

Ryan Goulding


On Wed, Apr 26, 2017 at 12:54 PM, Tom Pantelis <tompantelis@...> wrote:


On Wed, Apr 26, 2017 at 12:38 PM, Robert Varga <nite@...> wrote:
On 26/04/17 18:35, Tom Pantelis wrote:
> OK - that explains it. I assume it only updates the config data once on
> initial start and not on every restart?
>
>  Restarting the BP container is OK.  Ideally <clustered-app-config>
> could be embedded in a bean and invoke an update method when it changes
> (similar to <cm:managed-properties>). That's on my TODO list....

So how do we deal with this in a reasonable time frame?

I think SFT's expectation of not observing bundle stops is reasonable,
but we obviously have a restart happening for a very valid reason.



We could disable SFT for AAA for now as a temporary stop gap. Or somehow configure something in SFT telling it to expect a restart of that particular BP container?

Shorter term,
  - Disable restarting container for <clustered-app-config> (set update-strategy="none"). However that would require a manual restart for changes to take.
  - Don't use <clustered-app-config> - read/watch the data in the app

Longer term 
   - allow <clustered-app-config> to be embedded in a <bean> as I mentioned before.




Ryan Goulding <ryandgoulding@...>
 

We are just going to hardcode for this release and make suggestion that users change it.  Afterwards, we can fix in nitrogen and cherry pick to stable/carbon for SR1.  I have a patch waiting jenkins +1 listed above.

Regards,

Ryan Goulding

On Wed, Apr 26, 2017 at 2:06 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Tom,

I assume it only updates the config data once on initial start and not on every restart?
 It is not updating every restart, only at the first time to generate the random values.   
 



On Wed, Apr 26, 2017 at 1:16 PM, Ryan Goulding <ryandgoulding@...> wrote:
We can also just hardcode those values now and suggest users change them on their own. Something like [0].  Thoughts??

Regards,

Ryan Goulding


On Wed, Apr 26, 2017 at 12:54 PM, Tom Pantelis <tompantelis@...> wrote:


On Wed, Apr 26, 2017 at 12:38 PM, Robert Varga <nite@...> wrote:
On 26/04/17 18:35, Tom Pantelis wrote:
> OK - that explains it. I assume it only updates the config data once on
> initial start and not on every restart?
>
>  Restarting the BP container is OK.  Ideally <clustered-app-config>
> could be embedded in a bean and invoke an update method when it changes
> (similar to <cm:managed-properties>). That's on my TODO list....

So how do we deal with this in a reasonable time frame?

I think SFT's expectation of not observing bundle stops is reasonable,
but we obviously have a restart happening for a very valid reason.



We could disable SFT for AAA for now as a temporary stop gap. Or somehow configure something in SFT telling it to expect a restart of that particular BP container?

Shorter term,
  - Disable restarting container for <clustered-app-config> (set update-strategy="none"). However that would require a manual restart for changes to take.
  - Don't use <clustered-app-config> - read/watch the data in the app

Longer term 
   - allow <clustered-app-config> to be embedded in a <bean> as I mentioned before.





Ryan Goulding <ryandgoulding@...>
 

2/4 jobs have passed so far including a verify pass (first one I have gotten in days...).  Things are looking good knock on wood.  Will keep you all updated.

Regards,

Ryan Goulding

On Wed, Apr 26, 2017 at 2:07 PM, Ryan Goulding <ryandgoulding@...> wrote:
We are just going to hardcode for this release and make suggestion that users change it.  Afterwards, we can fix in nitrogen and cherry pick to stable/carbon for SR1.  I have a patch waiting jenkins +1 listed above.

Regards,

Ryan Goulding

On Wed, Apr 26, 2017 at 2:06 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Tom,

I assume it only updates the config data once on initial start and not on every restart?
 It is not updating every restart, only at the first time to generate the random values.   
 



On Wed, Apr 26, 2017 at 1:16 PM, Ryan Goulding <ryandgoulding@...> wrote:
We can also just hardcode those values now and suggest users change them on their own. Something like [0].  Thoughts??

Regards,

Ryan Goulding


On Wed, Apr 26, 2017 at 12:54 PM, Tom Pantelis <tompantelis@...> wrote:


On Wed, Apr 26, 2017 at 12:38 PM, Robert Varga <nite@...> wrote:
On 26/04/17 18:35, Tom Pantelis wrote:
> OK - that explains it. I assume it only updates the config data once on
> initial start and not on every restart?
>
>  Restarting the BP container is OK.  Ideally <clustered-app-config>
> could be embedded in a bean and invoke an update method when it changes
> (similar to <cm:managed-properties>). That's on my TODO list....

So how do we deal with this in a reasonable time frame?

I think SFT's expectation of not observing bundle stops is reasonable,
but we obviously have a restart happening for a very valid reason.



We could disable SFT for AAA for now as a temporary stop gap. Or somehow configure something in SFT telling it to expect a restart of that particular BP container?

Shorter term,
  - Disable restarting container for <clustered-app-config> (set update-strategy="none"). However that would require a manual restart for changes to take.
  - Don't use <clustered-app-config> - read/watch the data in the app

Longer term 
   - allow <clustered-app-config> to be embedded in a <bean> as I mentioned before.