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

Config file shims #8

Open
MatthewHink opened this issue Nov 19, 2018 · 6 comments
Open

Config file shims #8

MatthewHink opened this issue Nov 19, 2018 · 6 comments

Comments

@MatthewHink
Copy link
Contributor

modbus and snmp plugins are using the config.yml in the from the modbus and snmp repos and not the config.yml shimmed in here.

This is related to this mega-commit: https://github.com/vapor-ware/deployment/commit/f74a3e30c6b939663bb5218325fac1d199dc5cb2

vapor@basx-vec1:~/src/deployment/site/oregon/redmond$ kubectl exec -it aspiring-clownfish-modbus-56bd6d54c9-jfn59 -- /bin/sh
/plugin # cat config.yml
version: 1.0
debug: true
network:
  type: tcp
  address: ":5004"
settings:
  mode: serial
  read:
    interval: 10s
    serialReadInterval: 1ms # This config is from the plugin config.yml, not the deployment config.yml
  write:
    interval: 2s
@marcoceppi
Copy link
Contributor

Is /etc/synse/plugin/config a directory in the container and does it have a config.yml file in it? If so is it right? Can you run pwd from that container and ls -lah this looks like the file is just not in the right path

@MatthewHink
Copy link
Contributor Author

/etc/synse/plugin/config/config.yml is in the plugin. The plugin is loading the config from /plugin.

This is either:

  • A config loading issue in the sdk due to whatever changes were made there.
  • A symptom of existing plugins having a config.yml in the root.
vapor@basx-vec1:~$ kubectl logs aspiring-clownfish-modbus-56bd6d54c9-jfn59
time="2018-11-19T21:58:44.679Z" level=info msg="[sdk] found config files" configs="[config.yml]" path=/plugin
time="2018-11-19T21:58:44.68Z" level=info msg="[sdk] plugin config: {\"Version\":\"1.0\",\"Debug\":true,\"Settings\":{\"Mode\":\"serial\",\"Listen\":{\"Enabled\":true,\"Buffer\":100},\"Read\":{\"Enabled\":true,\"Interval\":\"10s\",\"Buffer\":100,\"SerialReadInterval\":\"1ms\"},\"Write\":{\"Enabled\":true,\"Interval\":\"2s\",\"Buffer\":100,\"Max\":100},\"Transaction\":{\"TTL\":\"5m\"},\"Cache\":{\"Enabled\":false,\"TTL\":180000000000}},\"Network\":{\"Type\":\"tcp\",\"Address\":\":5004\",\"TLS\":null},\"DynamicRegistration\":{\"Config\":[]},\"Limiter\":null,\"Health\":{\"UseDefaults\":true},\"Context\":{}}"
time="2018-11-19T21:58:44.68Z" level=info msg="[sdk] found config files" configs="[/etc/synse/plugin/config/device/config.yml]" path=/etc/synse/plugin/config/device```

@marcoceppi
Copy link
Contributor

It seems we should just have the charts write to /plugin then? @edaniszewski

@MatthewHink
Copy link
Contributor Author

I think that's the way it used to work, then things got changed around in that big checkin. It could be an order of preference way that the configs get loaded in the sdk (?)

@MatthewHink
Copy link
Contributor Author

It's more complicated than it needs to be and was not tested prior to checkin / merge.

@edaniszewski
Copy link
Contributor

This seems to be a symptom of the way the SDK loads configs. It is actually pretty well tested, but this case slipped through because the images it was tested on didn't have a plugin config included within the docker image by default. I believe modbus (and maybe snmp too) had the configs copied into the dockerfile when the project was first being set up to make development easier, and then they were never removed.

The SDK will try to load plugin configs in the following order:

https://github.com/vapor-ware/synse-sdk/blob/ee3e84f602c74c6e499a36f7f58916f08eeb74b6/sdk/reader.go#L22

here . evaluates to /plugin because that is where the plugin is being run from in the docker image.

The way we were previously doing it in the deployment configs was to mount the configs to some other path that is not on the default search path, and set an environment variable to point to it. We could do that again, but it does add more complexity to the deployments (need to define and track more things) when the SDK can handle it using the default search paths.

The easiest way to fix this would be to update the dockerfile for each image to remove the part where the plugin config is copied in -- this will require us to specify our own plugin config (will fail if no config is provided), but we are already doing that.

@hulksmaaash hulksmaaash added this to the Objective 6 Completion milestone Apr 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants