Correct Procedure for 're-deploy reconcile'

[Koji Yokoe]

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?

[Jan Lindblad]

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.

[Koji Yokoe]

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

[Koji Yokoe]

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 {
                  }
              }
          }
      }
  }

[Jan Lindblad]

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

[Koji Yokoe]

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.

[Jan Lindblad]

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.

[Koji Yokoe]

Hi Jan.

Thank you for the explanation.

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

Koji Yokoe

[Koji Yokoe]

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.

[Jan Lindblad]

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

[Koji Yokoe]

Hi. This is a very old topic, but I think I finally understand why following happened.

> 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.

NSO manual "NSO Development" Chapter 10. Developing NSO Services shows following example

admin@ncs(config)# devices sync-from
admin@ncs(config)# services vlan v1 description v1-vlan iface eth1 unit 1 vid 111

At this moment, Refcount is 2 like this.

! Refcount: 2
! Backpointer: [ /ncs:services/vl:vlan[vl:name='v1'] ]

Then
admin@ncs(config)# services vlan v1 re-deploy reconcile

It makes Refcount 1 like this.

! Refcount: 1
! Backpointer: [ /ncs:services/vl:vlan[vl:name='v1'] ]

In this example, "services vlan v1" DID NOT exist in NSO.
So first "services vlan v1" was deployed and then "re-deploy reconcile" was executed.

In our case, "service" DID exist in NSO.
But device config didn't exist for some reason (YANG Data changed after NED update).
So
(1) sync-from
(2) re-deploy (this is service deployment which already existed in NSO)
(3) re-deploy reconcile
After (2), Refcount becomes 2.
After (3), Refcount becomes 1.
So deleting service DOES delete config.