System attributes for generic systems

[williampincek47]

Hi,

This is a request for a new feature. Currently, we cannot use apstra_datacenter_device_allocation to set the system attributes of a generic system. If I attempt to do so, I get this error...

│ Error: invalid configuration │ │ with apstra_datacenter_device_allocation.generic-systems["server3"], │ on build.tf line 48, in resource "apstra_datacenter_device_allocation" "generic-systems": │ 48: system_attributes = { │ 49: name = each.value["name"] │ 50: hostname = each.value["hostname"] │ 51: } │ │ system_attributes may be specified only for "switch" type systems, but the system with label "my_single_001_sys001" │ has type "server"

I do see that there a previously "solved" issue related to this. The fix to the issue ensures "server" type systems cannot have their system attributes set with the apstra_datacenter_device_allocation resource.

If apstra_datacenter_device_allocation cannot be updated to perform this change to a "server" type system, I would like to request that a new resource is created to support this function. Maybe the resource could be called apstra_datacenter_server_allocation?

Thanks,

Will Pincek

[chrismarget-j]

Hi @williampincek47,

The attributes (hostname, asn, etc...) of a generic system can be set when it is created using the apstra_datacenter_generic_system resource.

This is a deliberate nudge to create generic systems explicitly vs. discovering their existence and adjusting their parameters (the process required with switches and anything else which follows the created-by-template pattern).

[williampincek47]

I understand what you are saying.

However, I will say that all of the examples on github (including the AI/ML JVD example) do not use the apstra_datacenter_generic_system resource. The examples expect that Apstra will scaffold the blueprint based on a template that is loaded with generic systems. Also, when I asked a SME about it, he said "there is more than one way to skin a cat" so it seems that it is OK to do it either way. :)

To me, it seems that the same problem that we are discussing for generic systems also exists for the leaf nodes of a blueprint (spines also). I can either instantiate them all by the racks of a template or by adding racks after a blueprint is scaffolded. Regardless of the method, I still don't have a "switch" resource to manage the individual switches. I only have a "rack" resource. It seems that we have been given a fix to the no "switch" resource problem which is the apstra_datacenter_device_allocation resource. With that resource I can change the deploy mode, name, hostname and so on of any switch I want to.

Why wouldn't it make sense to also solve that problem for generic systems?

Will

[williampincek47]

To me, the apstra_datacenter_device_allocation resource feels like the Apstra software had an existing backdoor to being able to set the system attributes of a "switch" without needing a resource defined for a "switch".

If the answer is, "Generic systems don't have that same backdoor so it is not possible to change system attributes without a "generic-system" resource.", then, that make sense and I will go on about my business. :)

It sure would be a nice feature to have. It would make it so all methods of blueprint scaffolding are equal....more or less.

[chrismarget-j]

without needing a resource defined for a "switch"

Look at it the other way: Spine and Leaf switches exist without terraform having any involvement in their creation or management. This is an ugly corner for declarative tooling. Discovering these objects and changing their configuration is an imperative process. It's a workaround.

Declaring objects along with their attributes via terraform configuration is the natural path.