Does changing a node line in router.db always have to destroy the version history ?

[airbear-thebear]

If I make a simple change to a node - eg. to override the default username, I lose the change history for that node!

[ytti]

No that shouldn't happen. We only care about the node name and we never delete old nodes.

[danilopopeye]

I lose the change history for that node!

have you restarted oxidized or just issued a reload?

[ytti]

I guess we interpreted 'version history' differently. I interpreted as git versions. But I feel like @danilopopeye interpreted as runtime stats.

Runtime stats are currently lost every time nodes are loaded. We should have runtime state in sqlite instead of memory, but when will that happen is another story.

[airbear-thebear]

Thanks, obviously, my terminology was a bit crappy. The issue for me is that, if I reload nodes and there is any change to a node line, then the version history through the web interface is emptied.

The git repository retains the history as expected.

I guess what I am looking for is an on-premise web interface to the git repository. Would getting oxidized to push to gitlab be the best approach, or is there something better?

[ytti]

My preferred solution is gitlab for sure. But almost every organisation already has something, gitlab, github, stash, bitbucket..., if you already have something, it makes most sense to use what you have.

If you don't have anything, I'm surprised (where do you keep your stuff man:), install gitlab.

[danilopopeye]

The issue for me is that, if I reload nodes and there is any change to a node line, then the version history through the web interface is emptied.

maybe we should investigate a little more and fix the oxidised-web too? 😄

could you post some screenshots to exemplify your issue?

[airbear-thebear]

I have attached some screenshots, but it's really very simple.

First I ran with a single node for a while, using node file "before_router.db.txt".
Then I took screenshot "before_conf_change.PNG".
Then I changed router.db to override the default value for username with the same value, see file "after_router.db.txt".
Then I reloaded nodes.
Then I took screenshot "after_conf_change.PNG"

I have also attached config and oxidized log and output from `git log'.

Unfortunately, my evidence doesn't show it but, any unchanged node lines are unaffected.

after_router.db.txt

before_router.db.txt
config.txt
gitlog.txt
oxidized.log.txt

[ytti]

I think the problem is the '/' in start of the name. This causes node to be 'nil' and group to be 'testnode'.

[airbear-thebear]

I see. That's probably my bad nginx proxy config. It's not coming from the node config. I'll test around that and let you know.

[ytti]

I seriously suspect you'd rewrite the node name in query, it's probably problem in oxidized-web. But I can't be arsed to look for it now.
I'm guessing you'll get list of devices, and in that list of devices, after reload, the node name is prefixed with '/'?

[danilopopeye]

@airbear-thebear any update?

[airbear-thebear]

Hi,
It seems that changing the username field is also changing the group field. The update/change history is persistent but, I am simply seeing a different history for the same node, in a different group.
I believe this is pretty much what ytti suspected would be the problem?

The below was taken with my browser connecting directly to Oxidized-web (no NGINX).

So, here's a recap on the config:

source:
  default: csv
  csv:
    file: /home/oxidized/.config/oxidized/router.db
    delimiter: !ruby/regexp /:/
    # Here we are setting variables based on CSV columns:
    # ie.  name = col0, model = col1 ...
    map:
      name: 0
      model: 1
      group: 2
      username: 3
      password: 4
      input: 6
    vars_map:
      enable: 5

Here is router.db:
default_username_router.db.txt

Here is what the overview looks like:

Here is the history for node "csw01":

Now I put a value in the username field for node "csw01":
username_router.db.txt

I reload nodes and refresh. Now the nodes overview changes:

And we see a (persistent) but different history for node "csw01":

Changing the config back to use an empty username field will return the node to the "default" group and restore the update history.

[ytti]

Your problem:

[ytti@ytti.fi ~]% pry
[1] pry(main)> "bigip-01:tmos::username:password::".split(":")[2]
=> ""
[2] pry(main)> "bigip-01:tmos:::::".split(":")[2]
=> nil
[3] pry(main)>

This relates to issue #500. We don't have clear way to specify

1. I have value, but it is empty
2. I have value, and it is not empty
3. I do not have value

Now after you add username and password, the 'missing' fields become 'has value, empty'. Before adding them, they are 'no value'.

I'm thinking of adding 'pseudo types', so you could populate them with nil to indicate lack of value. Or something similar if other people have another solution for #500

Right now, you could solve your problem by changing the mapping order, so group is after username/password. Or just remove group, as you don't seem to use it.

[ytti]

To put that plainly, after you specify username:password, you accidentally also specify group, which happens to be empty string.

We will fix the behaviour, unsure how yet. Probably in a way where you need to enter 'nil' or 'false' in fields without value. And :: will be empty string.

But in mean time, either remove group mapping if you don't use it, or juggle them around for desired effect.