Support for support contracts

[netman2048]

It would be useful for the DCIM portion of Netbox to be able to add support contract info to a device. The contract number, SLA (4 hours, NBD, etc) term start, term end, alarms (dashboard and email) when a contract is getting close to expiring, etc.

[shakalandy]

This would really be a great addition to the already existing feature set.

[peelman]

This should be a one->many relationship, and not just a set of fields on the device. If you do recurring support contracts you can have multiple contracts associated with a given device. Bonus points for including the cost of said contract for said device (leading towards a TCO calculation for a device)

[peelman]

Proposed Fields for SupportAgreement:

• devices (many-to-many table)
• description (eg. smartNET, JCore Plus, etc)
• service_level_agreement (freeform)
• issue_date
• expiration_date
• issued_by (the device manufacturer might not be the one warrantying a device)
• registered_to (ever have a company you work for change names? know who the warranty-er thinks owns the device is useful)
• agreement_identifier (usually a number, but could be alphanumeric)
• notes (long-form, for those times when even custom fields can't cut it)
• cost

Anybody want to add to that list or debate any of those?

Some considered fields that require other things NetBox doesn't have or do yet:

• Purchase Order Number (or some other accounting-type reference)
• Attachments (maybe you want to attach a PDF of paperwork, etc)
• Company reference instead of simple issued_by text field (see my comment here)

[rblayzor]

Recommendations....

Duration and expiration are probably redundant? Why not just have a "start_date" and "end_date" ? (replacing issue_date with start_date)

Response_time should be "sla".

Also instead of "registered_to" you can probably FK that to Vendors / providers?

[ryanmerolle]

SLA could include combinations of the following depending on the vendor:

• Service Level:
  • onsite
  • remote support and parts/RMA
  • remote software support without parts/RMA
• Response Window 1
  • Next Business Day
  • Same Business Day
• Response Window 2
  • 24x7 including holidays
  • 24x5 including holidays
  • 24x5 no holidays
• Response time
  • 4 hours
  • 2 hours
  • x hours

For duration vs end date, I would recommend a current term end date with some sort of support event journaled to the record that would log previous support events changing service levels, renewals, etc.

Given how support contracts are often setup in groups, we definitely need a way to link a master contract to to multiple devices that inherit the SLAs and etc.

[peelman]

@rblayzor I think I actually crossed some wires on duration.

i avoid acronyms in model names, but the SLA suggestion is noted. @ryanmerolle has nice suggestions there. SLA has a lot of considerations

We don't have Vendors/Providers yet. See my third bullet point under "considered field" (and the linked comment).

He also makes a good point about applying to groups of objects instead of the singular.

[peelman]

@ryanmerolle After a little more looking and poking this morning, I don't think it feasible to keep creating buckets. Hell, no two warranty offerings from a company are consistent enough to make it feasible, let alone trying to shoehorn options provided by every vendor.

I currently leaning towards a free-form field with some auto-complete javascript that suggests previously entered answers.

[rblayzor]

Perhaps it's getting over complicated and should be more simplified and just add a couple of fields to the actual device like; "warranty_end". Warranty could be anything; mfg warranty, service agreement, etc. It would just be nice to pull a report on all your devices for anything expiring warranty by X. I think that would be incredibly helpful.

[peelman]

This should be a one->many relationship, and not just a set of fields on the device. If you do recurring support contracts you can have multiple contracts associated with a given device. Bonus points for including the cost of said contract for said device (leading towards a TCO calculation for a device)

[jeremystretch]

I'm not sure this is a great fit for NetBox. Other than pointing to an installed device, I don't see much overlap with NetBox data. I could be missing something, but it seems like all of the data defined above could easily be maintained in a separate system and linked to in a custom field within NetBox (or alternatively linked to in the reverse direction using a device name).

[rblayzor]

I think it would be a great fit in a simple form. (not getting overly complex). It seems like Netbox has all the makings of an "Asset Manager" as well. There is a lot of overlapping data that appears in Netbox compared to what would be provided in just a simple asset management system; with the exception of just a few minor missing fields. Obviously I don't think you want to bog things down with adding too many fields and trying to solve all the worlds problems.

Another option may be to just explore adding custom fields in database tables that can be represented and changed, much the way RT can do that with tickets.

[dswebbthg]

I just want to second rblayzor in saying that I think the DCIM portion would be greatly enhanced by a many to one relationship with a support provider (much like you have with circuit providers). doing it in the notes field or some other field (without a parent / child relationship) would be a huge pain when you need to change the support details across many devices.

[ryanmerolle]

@jeremystretch, yea my view is that this would help your ops teams with understanding what is under support when incidents happen. It also allows you to pull up support contact and SLA details linked to a device. It creates slippery slope into IT Expense Mgmt and more expansive DCIM/Assest Management.

[netman2048]

I personally don't think I would need anything horribly complicated. Like I said in the initial post, contract number, SLA type, begin and end dates, and the ability to set a notification X days from expiration of the contract. I wouldn't care if it was baked in or module based.

[rfdrake]

Maybe they could add hooks for a plugin system so you could write this as a separate module?

[alexjhart]

File Attachments are a must for this in my opinion. Looking forward to developments for this issue.

[candlerb]

The one place where direct integration with DCIM makes particular sense is spares inventory (related: #198). You have a spare device and it has a manufacturer, device type, serial number, an asset tag etc; and it's something that you want to be able to move from a spares pile into live service and vice versa. That requires tight integration with DCIM.

However, I can sympathise with the view that support contracts should be a separate application. If so, I would still like it to be something which can integrate easily with Netbox, for example accessed using the same authentication.

Netbox is already very modular, with /ipam/, /dcim/ etc, so explicit support for external plugin modules would be great. They would at least need to hook into the top-level menu bar.

Plugin modules should be able to maintain their own database tables, without stomping on the migrations mechanism for the core.

[djzort]

Could simple PO # and PO data fields be added, as an interim for someone creating a highly featured support contract system?

[jeremystretch]

This needs a firm outline of proposed models and views before it can get anywhere. Running code isn't necessary, but we need at least a mock up that people can comment on and (hopefully) reach consensus.

[djzort]

The most general case to be able to add custom meta data (key value pairs) for each device type. I whipped up a quick screen mockup in the gimp based on the django admin interface (linked above) of the device type page. In it, you can add add the key "name" and the value "type". Which i suggest as text, currency, integer - other obvious ones are time, date, datetime, etc. It could all just be text, but a little overlay wouldnt hurt.

[djzort]

I dont know why gimp put green edges on the custom metadata title text, it wasnt intentional and i wasnt bothered to fight with it. But on the plus side its highlighting the section i have added.

[djzort]

i would add, that the above is more or less identical to the "attributes" functionality in RackTables - although in racktables you declare them globally. then apply them to device types. I guess in this way its implicit that they are the same "thing" across devices and are therefore comparable

[alexjhart]

Will this include support for circuits as well as devices? Very similar things need to be tracked for them as well.

[th3goose]

I'm of the personal opinion that support contract management is outside the scope of netbox, but it does make sense to maybe add a few optional fields for circuits and hardware that makes reference to a support contract number. I am actually getting this implemented in our asset database for my day job (which won't be based on netbox, sad as it may be) and helps finance and operations understand what hardware is tied to what contract when doing meetings with vendors, and for production support.

[defo89]

Not sure whether my comment helps but there is an API from Cisco that can return Coverage Status for a given serial number - https://apiconsole.cisco.com/docs/sn2infov2.

In fact there is a project from Henry Ölsner that is a standalone solution which leverages this API. https://github.com/hoelsner/product-database

So given these possibilities I am not sure whether it's a good idea to have these features in Netbox or to have a separate tool for this purpose.

[alejojo]

what about https://github.com/snipe/snipe-it and make APIs work together?

A free open source IT asset/license management system built in PHP on Laravel 5.2 and Bootstrap 3. https://snipeitapp.com

[Gelob]

@alejojo snipe-it looks awesome. I would be for some basic netbox + snipe-it integration. No need to re-invent the wheel.

[Zorlin]

You could call it NetSnipe or SnipeBox ;)

