Support contracts model

[shepherdjay]

We currently manage assets that may be subject to multiple warranties and/or contracts.

Those contracts will have their own renewal dates, specific assets, provide combinations of hardware and software support.

I haven't been able to figure out good way to manage this with just custom fields.

For example we may purchase a switch from supplier x. That supplier may provide a 90 day hardware warranty. We may subsequently purchase a 1 year software support agreement from another supplier y which is actually a reseller of support for vendor x.

What we want to be able to do is when looking at a device in dcim to figure out who to quickly call for software or hardware support.

Rough thoughts where that there could be new model for Contracts that have start, end date, and Boolean for hardware, one for software, and support standard netbox contacts. Contracts could be added to a purchase. Assets could be assigned multiple contracts. Assets could display along with warranty data a link to most recent contract for hardware and software.

[uck9]

I'd second this. There's some overlap here with design included on the NetBox Lifecycle plugin but my thoughts are that it's better associating the support contracts with the asset records as opposed to the Device Record. Means there is visibility of contract info at the hardware level vs only the active hardware (eg Devices).

[matejv]

One of design guides when we started developing netbox_inventory was that we'll keep it simple with regards to warranties, support contracts and such.

However if there is a real need for this functionality I'm not opposed to adding it. I do think we need to flesh out the idea a bit more before we start work on it.

If @shepherdjay or @uck9 (or someone else reading this that would also benefit from this) could describe in more detail how you imagine the functionality would work (or provide a pull request), we cold work something out.

[shepherdjay]

My initial thought is there would be 3 base types of contracts. Hardware Warranty, Software Support, and Hardware Support.

A contract itself would function somewhat similar to an asset in that it is optionally tied to a purchase / supplier. It would also have a list of assets it would affect and assets can be affected by more than one contract.

Warranty you already have implemented, so can stay where it is or migrated to this new model. Possibly a plugin config option that either enables per asset warranty contract creation (the default) or disables it and leaves it up to user.

