Feature Request: description field

[bradvido]

Since the "name" field is used as a unique identifier for the devices, it would be nice to have another field to describe the device, which could change without altering the device identity.

[ytti]

Where would you display it and for what purpose? Use case might help.

You can already pass arbitrary variables from sources to the node via vars_map

[bradvido]

Ideally, it would be displayed in oxidized-web. I submitted the issue here because I'm assuming the data structures live here and the web interface is just presentation.

[ytti]

I'm not against this, and I can do the oxidized part, it's extremely easy. However, it would be cool, if we we'd rather figure out acceptable way to display vars in oxidized-web, this way your use-case and any other arbitrary future variable would be supported.

However, I'm not sure if this is such an easy task, because you probably don't want some vars blob in the oxidized-web, which you need to click open to see what vars there are.
Or should all vars be columns in the table?

[bradvido]

All vars in the columns table, and hidden by default seems reasonable to me.

Doing this would make this issue a higher priority (remembering last column layout on reload): ytti/oxidized-web#31

[ytti]

W000, then my work is done! :>

Someone just needs to expose that in oxidized-web, all the vars are available via #Node.vars as a hash.

[bradvido]

Can you give a hint as to where to start? I'll take a stab

[ytti]

For example the nodes list is here: https://github.com/ytti/oxidized-web/blob/master/lib/oxidized/web/webapp.rb#L34-L46

The view is here: https://github.com/ytti/oxidized-web/blob/master/lib/oxidized/web/views/nodes.haml

In the view @data contains list of nodes. You could iterate it with something like this:

@data.each do |node|
  # node is individual node
  node.vars.each do |name, value|
    # name is name of the variable
    # value is the value of the variable
  end
end

[laf]

@bradvido Did you manage to look at this?

[no-response]

This issue has been automatically closed because there has been no response to our request for more information from the original author. The information that is currently in the issue is insufficient to take further action. Feel free to re-open this issue if additional information becomes available, or if you believe it has been closed in error.