On 24 Oct. 2017 23:28, "Ryan" notifications@github.com wrote:

@alejojo https://github.com/alejojo snipe-it looks awesome. I would be for some basic netbox + snipe-it integration. No need to re-invent the wheel.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/digitalocean/netbox/issues/182#issuecomment-339030125, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTmrA6Hcp392Yqo90z8T9MN9ywiolEgks5svgIbgaJpZM4JDqzI .

[tvberlin]

+1 for attaching documents (.pdf, .doc, .xls) to devices, racks, circuits, sites. For acceptance documentation for sites/racks, measurement protocols for circuits and contract/acccess request forms for sites. Would be great to have the possible to extend the upload function and also have the possibility to add types for documents. Furthermore, the possibility to upload/select multiple documents at once for upload would be great.

[IPFox]

I have been looking for support contracts / licenses feature for netbox mainly as a learning experiment, however I have rather well working solution in place and would like to see if anyone has done any work on this front so far and if my implementation would be suitable for addressing this issue.

Basically it is a copy of the current circuits setup, renamed as Subscriptions with the subscritpion types (license, maintenance contract etc) and Service provider / Vendor.

The idea is that each subscription can be attached to multiple devices, especially true in maintenance contract cases where one contract can cover dozens of devices.

Each subscription will have start and end date, with the possibility of being permanent for specific device(s). I also have a idea of having the cost and the PO stuff included later on.

One idea I have been thinking with these is that should the circuits and my subscriptions actually be within the same menu, as in the end we are talking about subscription services there with Vendors/Providers, or is that just a brain dead idea?

I would appreciate any feedback on the approach and also a note if someone has been working on this to find a way to get this feature in place one way or another.

[computer045]

@IPFox Circuits and “subscription” should be separate entities. The request of this issue is about the warranties of devices. The circuit module of the application is mostly for the IPAM. The “subscriptions” should be about the devices in the DCIM, as I understand it.

