device lifecycle discussion

[ryanmerolle]

There are a lot of discussions and some efforts going on with creating a plugin(s) for device lifecycle. I have been investigating approaches, talking to users, looking and other tools that try to do the same thing. Here is my stream of conscience to help others out and initiate conversations. This will start at scoping, another subsequent post in this discussion will tackle models.

Lifecycle could encompass a lot, and whoever approaches this needs to feel comfortable with the scope because it could get out of control. I have no strong feeling on scope even if my write up may lean one way or another.

Possible Scope / Problems to address:

• Lifecycle Model: DeviceType / ModuleType / Device / Module / PlatformVersion tracking of End-of-Life, End-of-Sale, End-of-Support, End-of-Software-Release (names can be changed up, but you should get the point)
• Software/Platform Version Tracking- Track whether a version has LTS, is a pre-release, is a feature or maintenance release, release date, end of support date, a url to link to the release notes,
  • With vendors like Arista, it's just a basic tracking of a software version, filename, etc.
  • With more complicated platform like with some Cisco IOS, you may have various "flavors" of a particular version (IE they are the same version number, but provide different feature set). Thus you may need a relationship between Version and with some model of firmware_variations or firmware_filenames
  • In some platforms inventory items could have firmware applied to them
  • In some instances optional software/firmware could be tracked
• Intended/Certified/Approved Software version to deploy - in addition to the possible versions that could be installed on a device/vm you could track the intended/certified software for a group of devices
• Support Contracts - Track contract numbers, what they include (level of support etc), what they apply to (devices/serials), start date and end date. When a new contract is negotiated with a vendor, the netbox would get a new contract created (to preserve the attributes for the old expired contract in the model). Manufacturers would need to be associated to a contract and resellers may also need to be associated

Given all of the above, you would be able to enable the following workflows with plugins, reports, or your own stitched together workflows:

• Firmware upgrades to certified image
• Firmware compliance reporting (when a user grabs the actual software running on a device and comparing to the certified/intended compliance version)
  • (Bonus) Firmware exceptions - compare running software against a list of possible software (beyond just intended/certified/golden)
  • (Bonus) Firmware End of Support reports vs what is running
• Support contract tracking
• Device Support Status
• Device End of Life/Support reports

@DanSheps @abhi1693 @kkthxbye-code

[DanSheps]

Software image management, IMO, should be a SWIM plugin.

[ryanmerolle]

@DanSheps I cannot really argue against your logic, I was just stating what I have seen others do with the nautobot and other attempts I have seen with defunct netbox plugins.

I think the argument I’ve heard to include it is so you can also apply the lifecycle model on software as well. For example some vm and container versions of platforms will have an EOL, EOS, and etc. Some people I have talked to about this have gone so far as to say the need to track the last supported version of a platform for a particular devicetype.

[asteven]

Isn't this https://github.com/nautobot/nautobot-plugin-device-lifecycle-mgmt basically an implementation of the above discussion?
Is this an effort to bring that functionality (back) into netbox?
Just curious.

[DanSheps]

Yes, this is likely similar to the nautobot plugin, but you need to remember, NetBox is not NautoBot, so any plugins for one don't generally work for the other.

I am working on a plugin, which does have similar features to the Nautobot plugin but there also lots of differences.

[Lon1]

We are just starting out with a few custom fields in the Platform object to track software EoX dates and similar custom fields in the Device object. Since we are mostly a Cisco shop, we are developing scripts to pull the EoX data down from Cisco automatically to populate the data, but will allow manual edits of the fields for non-Cisco gear and software. I agree a plugin would be better than adding more custom fields (gets messy). I believe we will eventually land on moving all this over to a plugin.

[mtinberg]

This might be a little out of date but could be a good place to start https://github.com/goebelmeier/netbox-cisco-support — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Lon Thompson ***@***.***> Sent: Monday, October 30, 2023 9:22 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] device lifecycle discussion (Discussion #12564) We are just starting out with a few custom fields in the Platform object to track software EoX dates and similar custom fields in the Device object. Since we are mostly a Cisco shop, we are developing scripts to pull the EoX data down from Cisco automatically to populate the data, but will allow manual edits of the fields for non-Cisco gear and software. I agree a plugin would be better than adding more custom fields (gets messy). I believe we will eventually land on moving all this over to a plugin. — Reply to this email directly, view it on GitHub<#12564 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM2YOK2TIZ6OKQL56RLYB6Z2ZAVCNFSM6AAAAAAX6OLXQSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TIMRUG42DI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Lon1]

I did look at this, but it was too Cisco specific and you are correct as the plugin needs updated to the latest Cisco API URLs. Thanks for thinking of it.
-Lon.

[DanSheps]

If you want to suggest specific changes to mine to support software EoL/EoX I am more then willing to work on that.

https://github.com/dansheps/netbox-lifecycle

[HolyFredy]

If you want to suggest specific changes to mine to support software EoL/EoX I am more then willing to work on that.

https://github.com/dansheps/netbox-lifecycle

Hi!
I use https://endoflife.date/ to get my EoL/EoX of OS and softwares.
They got an API to retrieve info: https://endoflife.date/docs/api