cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
603
Views
0
Helpful
9
Replies
Cisco Employee

Correct Procedure for 're-deploy reconcile'

Hi.

Is this the correct procedure for 're-deploy reconcile' ?

- First 're-deploy'

- Then 're-deploy reconcile'

 

Following procedure didn't make expected result.

(1) sync-from

(2) re-deploy reconcile

After (1), config doesn't have Refcount.

After (2), Refcount becomes 2.

So deleting service doesn't delete config.

 

Following procedure made expected result.

(1) sync-from

(2) re-deploy

(3) re-deploy reconcile

After (1), config doesn't have Refcount.

After (2), Refcount becomes 2.

After (3), Refcount becomes 1.

So deleting service DOES delete config.

 

So 're-deploy' before 're-deploy reconcile' is required?

9 REPLIES 9
Cisco Employee

Re: Correct Procedure for 're-deploy reconcile'

Normally you would not need the first re-deploy; one re-deploy reconcile should do it. The fact that this is not the case in your setup is interesting. It suggests that your service code is doing different things the first and second times it runs. Is the service code reading the existing configuration in any way and reacting to what it sees (using e.g. an if-statement)?

 

Running your re-deploys with the dry-run flag should tell you what the code does at each invocation. See any differences between the two?

 

Another factor that may play a role in this is configuration that exists on the device sitting below the config created by the service. If you play with the re-deploy flag discard-non-service-config in dry-run mode, you might be able to catch something that's missing in your service template.

 

 

Cisco Employee

Re: Correct Procedure for 're-deploy reconcile'

Hi Jan.

Thank you for your kind advice.

I really appreciate it.

I'll try it.

If I find something, I'll tell it to you.

 

Koji Yokoe

Highlighted
Cisco Employee

Re: Correct Procedure for 're-deploy reconcile'

Hi Jan.

I tried it.

But all the following cases created the same result

 

1. "re-deploy dry-run" only

2. 1st "re-deploy", then "re-deploy  reconcile { } dry-run"

3. "re-deploy  reconcile { } dry-run" only

4. "re-deploy reconcile { discard-non-service-config } dry-run" only

 

All of the results were as follows.

 

cli devices {
          device router1 {
              config {
                  ios:vrf {
                     definition VRF1 {
                      }
                  }
                  ios:ip {
                      access-list {
                          filter-list Tunnel_ACL_VRF1 {
                          }
                      }
                  }
                  ios:policy-map QoS_VRF1 {
                  }
                  ios:interface {
                      Loopback 1000 {
                  }
              }
          }
      }
  }

 

Cisco Employee

Re: Correct Procedure for 're-deploy reconcile'

What does your template(s) for this look like, or code if you're not using templates?

 

Cisco Employee

Re: Correct Procedure for 're-deploy reconcile'

Hi Jan.

Thank you for the prompt reply.

We are using templates.

Since this is customer's template, I'll share it with you offline.

I don't think this public site is good for sharing.

Cisco Employee

Re: Correct Procedure for 're-deploy reconcile'

Thank you for sharing the templates. I see nothing wrong in them, but I do see one difference compared to how I usually write them. This difference also seems to be possibly related to the odd thing I see in your output.

 

When you run re-deploy (all variations) you get a lot of output, but no + or - signs that anything is added or removed. Normally when you run re-deploy, it would either not give any output at all (just cli { }) or there would be at something added or removed at the center of all subtrees listed. I don't see that here. Odd.

 

This makes me think the diff engine and the template don't understand each other well, somehow. Which brings me back to the difference in style I saw in the templates. Just to see if it would make any difference, could you try the following?

 

In many of the templates, there is a line <config tags="merge">, like here:

 

<config-template xmlns="http://tail-f.com/ns/config/1.0">
  <devices xmlns="http://tail-f.com/ns/ncs">
    <device tags="nocreate">
      <name>{$DEVICE_NAME}</name>
      <config tags="merge">
        <!-- VRF -->
        <vrf xmlns="urn:ios">
          <definition>
            <name>...</name>

 

Could you try changing this in some template that is being used in your test case so that instead the tags="merge" is on the actual YANG lists:

 

<config-template xmlns="http://tail-f.com/ns/config/1.0">
  <devices xmlns="http://tail-f.com/ns/ncs">
    <device tags="nocreate">
      <name>{$DEVICE_NAME}</name>
      <config>
        <!-- VRF -->
        <vrf xmlns="urn:ios">
          <definition tags="merge">
            <name>...</name>

...

        <interface xmlns="urn:ios">
          <Loopback tags="merge">
            <name>...</name>

 

Note that this tags="merge" would be removed from one location, but added in many locations inside the <config> tag; each of the YANG lists inside the config tag.

 

Try this for one template and see if there is any difference in behavior.

 

Cisco Employee

Re: Correct Procedure for 're-deploy reconcile'

Hi Jan.

Thank you for the explanation.

I'll try it, and get back to you.

 

Koji Yokoe

Cisco Employee

Re: Correct Procedure for 're-deploy reconcile'

Hi Jan.

I tried it, but Refcount is still 2.

Anyway, if 're-deploy' and then 're-deploy reconcile' can be a workaround, I'm satisfied with it.

Cisco Employee

Re: Correct Procedure for 're-deploy reconcile'

I'm of course happy that you're satisfied, but there is something not working quite right here.