search

dropbox / nsot

Network Source of Truth is an open source IPAM and network inventory database
https://nsot.readthedocs.io
Other
399 stars 66 forks source link

Expiry field on resources #159

Open coxley opened 8 years ago

coxley commented 8 years ago

In the world of automation, no looking back, moving fast and breaking things it greatly simplify extra work to have an expiry field on resources. This is a datetime field that renders a resource as either orphaned and easily reportable, hidden and ready to overwrite, or deleted - I mostly lean toward the former.

An example use case would be running a periodic job to push updates to NSoT about a resource, either from local server or EC2 or anything, that gets decommed suddenly and letting it be cleaned up nicely.

jathanism commented 8 years ago

Can you explain why you think this should be a hard Resource field vs. an Attribute? I'm not fully understanding, but on a related note I had considered at one point adding created and modified datetime fields to all Resources, which is more generic but could potentially indicate the same type of intent?

Eh?

coxley commented 8 years ago

I guess my thought was to write less code against polling every interface looking for a expiry attribute to have it done server side. Totally doable though and if not everyone has the use case probably not worth putting in.

coxley commented 8 years ago

Polling every resource, not interface

jathanism commented 8 years ago

I don't think it's a bad idea, but I would like to make sure we've thought about the generic use-cases, especially if that means we want all resources to have a concept of expiration, and how that is represented both at the database level and from within the API.