Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request about usage #54

Open
misch42 opened this issue Jan 5, 2019 · 4 comments
Open

Request about usage #54

misch42 opened this issue Jan 5, 2019 · 4 comments
Labels
Milestone

Comments

@misch42
Copy link

misch42 commented Jan 5, 2019

Hi,

I followed you setup in the README. A
salt 'mydevice' test.ping
works. Also all functions work. Nice work. Thanks.

But when I want to test a state, I get an error. According to the doc I add the ntp.peers to the device pillar:

cat /srv/pillar/mydevice.sls
proxy:
proxytype: napalm
driver: junos
host: 192.168.1.2
username: admin

ntp.peers:

  • 192.168.1.1

The answer of salt is:
salt 'mydevice' state.sls mydevice.ntp
mydevice:
Data failed to compile:

No matching sls found for 'mydevice.ntp' in env 'base'

Any idea, what I got wrong?

Michael

@misch42
Copy link
Author

misch42 commented Jan 5, 2019

salt -V
Salt Version:
Salt: 2018.3.3

Dependency Versions:
cffi: 1.11.5
cherrypy: Not Installed
dateutil: 2.6.1
docker-py: Not Installed
gitdb: 2.0.3
gitpython: 2.1.8
ioflo: Not Installed
Jinja2: 2.10
libgit2: 0.26.0
libnacl: Not Installed
M2Crypto: Not Installed
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.5.6
mysql-python: Not Installed
pycparser: 2.19
pycrypto: 3.7.2
pycryptodome: Not Installed
pygit2: 0.26.2
Python: 3.6.7 (default, Oct 22 2018, 11:32:17)
python-gnupg: 0.4.1
PyYAML: 3.12
PyZMQ: 16.0.2
RAET: Not Installed
smmap: 2.0.3
timelib: Not Installed
Tornado: 4.5.3
ZMQ: 4.2.5

System Versions:
dist: Ubuntu 18.04 bionic
locale: UTF-8
machine: x86_64
release: 4.15.0-43-generic
system: Linux
version: Ubuntu 18.04 bionic

@mirceaulinic
Copy link
Member

mirceaulinic commented Jan 7, 2019

Hi @misch42.

It is probably good to have the following distinction in mind: data goes into the Pillar, automation logic does into the State files (+ templates, when applicable). In the above you have correctly defined the Pillar data, however the State file is missing: when you execute state.sls mydevice.ntp, the State system is looking for a file named ntp.sls, under a directory named mydevice, physically located under one of the file_roots paths on the Master.

For example, if you have the following configuration on your Master:

file_roots:
  base:
    - /srv/salt
    - /srv/salt/states

If you place this State SLS file: https://github.com/napalm-automation/napalm-salt/blob/master/examples/router/ntp.sls under /srv/salt/states/ntp.sls you should be able to execute: salt 'mydevice' state.sls ntp.

@mirceaulinic mirceaulinic added this to the Discussion milestone Jan 7, 2019
@misch42
Copy link
Author

misch42 commented Jan 7, 2019

Thanks. That was the problem. But I think it will be easiery to work with formulas (napalm-ntp-formula) in real deployments.

@mirceaulinic
Copy link
Member

I agree, the napalm-ntp-formula is probably the best (and in similar ways with anything else). The native NTP State is good enough, but can fall short in some particular cases, and it may be deprecated at some point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants