This group is locked. No changes can be made to the group while it is locked.
Date
1 - 15 of 15
[release] Help with karaf4 features for AAA
|
Robert Varga
On 26/04/17 15:26, Ryan Goulding wrote:
Hi Release team,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 :). Regards, Ryan Goulding
On Wed, Apr 26, 2017 at 9:59 AM, Robert Varga <nite@...> wrote:
|
|
|
|
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:
|
|
|
|
Robert Varga
On 26/04/17 16:23, Ryan Goulding wrote:
Thanks Robert. You mean that the Service is published here [0]? SoScratch 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:
|
|
|
|
Tom Pantelis
On Wed, Apr 26, 2017 at 10:48 AM, Robert Varga <nite@...> wrote:
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- 2017-04-25 20:37:05,195 | INFO | BundleDiagInfos] | TestBundleDiag
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
Robert Varga
On 26/04/17 18:35, Tom Pantelis wrote:
OK - that explains it. I assume it only updates the config data once onSo 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: 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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|