Post

3 followers Follow
0
Avatar

Possible to change dictionary value but not trigger update / delta

Hi,

We are adding a property to war.module. When this property is populated by a dictionary value it triggers a change therefore deploying the same war file. Is it possible for us to add a property to an existing war / type but not have it trigger an update?

I tried transient=true, but ti didn't seem to do it.

Thanks for any info!
Bernie

Bernie Bonn

Please sign in to leave a comment.

8 comments

0
Avatar

Just to add a little flavor. We have been experimenting with automating a wsdl refreshs for a package that contains over 30 services. In order to implement this I will need to create a dictionary that has a separate URI for each service, and we have this for numerous environments. Now say for example we need to change these URIs or maybe even the first time we create the dictionary, this will trigger a mass update of services that have not changed. I suppose you could argue that they have changed but it would be helpful in this case to not update. Just wanted to add a use case for a little clarity.

Thanks!

Bernie Bonn 0 votes
0
Avatar

Hi Bernie,

Let me fully understand your scenario first. Is the change to the dictionary causing an update on the deployed which causes a step to be generated? Or is the change to the dictionary not causing an update on the deployed but still causing a step to be generated?

In the former case, why would you not want a step to be generated? The property changed, so the deployed changed and that probably means the service has to be updated/redeployed, right? In what scenario would you not want the update to happen?

One solution I'm thinking of is to add a condition to the rule that causes it only to trigger if certain things have changed (or not changed). Would that work for you?

Regards, Vincent.

Vincent Partington 0 votes
0
Avatar

Hi Vincent,
Thanks for replying. I'll try to clarify.
We are trying to replace a manual step, that being a wsdl refresh that is done when a war (service) is deployed. The way we control it is to add a property for the wsdl uri in Jenkins. Then when the war is published up to XLD it has a placeholder in the property that will eventually get resolved by a dictionary. We have an XL rule that says when the war is created or modified, check to see if this URI property exists and is resolved i.e. that property exists, if yes, add the step in the deploy plan that refreshes the wsdl after the war is deployed and started.

This is all well and good. The issue I am having is that we are doing this sort of retroactively, and that means when I add these dictionary values a bunch of services that may be deployed will think they need to redeploy, which is not the case.

So I understand your point that it has changed so should be redeployed, but in this case it would cause a lot more time and disruption when the only thing that is different is we have added an ancillary step to the deploy, and not changed the deployable version at all.
My other concern with this configuration is if ops decides to make a mass change to these uri’s it will cause mass updates that are unnecessary.

Does this make sense, any ideas for a solution. Let me know if you would like to see the synthetic and the xl-rule and I’ll copy them in any other clarification you may need.

Thanks Vincent, I appreciate your help,
Bernie

Bernie Bonn 0 votes
0
Avatar

Hi again,
After reading my response I realized I may not have answered your questions.

Is the change to the dictionary causing an update on the deployed which causes a step to be generated?
--Yes the change to the dictionary is causing an update, which then triggers the XL rule that checks for the property we added, and if it exists adds the step.

"In the former case, why would you not want a step to be generated? The property changed, so the deployed changed and that probably means the service has to be updated/redeployed, right? "
--If for instance the service has already been deployed, we would consider this change to be metadata, that was added just to enable this step. A undeploy and a redeploy of the same version would be wasteful, especially in a time sensitive deploy with many components. Maybe tying the rule to the war was not the way to go, but we couldn't think of another way. So in this scenario we would never want metadata to trigger an update.

"One solution I'm thinking of is to add a condition to the rule that causes it only to trigger if certain things have changed (or not changed). Would that work for you?"
--I don't think so, the step the rule is creating is not the problem, it is the metadata we are using to trigger the rule and to efect the wsdl refresh that cause the unneeded updates.

Thanks Again Vincent, look forward to any information you can provide.
Bernie

Bernie Bonn 0 votes
0
Avatar

I thought I'd jump on because I see this as an extension of an existing problem for us.

We decided that in order to perform Layer7 WSDL refreshes we would extend wls.WarModule with additional properties. We've written an XL Rule that:
* Checks if the current operation is CREATE/MODIFY
* Checks if a specific wls.WarModule property (one that we've created by extending it) is not empty.

If those things are true, the rule will add a WSDL refresh step to the deployment plan.

We use dictionaries to drive the data into our custom property that the XL Rule checks for. The data itself is URI information about the Layer7 endpoint, which can change. When only the Layer7 properties change on a wls.WarModule it does not make sense to undeploy/redeploy the WAR file since it is the exact same one. We'd rather treat it is metadata that gets carried along with the type but that does not affect whether or not it gets deployed/undeployed, but it does not appear there is a way to do that.

Another approach we could have taken is to create another custom type for the Layer7 WSDL refresh. But that creates a different issue of relating a specific wls.War to this new type responsible for performing the WSDL refresh. This is the underlying issue I referred to -- there does not seem to be a great way to relate 2 deployeds to each other. XL Rules I think help bridge that gap, but what we end up with is a bunch of custom logic in the rule, which we'd like to avoid.

If we could mark a custom property as metadata that doesn't get taken into account when XLD is making the decision on if this type needs to be updated, then we could avoid custom logic in XL Rules and have it be a bit more standardized.

If there is an alternative to this that would also solve this for us, we'd love to work with you to understand how we could implement it.

Thanks!

Josh Figler 0 votes
0
Avatar

Hi Bernie, Josh,

Thank you for your answers. Explaining that this is about a Layer7 endpoint URL made me understand your use case. My apologies for not replying earlier. I was travelling. :-/

So if I understand you correctly, the problem is that an UPDATE delta is generated even though only a "metadata" property was updated. the This happens whether or not dictionaries are involved, so that is actually a not relevant for this question.

A few solutions that come to my mind are:

  1. Add a condition that causes the rule to not trigger if the Layer7 endpoint URL changed. But that would also cause the rule to not trigger if the Layer7 endpoint URL changed and some other property changed. If that does not happen, this might be a simple approach.
  2. Move the Layer7 endpoint URL to the package level (where orchestrators usually live). This only works is the Layer7 endpoint URL is the same for all WARs in the package. If some prefix of the Layer7 endpoint URL is the same for all WARs, you could split that property into a "Layer7 endpoint URL prefix" on the deployment package and a "Layer7 endpoint URL suffix" on the WAR deployables.
  3. Move the Layer7 endpoint URL to a separate CI. If the endpoint URL is the same for all WARs, this could be a global CI (in the Configuration or Infrastructure trees).

Is this line of thought going in the right direction?

Regards, Vincent.

Vincent Partington 0 votes
0
Avatar

Hi Vincent,

Thanks for your reply!

"So if I understand you correctly, the problem is that an UPDATE      delta is generated even though only a "metadata" property was updated. the This happens whether or not dictionaries are involved, so that is actually a not relevant for this question."

This is correct, the dictionaries was simply our implementation of a solution. We have a war file and some properties associated with it, we were hoping for a solution where we could 'mark' these as metadata and not trigger a delta, hence causing a war to redeploy when it doesn't have to.

I guess choice number 1 of those you presented would be the closest. I say that because the layer 7 urls are different for each war file deployed as part of the composite package.

You probably know, but we had a phone conversation with Rick Broker from Xebia this week, and I think he understands the issue quite well and is working up some options.

Thanks again Vincent!

Bernie Bonn 0 votes
0
Avatar

Hi Bernie,

Yes, I know Rick is working with you on finding a solution. Let me know when/if you need any further help from me. And I'd be curious to hear what ended being the solution you went for.

Regards, Vincent.

Vincent Partington 0 votes