[IPFox]

I have demo available of the basic functionality of the Subscriptions available now at http://netbox.ddns.net. I have few bugs on it on the subscription addition side, but otherwise everything is working including tests and API. All the feedback is more than welcome and of course I will file a PR in case this will be something that would be suitable to be added to the Netbox

[xonacs]

I quite like the idea for license management, example Microsoft SPLA management etc.

On Fri, Oct 19, 2018 at 8:27 AM IPFox notifications@github.com wrote:

I have demo available of the basic functionality of the Subscriptions available now at http://netbox.ddns.net. I have few bugs on it on the subscription addition side, but otherwise everything is working including tests and API. All the feedback is more than welcome and of course I will file a PR in case this will be something that would be suitable to be added to the Netbox

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/digitalocean/netbox/issues/182#issuecomment-431258334, or mute the thread https://github.com/notifications/unsubscribe-auth/AgTEBWK2gGEb4tqzHmeZR_61I2ggynlWks5umXDqgaJpZM4JDqzI .

[ruben-herold]

@IPFox your demo side is not reachable in the moment. I would like to test it.

[imranh2]

Not having this feature is what stops us from using Netbox.

I see the bare minimum being just the warranty/contract/PO number and end date for a device/part warranty. Some alerting when it's about to expire would be nice too.

Everything else can be looked up in a static document store that does version control etc...

I think trying to enter specifics like response time isn't a bad idea but where do you stop? Everyone's needs are so different, I feel that this has got to be super generic.

[candlerb]

There seem to be two distinct things here:

1. Support contracts for physical devices
2. Software licences / software subscriptions

Note that if you're running RHEL on a Device, or you're running RHEL in a VM, you could have a software subscription / support contract. I'm thinking (1) is the maintenance contract from the hardware vendor, and (2) covers OS and applications.

For point (1), I'm coming to the view that a separate asset system is required, whereby Netbox contains the Asset ID for each Device and Inventory Item, referencing the asset system. The asset system tells you what you have (or had), its purchase history and warranty info; Netbox tells you where it is installed right now and how it is configured. The asset system can keep track of spares and returns too.

Netbox currently doesn't work well as an asset system. For example, it doesn't really handle swap-outs of in-service devices. You can update a device with a new serial number and MAC addresses, but you lose the history of the device which previously served its role. An asset needs to be an entity which is tracked from purchase to disposal. And since a support contract relates to the asset, I think it belongs in the asset system.

For point (2) this seems to be very open-ended. Any Device or VM could potentially have many software applications, each with licence and subscription. There are also SaaS cloud-hosted subscriptions which are not linked to any Device or VM. Licences and subscriptions are closely tied to purchasing, and only loosely to DCIM, if at all.

[ryanmerolle]

To add on to @candlerb was saying, I think there is a third part of this request that needs to be documented. It relates to #1435 that @jeremystretch closed linking as a duplicate to this ticket.

3. Adding more attributes to the manufacturer objects or at least the ability to add custom fields.

This could be handled by an integration with a third party tool, or at least custom links (jinja2) to the page of a third party tool such as Snipe-IT. As of right now, no custom entries can be added, so it would be hard to link the too in NetBox. Allowing any custom fields, would allow people to track items they think important such as notes, account numbers, etc.

[deajan]

At least, having support contracts / software licences with a date field, it would be awesome to have a search field by date, and more, alerts on expiring contracts. Imagine having this, you could use netbox to also handle domain / ssl renewals :)

Any roadmap in sight ?

Best regards.

[ryanmerolle]

Separate from this bigger feature, would it challenging to extend manufacturers slightly to at least include fields similar to the circuit provider data model? I think ultimately these providers / manufacturers seem very similar and could merge into 1 object type.

[jeremystretch]

After some discussion with the other maintainers, we've decided to defer this work to avoid further scope creep. However, it has been identified as an ideal candidate for a future plugin project, once plugin support has been introduced in NetBox (loosely referred to as NetBox v3.0).

[nimbius]

@jeremystretch Thank you for not incorporating this feature. Im probably in the minority here but what makes Netbox such a refreshing change from every other six-figure proprietary DCIM is that it doesnt include any of this crap.

"NetBox is an open source web application designed to help manage and document computer networks. " Full. Stop. If you're maintaining contracts, licenses, RMA's, vendor POC's, and SLA's as part of the definition of a device then youre doing it wrong.

This is I believe a business process issue common in a lot of smaller/medium shops the purchasing department is basically nepotism with a desk, so no real tracking gets done. eventually contract management creeps into the job description of the engineer.

think of it this way. Water, electric, gas, and phone bills are tracked effectively by the company, so why cant the same type of recurrent payment of licenses? whatever system tracks the vending machine contracts should track the switch contracts.

Netbox should strive to interact with ChatOps tools and ticketing systems like Jira perhaps...tools that handle the issues surrounding devices in a computer network. it should not however strive to handle the entire life experience of a device.