centralized hostname

[egarnel]

Would it be possible to have a centralized hostname table in the db in which the plugins could refer to?

This way, It would be easy just to add devices into the plugins instead of adding devices AND hostnames.

or better yet, have the ability for plugins to pull the devices directly from the host table and thus saving time & typing by not having to add devices into plugins manually each time.

Thanks

[streaker69]

I like this idea as well. Between the basic cacti functionality and then setting up Manage and MacTrack you're duplicating the same entries all over the place.

Also wouldn't it save something in the overall execution of Cacti? It wouldn't have to poll so many different tables to get HostName for the various plugins.

[egarnel]

Agreed. I thought I was just trying to be lazy, but you make some very valid points.

[gilles]

manage use the host table for hostname, description etc...
manage doesn't recreate these values

[streaker69]

manage use the host table for hostname, description etc...
manage doesn't recreate these values

Yeah, I remembered that after I posted it.

[TheWitness]

This is an important topic. We need to also merge Sites and Groups as well. Frankly, when I wrote MacTrack, it was before Plugins really too off. So, now I wished theses things had been in the core sooner.

We should all agree and then move in that direction.

TheWitness

[Howie]

Just while it's being discussed again, I'd like to be able to add arbitrary properties to a host. I'm mainly thinking in terms of things like the customer account number from our internal provisioning database, or the node id from What's Up Gold. Things that would allow other plugins to tie data in Cacti into other systems.

Of course, if it meant you could add notes, or open RT ticket numbers or whatever to a host too, that'd be cool.

And if you could do access control based on one, then I could just give a customer a login, and access to all hosts where resellerid=33, and then as new systems come online, I set that property to 33 and everything 'just works'.

I guess something similar for users would help too, in this respect.

But you know, done generically, in your spare time

Seriously though, I think a user_properties, and host_properties table, like the settings table but with a host_id or user_id in them would go a long way. If it had a UI to make those things visible, then all the better, but you could argue that that is the job of the plugin that understands the value (so a device_form_ui hook would be the right thing). Which almost gets you back to the current situation where each plugin adds it's own values to it's own table, but it seems nicer if it was a central location - maybe plugins could share then, more.

[Howie]

Clearly my brain wasn't fully engaged this morning

[TheWitness]

Hmm, I think you are on to something though. If we use a more row based information store, then as you said, you would not be required to add to the hosts table columns.

Therefore, you would have four fields in this table: host_id, plugin_id, column_id, and value.

Then, Cacti could display this arbitrarily, and/or transpose it into column. In any event, you would certainly be able to query against it. Control of display would remain the function of the plugin.

That aside, I would like to take a poll as to what additional fields shold be considered as a part of the main table, and what tables should be common.

I'll start it.

Common Tables with some arbitrary columns TBD
Sites
Groups
User Groups

Additional Fields:
Users - e-mail
Users - Last Name, First Name
Users - Domain (although e-mail could be the primary key to link gather additonal information.

Host - uptime, last_uptime

[egarnel]

oooh, I like it when I cause trouble!

[rony]

Before implementation, discussions are good.

But, we have to take into account the changes in 0.9.0 and how they support just what you are asking for...