Sonatype CLM Server - Policy Management

By now, we should know that an easy way to look at conditions is to consider them the if part of an if/then statement. In contrast, a constraint is not part of the statement, but rather a container for conditions. This can come in real handy when you want to consolidate a policy, by grouping similar conditions.

But why do this?

Well, for one thing, it reduces time. Next, because constraints are displayed on the application composition report, along with violations, it becomes easier for a member of your team to process information that is similar. Of course, it also has the added benefit of not having to create hundreds of small, one-off policies.

For example, in our Architecture Age and Quality policy, we may start with two conditions, one for age and one for popularity. This will work, but it’s likely better, especially if we want to expand that later on, we isolate these as separate constraints.

As a good practice, grouping similar conditions is the best way to build your constraints. Again, this will help de-clutter a multi-policy environment, as well as help someone reading any associated violations on the application composition report. For our example, we’ll be placing both conditions in the same constraint.

Now, before we move on, let’s take a look at some of the specific aspects of conditions that can tend to be a bit confusing.

Policy Type. Sonatype CLM has an algorithm for determining the type of policy you created. This type is based on the types of conditions you include and is mainly used in reporting purposes. For example the trending report aggregate the different policy types into separate lists. The rules to determine the type of a policy are:

Any vs. All. If a component meets any constraint, the policy is considered violated. However, inside each constraint, when you have more than one condition, you have the ability to require that a component must either meet all conditions or just any of the conditions to trigger a violation.

This is a straightforward concept, but it can produce vastly different results. For example, selecting Any as an option will tend to produce a lot more violations, it’s the equivalent of placing an or between each condition. In addition even if you resolve one violation for a component, if the component meets other conditions later on, it might cause it to still violate the policy. On the other hand, using All' allows you to establish that all conditions must be met. It’s like placing an and between each condition. In this case, if you address any of the conditions, the violation will be resolved.

Let’s look at an example that would further explain this, and then we will move on to creating conditions in our policy. Below, we have a couple of policies and a component. If we wanted to exclude components that were younger then four years and had less than fifty percent popularity, which would we want to use? Also, would the component listed violate this policy?

It may seem like these two policies are exactly the same, but there is a key difference, Any vs. All. So, our first policy states that if Any of the conditions are met that a violation will occur. Given that, our component violates this policy. This is good, but we only want a component to violate a policy when Age is less than three years, and popularity is below 50%. We understand that there may be circumstances where a component might need to fall outside one of those boundaries, but if it’s both, we know we have a problem. Our component is pretty popular, so it might be a case where this component, even though it is newer than we prefer, actually resolves an issue another component might have. For this reason, the best policy for us to choose is Policy 2, and our component would not actually cause a violation.

Now that you know about all the available conditions and how they can be combined to match all or any condition to create a constraint we are ready to determine what should happen if a constraint is met - the policy actions.