Change 895725 had a related patch set uploaded (by Cathal Mooney; author: Cathal Mooney):

[operations/software/homer/deploy@master] Return port blocks data for both QFX5120-48Y Netbox device types

https://gerrit.wikimedia.org/r/895725

+1 to fixing them as separate entries as its easy enough to add more models to netbox. Particularly since Homer can report them as such as well!

It hasn't been discussed that I recall, just overlooked in all the new hardware models.

Change 895725 merged by Cathal Mooney:

[operations/software/homer/deploy@master] Return port blocks data for both QFX5120-48Y Netbox device types

https://gerrit.wikimedia.org/r/895725

Change 896348 had a related patch set uploaded (by Cathal Mooney; author: Cathal Mooney):

[operations/software/homer/deploy@master] Release v0.6.1 update

https://gerrit.wikimedia.org/r/896348

Change 896348 merged by Cathal Mooney:

[operations/software/homer/deploy@master] Release v0.6.1 update

https://gerrit.wikimedia.org/r/896348

As @cmooney said, on a hardware point of view they're similar:

Chassis                                xxx      JNP48Y8C-CHAS
Pseudo CB 0     
Routing Engine 0          BUILTIN      BUILTIN           RE-QFX5120-48Y-8C
FPC 0            REV 11   650-083242   xxx      JNP48Y8C-CHAS

Only the licensing changes.

I guess it "doesn't hurt" to separate them now, especially if we want to start keeping track of licenses down the road. While it would be more difficult to do it later on.

The main risk I see with 2 different models is entry mistakes, and as the FLEX is not exposed by LibreNMS, it's not possible to add a check in the reports. So the other option is to keep them as one until we need them to be separated.

Where does the QFX5120-48Y-8C and QFX5120-48Y-AFI2 come from? Packing slip? device itself?

For what I saw the prompt is the fastest way to differentiate them from the CLI:

• JUNOS 19.1R3-S2.3 Kernel 64-bit FLEX JNPR-11.0-20200618.2bc7e35_buil

In T331519#8688137, @ayounsi wrote:

Where does the QFX5120-48Y-8C and QFX5120-48Y-AFI2 come from? Packing slip? device itself?

QFX5120-48Y-8C is the hardware model reported under show version by both variants.

QFX5120-48Y-AFI2 is the current Juniper SKU we order, requiring the flex licencing. I can't see anywhere on the device itself that is listed, but as you say the inclusion of "flex" beside the software version seems to be a way to tell.

Perhaps we should rename the "8C" variant in Netbox to "AFI"? i.e. use the SKU for both to be clearer about the difference?

Or perhaps not use AFI anywhere and have an "8C" and "8C-FLEX"?

Let's try this proposal:
if either:

• DCops is OK to put special care to the model when adding devices to Netbox when they arrive on site (including RMAs) and the packing slip makes the difference between the two models
• Or someone figure out a way to add a Netbox check

Let's use two models (most likely the SKUs)

Otherwise let's use the existing one until we need to make the distinction between the two.

For what I saw the prompt is the fastest way to differentiate them from the CLI:

JUNOS 19.1R3-S2.3 Kernel 64-bit FLEX JNPR-11.0-20200618.2bc7e35_buil

Looks like it's gone since the upgrade:
--- JUNOS 21.4R3.16 Kernel 64-bit JNPR-12.1-20220817.43c4e23_buil

Which makes the first option even more difficult. It might be worth asking Juniper how to differentiate them.

Just to note, the new Juniper QFX5120 devices in Eqiad (lsw1-e[5-7]-eqiad / lsw1-f[5-6]-eqiad) had been marked down as QFX5100-48S-6Q.

Matching the status-quo for the similar switches that arrived in codfw I have now set them all to device type QFX5120-48Y-AFI2 for the time being.

Another thing we'll need to tidy up here is the LibreNMS report that checks what it sees from SNMP with the info from Netbox.

Given the "AFI2" is not seomthing LibreNMS will ever see I'm not sure how we approach this. We could perhaps change the report to only compare the first two elements if we split the model name on the dash character, so for instance remove the -8c, -afi2 etc., and then search for it in the sysDescr field LibreNMS returns. Could be a bit messy/brittle though.

I'm more and more on the side of using a single device type here.

Had a quick chat with @RobH on -dcops to get it sorted before we deployed new esams.

One major usage DCops/procurement have of this data is to verify Juniper's support renewal quotes. For example to double check that Juniper don't assign the wrong type of support (as it has happened) to a given model.
With that in mind I don't see any other way that tracking those 2 models independently.
Medium/long term we will be able to detect entry mistakes with {T306238}
@cmooney I think that was your preference as well, so consensus might be easy to reach :)

@ayounsi I was leaning towards having a single device, from a netops perspective they are pretty much the same. In terms of licensing we know everything new device is flex as that's all that's available.

But if there is a good reason for the Juniper API integration to have two separate models then that's fine, it's been a minor annoyance but no major issue so far having the two separate.

We can probably close this task now?

Change 958814 had a related patch set uploaded (by Ayounsi; author: Ayounsi):

[operations/software/netbox-extras@master] LibreNMS report: add equivalent model strings

https://gerrit.wikimedia.org/r/958814

Change 958814 merged by jenkins-bot:

[operations/software/netbox-extras@master] LibreNMS report: add equivalent model strings

https://gerrit.wikimedia.org/r/958814