Hi Ryan,

By looking at the change I'd have to update the AAA guides accordingly, but that's not a big deal.

Best regards,

David.

On mié, 2017-04-26 at 14:07 -0400, Ryan Goulding 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

[0] https://git.opendaylight.org/gerrit/#/c/56094/1/aaa-encrypt-service/src/main/resources/initial/aaa-encrypt-service-config.xml

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.

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

Hi David,

Unfortunately, this is going to be the easiest path forward for the initial Carbon release.  There will be work in Nitrogen to remedy this, and I have already opened an enhancement bug (8315) to track its progress.  This is a very strange scenario, and will require more thinking to tackle properly.

Thanks to all who have helped out with this;  I am still waiting for jenkins approval to merge.  Will keep an eye out for it and update appropriately.

Regards,

Ryan Goulding

On Wed, Apr 26, 2017 at 5:20 PM, David Suarez Fuentes <david.suarez.fuentes@ericsson.com> wrote:

Hi Ryan,

By looking at the change I'd have to update the AAA guides accordingly, but that's not a big deal.

Best regards,

David.

On mié, 2017-04-26 at 14:07 -0400, Ryan Goulding 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

[0] https://git.opendaylight.org/gerrit/#/c/56094/1/aaa-encrypt-service/src/main/resources/initial/aaa-encrypt-service-config.xml

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.

_______________________________________________
Odlparent-dev mailing list
Odlparent-dev@...ht.org
https://lists.opendaylight.org/mailman/listinfo/odlparent-dev