From a UI Perspective there would be two new timeline graphs (apologize don't have the exact term at the front of my brain right now) that show the furthest out expiration across each of the three contract types. (Furthest out due to multiple contracts of same type being assignable) - A hotlink to that contract or supplier wouldn't be terrible either.

I think that would cover a lot of the use cases. Primarily for us what we are struggling with most is that we have some assets that may have 3 different support avenues based on whether its a hardware/software failure and who we bought it from. Thanks to covid we picked up a lot of used gear so the simple if its Cisco you call Cisco Tac style support model no longer applies in our org.

@matejv -- I will look into working on a PR this weekend to flush it out a bit more and maybe that will help.

[cs-1]

Sorry for chiming in on the discussion but what you describe sounds like you really need a full-fledged asset management which netbox-inventory -- to my understanding -- was never meant to be. There're already solutions (open source solutions that is) that should do what you want. Maybe it makes sense to look at them (like Snipe-IT or any of the other FOSS solutions) and to connect NetBox+netbox-inventory to the asset management via custom links, custom fields and maybe a webhook based middleware? We do exactly that with our monitoring based on LibreNMS. You can get a pretty seamless integration by doing that. This way, netbox-inventory's code can stay simple enough to maintain and you still get the desired functionality in a field tested, dedicated asset management.

[uck9]

There’s actually a good set of models around support contracts in Dan Sheps netbox-lifecycle plugin. I’ve been working through the idea of a seperate support contract plugin to this inventory plugin - linking contract associations to an asset defined in the inventory. Means we have a separation of concerns to each plugin but allows capture of this info.

Personally, Keep hardware warranty on the current asset model as this can be assumed as default oob from a manufacturer, support contracts kept seperate.

@cs-1 - definitely see your point. This does start to turn NetBox into an actual operational state system vs the original scope (as I read it) where NB is a target state system. Unfort getting NB in was hard enough, managing to get some of this operational info captured and usable does make it easier to fight for. Personal experience there, ymmv elsewhere.

[shepherdjay]

Sorry for chiming in on the discussion but what you describe sounds like you really need a full-fledged asset management...

@cs-1 -- You aren't wrong that a proper asset management system would be beneficial. Unfortunately, Snipe-IT doesn't even support lumping assets together in a purchase natively and FOSS solutions in general can have a large technical resource cost. Its not always the case that there is the manpower, money, or desire to manage all the baggage that comes with an enterprise software solution.. let alone a FOSS one.

.... which netbox-inventory -- to my understanding -- was never meant to be.

Possibly. @matejv can clarify the overall vision of simplicity for the project, when I saw Deliveries make it into the model (which I'm just using custom state or 'Ordered' for today) it did give me pause that maybe there is the desire to manage more aspects of the asset lifecycle.

Netbox, to me, is about condensing information away from multiple sources into a single source of truth as much as practical. Getting away from a half dozen spreadsheets and tribal knowledge of where a device is, what it's plugged into, how to connect, and who to contact when it's broken.

Ultimately I'm fairly happy that this plugin has solved a major headache for me already and that's just on the 1.3 state. How to migrate our install and custom states to 1.4+ is already up in the air a bit as deliveries are an unintentionally added confusion for how we deployed it lol.

Also understand completely the solution needs to be maintainable and don't want to accidentally drop a new pet into a maintainers lap if the value isn't seen.

[shepherdjay]

@uck9 -- I haven't really heard of that plugin yet but have seen some of the work Dan has done. I wonder if the plugin is due to contract support being in the top five of the current plugin ideas bounty board https://plugin-ideas.netbox.dev/ideas?sort=popular (top list doesn't include the two actually up for bounty)

Also @matejv happy to take this over to Discussions as well if you want to enable for repo or if you prefer issues is best place to talk through this.

[uck9]

@shepherdjay - Yeah Dan's done some good work on the contracts model.

Thoughts from experience with Cisco Contracts:

• A Contract exists that's associated with a vendor and has a start and end date.
• Devices associated with the contract will have a Support Level associated (This may be where you have different HW / SW support SKU's available to assign). Noting that the end date for the support contract may be different to the end date on the actual parent contract (Dan accounted for this via the SupportContractAssociation Model which has an end date value available to fill).
• Having an installed address (that is referenced by the Vendor) is useful for us where we've got hardware installed internationally. This would be part of the SupportContractAssociation model as it's per device on the contract and I'm 99% sure this is completely seperate to the Installed-At address captured at the root hardware level.
• Having the ability to have multiple contracts associated with an Asset would be useful to account where we re-contract support via a different vendor to the current contract.

Another thing (and here's where scope creep might be kicking in) is to track EoL Dates for HW models. It's another thing that Dan included in his lifecycle plugin, and was also replicatd in the Cisco-Support plugin. Really nice to be able to see EoL Dates in one place.

[cs-1]

@shepherdjay thanks for the explanation. Yes, you're completely right, running an asset management is a lot of work and Snipe-IT isn't the holy grail either. I agree with you that having everything in one place (i.e. having it in netbox-inventory) would be great. The question is how to maintain it. I'm wondering whether or not we could support @matejv by helping with the project by writing code. I personally have written some custom report and custom script code for NetBox but would still need a thorough introduction into netbox-inventory's structure before I could contribute anything useful. But maybe if @matejv would help us with an introduction we could contribute to the project and make adding the contract model to it an easier task.

That being said, I'm totally pro having a contract model in netbox-inventory. We have all sorts of pain managing all the different contracts by different vendors.

[shepherdjay]

@uck9 - Comments inline below

• A Contract exists that's associated with a vendor and has a start and end date.

Yes - in this case plan for my proposed implementation is to try and make use of the supplier model.

• Devices associated with the contract will have a Support Level associated (This may be where you have different HW / SW support SKU's available to assign). Noting that the end date for the support contract may be different to the end date on the actual parent contract (Dan accounted for this via the SupportContractAssociation Model which has an end date value available to fill).

I don't think supporting hierarchal contracts is warranted. I think the use case for this plugin would be to provide quick asset level information. Tying to the direct contract makes sense here as it allows for quickly knowing if a device is under support or not. Parent contracts are useful for coordinating renewals with your var but hopefully thats where their value add comes in. An alternative implementation for those that need to track sub contracts is to just use a custom field for this.

• Having an installed address (that is referenced by the Vendor) is useful for us where we've got hardware installed internationally. This would be part of the SupportContractAssociation model as it's per device on the contract and I'm 99% sure this is completely seperate to the Installed-At address captured at the root hardware level.

This should match your asset. In the cases it doesn't match your asset you should update the support vendor with the new installed address. In line with the idea that netbox being a source of truth other systems should conform to this feels way to operational with little payoff. I would recommend if needed again a custom field is added to your asset, but really should just generate quarterly reports and send off to your vendor to fix their side.

• Having the ability to have multiple contracts associated with an Asset would be useful to account where we re-contract support via a different vendor to the current contract.

Multiple contracts is planned in my implementation.

@cs-1 -- Yes my plan is to help with the code. I didn't get an opportunity this weekend to work on it much at all but am really hoping to get a full fledged pr created within the coming weeks.

[uck9]

On the contracts item I’ve probably done a bad job of explaining the layout. Isn’t hierarchical contracts, just more the fact that every device attached to a contract can have a different level of support (eg 8x5xNBD vs 24x7x4) and an end date that is different to the contract. With Cisco at least you wouldn’t be able to say a contract is just one end date and level of support for all devices attached.

Agreed on the address method described. Def a way around this one, still importing from the vendor for current contracts so it’s available on the device details for easy review but seperate from contract.

Really interested to see your implementation pr as it sounds like it would align with some of my requirements.

[shepherdjay]

just more the fact that every device attached to a contract can have a different level of support (eg 8x5xNBD vs 24x7x4) and an end date that is different to the contract. With Cisco at least you wouldn’t be able to say a contract is just one end date and level of support for all devices attached.

The level of support I'm less worried about -- I don't know if its super critical to capture NBD vs 4 hour for example. Those things are easier to determine typically through the vendor system once you know its supported and who to call which is my primary motiviation. We for example have equipment that is supported not by the manufacturer but a third party so for us its this dance of who to call for support.

Now the end date being different is a problem and I'm going to have to think about the best way to capture that cleanly. Possibly some sort of asset override but that might make renewal time a pita. Or does it actually matter? By that I mean there would be nothing stopping a user from creating multiple contracts named nearly identical like 12345678 - NBD, 12345678 - 247, and 12345678 - December End -- etc. That might be an acceptable compromise. I'm not planning on the contract number to be unique as it could be null for some support contracts. Really the only required fields are going to be name and type.

[balpoint]

Anybody working on this concept to integrate it with Inventory , for us it's the one aspect missing in Netbox a good way to administrate support contracts