Network Reliability Engineering Community

jinja2.exceptions.TemplateNotFound: vqfx1.txt

Hello,

I am trying to build a stage 4 for the SaltStack lesson (lesson 30). However, when I try to load stage 4 on my local antidote instance, it gives me TemplateNotFound error.

The strange thing for me is that after multiple attempts, to test it out, I cloned the contents of stage 2 into stage 4 directory. The contents of stage2 loads but for the same content in stage 4, it gives me the following error.

Note: All the Error containers belong to stage 4.

NAMESPACE                NAME                                        READY     STATUS      RESTARTS   AGE
30-wuyckxkpciz4uvo1-ns   config-vqfx1-249md                          0/1       Error       0          11m
30-wuyckxkpciz4uvo1-ns   config-vqfx1-2tvh7                          0/1       Error       0          8m
30-wuyckxkpciz4uvo1-ns   config-vqfx1-56xwc                          0/1       Completed   0          14m
30-wuyckxkpciz4uvo1-ns   config-vqfx1-bdhnv                          0/1       Error       0          5m
30-wuyckxkpciz4uvo1-ns   config-vqfx1-dmkwj                          0/1       Error       0          11m
30-wuyckxkpciz4uvo1-ns   config-vqfx1-dtdtm                          0/1       Error       0          12m
30-wuyckxkpciz4uvo1-ns   config-vqfx1-dtmt7                          0/1       Error       0          10m
30-wuyckxkpciz4uvo1-ns   config-vqfx1-nhqql                          0/1       Error       0          9m
30-wuyckxkpciz4uvo1-ns   config-vqfx1-z2wnt                          0/1       Completed   0          16m
30-wuyckxkpciz4uvo1-ns   config-vqfx1-zxkts                          0/1       Completed   0          13m
30-wuyckxkpciz4uvo1-ns   salt1                                       1/1       Running     0          17m
30-wuyckxkpciz4uvo1-ns   vqfx1                                       1/1       Running     0          17m

More detailed logs for the stage 4 container:
skondvilkar-mbp:configs skondvilkar$ kubectl --namespace 30-wuyckxkpciz4uvo1-ns logs config-vqfx1-dmkwj
/usr/local/lib/python3.7/site-packages/paramiko/kex_ecdh_nist.py:39: CryptographyDeprecationWarning: encode_point has been deprecated on EllipticCurvePublicNumbers and will be removed in a future version. Please use EllipticCurvePublicKey.public_bytes to obtain both compressed and uncompressed point encoding.
  m.add_string(self.Q_C.public_numbers().encode_point())
/usr/local/lib/python3.7/site-packages/paramiko/kex_ecdh_nist.py:96: CryptographyDeprecationWarning: Support for unsafe construction of public numbers from encoded data will be removed in a future version. Please use EllipticCurvePublicKey.from_encoded_point
  self.curve, Q_S_bytes
/usr/local/lib/python3.7/site-packages/paramiko/kex_ecdh_nist.py:111: CryptographyDeprecationWarning: encode_point has been deprecated on EllipticCurvePublicNumbers and will be removed in a future version. Please use EllipticCurvePublicKey.public_bytes to obtain both compressed and uncompressed point encoding.
  hm.add_string(self.Q_C.public_numbers().encode_point())
NAPALM didn't catch this exception. Please, fill a bugfix on https://github.com/napalm-automation/napalm/issues
Don't forget to include this traceback.
Traceback (most recent call last):
  File "/configure.py", line 30, in <module>
    template_object = env.get_template(config_file)
  File "/usr/local/lib/python3.7/site-packages/jinja2/environment.py", line 830, in get_template
    return self._load_template(name, self.make_globals(globals))
  File "/usr/local/lib/python3.7/site-packages/jinja2/environment.py", line 804, in _load_template
    template = self.loader.load(self, name, globals)
  File "/usr/local/lib/python3.7/site-packages/jinja2/loaders.py", line 113, in load
    source, filename, uptodate = self.get_source(environment, name)
  File "/usr/local/lib/python3.7/site-packages/jinja2/loaders.py", line 187, in get_source
    raise TemplateNotFound(template)
jinja2.exceptions.TemplateNotFound: vqfx1.txt

Thanks @skondvilkar - I was able to replicate this on my end, will look into this.

This is a bug in Syringe. I opened https://github.com/nre-learning/syringe/issues/111 to track this, and I’m hoping to have a chance to fix this later today.

In the meantime, a viable workaround to getting you moving forward could be to provide SYRINGE_LESSON_REPO_REMOTE to the syringe deployment. You can run kubectl edit deployment syringe to do this. See the docs for the three git-related variables you have to play with. What you’ll have to do is commit and push your changes to your fork before reloading syringe to get them to show up. It’s a bit of a pain for now, but will get you moving forward with content.

However, I will obviously fix this bug so you can get back to the local directory workflow which is much more convenient, so please subscribe to updates on that issue, I’ll be providing further updates on progress there.

Thanks, @mierdin. :slight_smile:
I will go ahead with this until it’s fixed.

Actually it’s not a Syringe bug at all - it’s a problem with the manifest for deploying Syringe in selfmedicate. We moved to using a new env var name for controlling whether to use local directory or Git, and the selfmedicate manifest didn’t get updated.

I just updated it so you should be able to run the following commands in the selfmedicate repo to fix it:

git pull origin master
kubectl delete deployment syringe
kubectl create -f manfests/syringe-k8s.yaml

This will automatically start a new Syringe pod with the correct environment variable set, and your local content should be available.

@skondvilkar
Thanks a lot Matt @mierdin . Its working now.