Implement dynamic selection of parent prefix from a set of custom fields #90

henrybear327 · 2024-10-08T11:07:59Z

Design

We introduce a new parentPrefixSelector field in the CR. It's a list of custom field key-value mapping, where both the key and value are of the type string. For example

parentPrefixSelector:
    environment: "Production"
    ipVersion: "4"

We now have 3 cases:

If only parentPrefix is set, we continue on as-is
If only parentPrefixSelector is set, we would take all Prefixes that exactly match all custom field's key-value specified in parentPrefixSelector. We would then pick the first prefix that is able to satisfy the prefixLength requirement as the parent prefix.
If we have both parentPrefix and parentPrefixSelector present in the CR, the CRD validation will reject this yaml file

The parentPrefix will be set in the status field ParentPrefix, and this will be used as the source of truth for the rest of the reconcile function.

Known issue

Implement better selection algorithm for the dynamic prefix selection #99

TODO

Discuss if using status field to store the computed ParentPrefix value is desired
The restoration hash mechanism for parentPrefixSelector would require some documentation, as there might be the case there the picked parent prefix is different for the same parentPrefixSelector (e.g. due to prefix space exhaustion), and thus, the restoration might not work as user anticipated.

Notes

Closes Implement dynamic selection of parent prefix from a set of custom fields #79
Tests will be in a follow-up PR Implement tests for dynamic selection of parent prefix from a set of custom fields #91

internal/controller/prefix_controller.go

internal/controller/prefixclaim_controller.go

henrybear327 · 2024-10-09T07:37:31Z

Discuss if using the status field to store the computed ParentPrefix value is desired

We agree that the spec field is read-only, so we wouldn't put any computed ParentPrefix there.

The status field is what we have write access to and where we reflect the relevant internal states to the external user. Thus, we have decided to use it to store the computed ParentPrefix and use it as the source of truth.

henrybear327 · 2024-10-09T11:54:19Z

Improved CRD validation: According to [2], the oneOf validation will only come in the next version.

cc: @alexandernorth @bruelea

Reference:
[1] https://kubernetes.io/blog/2022/09/29/enforce-immutability-using-cel/
[2] https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-ratcheting

henrybear327 · 2024-10-10T21:31:12Z

For some reason, when we are querying for custom fields, for example using this URL http://localhost:8080/ipam/prefixes/?q=&cf_poolName=Pool+2&cf_environment=production, the value of the custom field cf_environment will be capitalized automatically. This has an impact on us as we can only enter the value in custom fields in capitalized form.

Reproduction step:

type in http://localhost:8080/ipam/prefixes/?q=&cf_poolName=Pool+2&cf_environment=production in your browser
you can see that the search that went through NetBox is actually http://localhost:8080/ipam/prefixes/?q=&cf_poolName=Pool+2&cf_environment=Production

The demo SQL files have adhered to this "observation", but I am not able to wrap my head around this, since for the restoration hash, we have no issue with it

cc: @alexandernorth @bruelea

henrybear327 · 2024-10-10T21:55:40Z

To maintain the backward compatibility of the restoration hash and extend it to support parentPrefixSelection, we have made the following changes to the hash:

append the parentPrefixSelection key-value pairs to the end of the hash during hash calculation. The exact string that is appended is done by sorting the keys first before appending, so in the case that only the key order of the parentPrefixSelection changes, the hash value won't be affected
we take the value of the parent prefix from the spec for the hash computation, thus, in the case of parentPrefixSelection, it will be an empty string

With the aforementioned change, the hash can by design distinguish the prefix claimed by ParentPrefix or parentPrefixSelection, thus, making the restoration process relying on the hash achievable.

internal/controller/prefix_controller.go

internal/controller/prefixclaim_controller.go

pkg/netbox/api/ip_address_claim.go

api/v1/prefixclaim_types.go

henrybear327 · 2024-10-11T14:24:14Z

Comment from @bruelea: add the newly created sample to the kustomization: config/samples/kustomization.yaml

Done

jitendrs · 2024-10-14T08:56:39Z

Please add me as reviewer.

henrybear327 · 2024-10-15T08:55:55Z

For some reason, when we are querying for custom fields, for example using this URL http://localhost:8080/ipam/prefixes/?q=&cf_poolName=Pool+2&cf_environment=production, the value of the custom field cf_environment will be capitalized automatically. This has an impact on us as we can only enter the value in custom fields in capitalized form.

Reproduction step:

type in http://localhost:8080/ipam/prefixes/?q=&cf_poolName=Pool+2&cf_environment=production in your browser

you can see that the search that went through NetBox is actually http://localhost:8080/ipam/prefixes/?q=&cf_poolName=Pool+2&cf_environment=Production

The demo SQL files have adhered to this "observation", but I am not able to wrap my head around this, since for the restoration hash, we have no issue with it

cc: @alexandernorth @bruelea

So as @alexandernorth explained, on browsers, they might modify the URLs. But for the API endpoints what we send is directly being processed.

So in the case, this is not an issue for us when querying using API endpoints! But when we are doing debugging using URLs, we might run into issues.

jstudler · 2024-11-12T13:27:43Z

If you use a PrefixClaim using parentPrefixSelector with an invalid Tenant (a Tenant that doesn't exist in NetBox), the Event will show:

The parent prefix was not able to be computed. no parent prefix can be obtained with the query conditions set in ParentPrefixSelector, err = <nil>, number of candidates = 0

Spec example:

apiVersion: netbox.dev/v1
kind: PrefixClaim
metadata:
  name: prefixclaim-customfields-sample
spec:
  tenant: "MY_TENANT that doesn't exist"
  site: "DM-Akron"
  preserveInNetbox: true
  prefixLength: "/31"
  parentPrefixSelector: # The keys and values are case-sensitive
    environment: "PostProduction"
    poolName: "Pool 1"

This is quite misleading. Do you think there is an easy way to enhance this?

jstudler · 2024-11-12T14:36:35Z

Under some circumstances the parent prefix will be computed but it's already exhausted. Even if you add more prefixes, the system will not recover and compute/chose a new parent prefix. Example describe:

Name:         prefixclaim-customfields-sample-09
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  netbox.dev/v1
Kind:         PrefixClaim
Metadata:
  Creation Timestamp:  2024-11-12T14:26:55Z
  Generation:          1
  Resource Version:    4212
  UID:                 a3b68d89-6c66-4d63-8b39-c95dd9c326b5
Spec:
  Parent Prefix Selector:
    Environment:       PostProduction
    Pool Name:         Pool 254
  Prefix Length:       /30
  Preserve In Netbox:  false
  Tenant:              Dunder-Mifflin, Inc.
Status:
  Conditions:
    Last Transition Time:  2024-11-12T14:27:11Z
    Message:               The parent prefix was computed successfully. parentPrefix is computed: 1.254.0.0/27
    Reason:                ParentPrefixComputed
    Status:                True
    Type:                  ParentPrefixComputed
    Last Transition Time:  2024-11-12T14:28:13Z
    Message:               Failed to fetch new Prefix from NetBox. parent prefix exhausted
    Reason:                PrefixCRNotCreated
    Status:                False
    Type:                  PrefixAssigned
  Parent Prefix:           1.254.0.0/27
Events:
  Type     Reason                    Age    From                     Message
  ----     ------                    ----   ----                     -------
  Normal   ParentPrefixComputed      4m41s  prefix-claim-controller  The parent prefix was computed successfully. parentPrefix is computed: 1.254.0.0/27
  Warning  PrefixCRNotCreated        3m39s  prefix-claim-controller  Failed to fetch new Prefix from NetBox. parent prefix exhausted
  Warning  FailedToLockParentPrefix  2m     prefix-claim-controller  failed to lock parent prefix 1.254.0.0/27

Could we fix this by removing .status.parentPrefix if we come to the condition that has the message "parent prefix exhausted"?

api/v1/prefixclaim_types.go

henrybear327 · 2024-11-13T22:50:10Z

@jstudler please take another pass when you have time! :) Thanks

henrybear327 · 2024-11-13T22:57:10Z

If you use a PrefixClaim using parentPrefixSelector with an invalid Tenant (a Tenant that doesn't exist in NetBox), the Event will show:

The parent prefix was not able to be computed. no parent prefix can be obtained with the query conditions set in ParentPrefixSelector, err = <nil>, number of candidates = 0

Spec example:

apiVersion: netbox.dev/v1
kind: PrefixClaim
metadata:
  name: prefixclaim-customfields-sample
spec:
  tenant: "MY_TENANT that doesn't exist"
  site: "DM-Akron"
  preserveInNetbox: true
  prefixLength: "/31"
  parentPrefixSelector: # The keys and values are case-sensitive
    environment: "PostProduction"
    poolName: "Pool 1"

This is quite misleading. Do you think there is an easy way to enhance this?

We actually throw an error indicating this situation, please see the code snippet below:

func (r *NetboxClient) GetTenantDetails(name string) (*models.Tenant, error) {
	request := tenancy.NewTenancyTenantsListParams().WithName(&name)
	response, err := r.Tenancy.TenancyTenantsList(request, nil)
	if err != nil {
		return nil, utils.NetboxError("failed to fetch Tenant details", err)
	}
	if len(response.Payload.Results) == 0 {
		return nil, utils.NetboxNotFoundError("tenant '" + name + "'")
	}

	return &models.Tenant{
		Id:   response.Payload.Results[0].ID,
		Slug: *response.Payload.Results[0].Slug,
		Name: *response.Payload.Results[0].Name,
	}, nil
}

I think this is related to the discussion this morning - we need to surface the underlying errors properly to the user. As in this case, we did throw an error clearly specifying the problem, but it's not visible to the user.

henrybear327 · 2024-11-13T23:02:59Z

Under some circumstances the parent prefix will be computed but it's already exhausted. Even if you add more prefixes, the system will not recover and compute/chose a new parent prefix. Example describe:

Name:         prefixclaim-customfields-sample-09
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  netbox.dev/v1
Kind:         PrefixClaim
Metadata:
  Creation Timestamp:  2024-11-12T14:26:55Z
  Generation:          1
  Resource Version:    4212
  UID:                 a3b68d89-6c66-4d63-8b39-c95dd9c326b5
Spec:
  Parent Prefix Selector:
    Environment:       PostProduction
    Pool Name:         Pool 254
  Prefix Length:       /30
  Preserve In Netbox:  false
  Tenant:              Dunder-Mifflin, Inc.
Status:
  Conditions:
    Last Transition Time:  2024-11-12T14:27:11Z
    Message:               The parent prefix was computed successfully. parentPrefix is computed: 1.254.0.0/27
    Reason:                ParentPrefixComputed
    Status:                True
    Type:                  ParentPrefixComputed
    Last Transition Time:  2024-11-12T14:28:13Z
    Message:               Failed to fetch new Prefix from NetBox. parent prefix exhausted
    Reason:                PrefixCRNotCreated
    Status:                False
    Type:                  PrefixAssigned
  Parent Prefix:           1.254.0.0/27
Events:
  Type     Reason                    Age    From                     Message
  ----     ------                    ----   ----                     -------
  Normal   ParentPrefixComputed      4m41s  prefix-claim-controller  The parent prefix was computed successfully. parentPrefix is computed: 1.254.0.0/27
  Warning  PrefixCRNotCreated        3m39s  prefix-claim-controller  Failed to fetch new Prefix from NetBox. parent prefix exhausted
  Warning  FailedToLockParentPrefix  2m     prefix-claim-controller  failed to lock parent prefix 1.254.0.0/27

Could we fix this by removing .status.parentPrefix if we come to the condition that has the message "parent prefix exhausted"?

Quick question, what's the desired behavior?

IMO, prefix exhaustion might be a temporary issue, so we should requeue and keep trying.

WDYT?

ParentPrefixSelectorGuide.md

jstudler · 2024-11-14T09:48:36Z

Under some circumstances the parent prefix will be computed but it's already exhausted. Even if you add more prefixes, the system will not recover and compute/chose a new parent prefix. Example describe:

Name:         prefixclaim-customfields-sample-09
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  netbox.dev/v1
Kind:         PrefixClaim
Metadata:
  Creation Timestamp:  2024-11-12T14:26:55Z
  Generation:          1
  Resource Version:    4212
  UID:                 a3b68d89-6c66-4d63-8b39-c95dd9c326b5
Spec:
  Parent Prefix Selector:
    Environment:       PostProduction
    Pool Name:         Pool 254
  Prefix Length:       /30
  Preserve In Netbox:  false
  Tenant:              Dunder-Mifflin, Inc.
Status:
  Conditions:
    Last Transition Time:  2024-11-12T14:27:11Z
    Message:               The parent prefix was computed successfully. parentPrefix is computed: 1.254.0.0/27
    Reason:                ParentPrefixComputed
    Status:                True
    Type:                  ParentPrefixComputed
    Last Transition Time:  2024-11-12T14:28:13Z
    Message:               Failed to fetch new Prefix from NetBox. parent prefix exhausted
    Reason:                PrefixCRNotCreated
    Status:                False
    Type:                  PrefixAssigned
  Parent Prefix:           1.254.0.0/27
Events:
  Type     Reason                    Age    From                     Message
  ----     ------                    ----   ----                     -------
  Normal   ParentPrefixComputed      4m41s  prefix-claim-controller  The parent prefix was computed successfully. parentPrefix is computed: 1.254.0.0/27
  Warning  PrefixCRNotCreated        3m39s  prefix-claim-controller  Failed to fetch new Prefix from NetBox. parent prefix exhausted
  Warning  FailedToLockParentPrefix  2m     prefix-claim-controller  failed to lock parent prefix 1.254.0.0/27

Could we fix this by removing .status.parentPrefix if we come to the condition that has the message "parent prefix exhausted"?

Quick question, what's the desired behavior?

IMO, prefix exhaustion might be a temporary issue, so we should requeue and keep trying.

WDYT?

The desired behavior is that the Operator can recover from this case. Yes, we should assume that prefix exhaustion is a temporary issue only. The behaviour I've seen above was deadlock: The parent prefix was chosen but it had no space left, but there were other parent prefix candidates that weren't chosen. So I think removing .status.parentPrefix where the controllers writes the condition/event that contains the message "parent prefix exhausted" should fix this.

jstudler · 2024-11-14T09:53:09Z

If you use a PrefixClaim using parentPrefixSelector with an invalid Tenant (a Tenant that doesn't exist in NetBox), the Event will show:

The parent prefix was not able to be computed. no parent prefix can be obtained with the query conditions set in ParentPrefixSelector, err = <nil>, number of candidates = 0

Spec example:

apiVersion: netbox.dev/v1
kind: PrefixClaim
metadata:
  name: prefixclaim-customfields-sample
spec:
  tenant: "MY_TENANT that doesn't exist"
  site: "DM-Akron"
  preserveInNetbox: true
  prefixLength: "/31"
  parentPrefixSelector: # The keys and values are case-sensitive
    environment: "PostProduction"
    poolName: "Pool 1"

This is quite misleading. Do you think there is an easy way to enhance this?

We actually throw an error indicating this situation, please see the code snippet below:

func (r *NetboxClient) GetTenantDetails(name string) (*models.Tenant, error) {
	request := tenancy.NewTenancyTenantsListParams().WithName(&name)
	response, err := r.Tenancy.TenancyTenantsList(request, nil)
	if err != nil {
		return nil, utils.NetboxError("failed to fetch Tenant details", err)
	}
	if len(response.Payload.Results) == 0 {
		return nil, utils.NetboxNotFoundError("tenant '" + name + "'")
	}

	return &models.Tenant{
		Id:   response.Payload.Results[0].ID,
		Slug: *response.Payload.Results[0].Slug,
		Name: *response.Payload.Results[0].Name,
	}, nil
}

I think this is related to the discussion this morning - we need to surface the underlying errors properly to the user. As in this case, we did throw an error clearly specifying the problem, but it's not visible to the user.

But I think the event is wrong. The event indicates "The parent prefix was not able to be computed" when in fact the problem is that the user set an invalid tenant. Could we create an event in GetTenantDetails for the case that the tenant cannot be found?

internal/controller/prefixclaim_controller.go

henrybear327 · 2024-11-15T09:05:29Z

If you use a PrefixClaim using parentPrefixSelector with an invalid Tenant (a Tenant that doesn't exist in NetBox), the Event will show:
The parent prefix was not able to be computed. no parent prefix can be obtained with the query conditions set in ParentPrefixSelector, err = <nil>, number of candidates = 0
Spec example:
apiVersion: netbox.dev/v1
kind: PrefixClaim
metadata:
  name: prefixclaim-customfields-sample
spec:
  tenant: "MY_TENANT that doesn't exist"
  site: "DM-Akron"
  preserveInNetbox: true
  prefixLength: "/31"
  parentPrefixSelector: # The keys and values are case-sensitive
    environment: "PostProduction"
    poolName: "Pool 1"
This is quite misleading. Do you think there is an easy way to enhance this?
We actually throw an error indicating this situation, please see the code snippet below:
func (r *NetboxClient) GetTenantDetails(name string) (*models.Tenant, error) {
	request := tenancy.NewTenancyTenantsListParams().WithName(&name)
	response, err := r.Tenancy.TenancyTenantsList(request, nil)
	if err != nil {
		return nil, utils.NetboxError("failed to fetch Tenant details", err)
	}
	if len(response.Payload.Results) == 0 {
		return nil, utils.NetboxNotFoundError("tenant '" + name + "'")
	}

	return &models.Tenant{
		Id:   response.Payload.Results[0].ID,
		Slug: *response.Payload.Results[0].Slug,
		Name: *response.Payload.Results[0].Name,
	}, nil
}
I think this is related to the discussion this morning - we need to surface the underlying errors properly to the user. As in this case, we did throw an error clearly specifying the problem, but it's not visible to the user.
But I think the event is wrong. The event indicates "The parent prefix was not able to be computed" when in fact the problem is that the user set an invalid tenant. Could we create an event in GetTenantDetails for the case that the tenant cannot be found?

Tracking under bug #132

henrybear327 · 2024-11-15T09:05:54Z

Under some circumstances the parent prefix will be computed but it's already exhausted. Even if you add more prefixes, the system will not recover and compute/chose a new parent prefix. Example describe:
Name:         prefixclaim-customfields-sample-09
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  netbox.dev/v1
Kind:         PrefixClaim
Metadata:
  Creation Timestamp:  2024-11-12T14:26:55Z
  Generation:          1
  Resource Version:    4212
  UID:                 a3b68d89-6c66-4d63-8b39-c95dd9c326b5
Spec:
  Parent Prefix Selector:
    Environment:       PostProduction
    Pool Name:         Pool 254
  Prefix Length:       /30
  Preserve In Netbox:  false
  Tenant:              Dunder-Mifflin, Inc.
Status:
  Conditions:
    Last Transition Time:  2024-11-12T14:27:11Z
    Message:               The parent prefix was computed successfully. parentPrefix is computed: 1.254.0.0/27
    Reason:                ParentPrefixComputed
    Status:                True
    Type:                  ParentPrefixComputed
    Last Transition Time:  2024-11-12T14:28:13Z
    Message:               Failed to fetch new Prefix from NetBox. parent prefix exhausted
    Reason:                PrefixCRNotCreated
    Status:                False
    Type:                  PrefixAssigned
  Parent Prefix:           1.254.0.0/27
Events:
  Type     Reason                    Age    From                     Message
  ----     ------                    ----   ----                     -------
  Normal   ParentPrefixComputed      4m41s  prefix-claim-controller  The parent prefix was computed successfully. parentPrefix is computed: 1.254.0.0/27
  Warning  PrefixCRNotCreated        3m39s  prefix-claim-controller  Failed to fetch new Prefix from NetBox. parent prefix exhausted
  Warning  FailedToLockParentPrefix  2m     prefix-claim-controller  failed to lock parent prefix 1.254.0.0/27
Could we fix this by removing .status.parentPrefix if we come to the condition that has the message "parent prefix exhausted"?
Quick question, what's the desired behavior?
IMO, prefix exhaustion might be a temporary issue, so we should requeue and keep trying.
WDYT?
The desired behavior is that the Operator can recover from this case. Yes, we should assume that prefix exhaustion is a temporary issue only. The behaviour I've seen above was deadlock: The parent prefix was chosen but it had no space left, but there were other parent prefix candidates that weren't chosen. So I think removing .status.parentPrefix where the controllers writes the condition/event that contains the message "parent prefix exhausted" should fix this.

Tracking under bug #131

henrybear327 · 2024-11-18T10:25:17Z

Under some circumstances the parent prefix will be computed but it's already exhausted. Even if you add more prefixes, the system will not recover and compute/chose a new parent prefix. Example describe:
Name:         prefixclaim-customfields-sample-09
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  netbox.dev/v1
Kind:         PrefixClaim
Metadata:
  Creation Timestamp:  2024-11-12T14:26:55Z
  Generation:          1
  Resource Version:    4212
  UID:                 a3b68d89-6c66-4d63-8b39-c95dd9c326b5
Spec:
  Parent Prefix Selector:
    Environment:       PostProduction
    Pool Name:         Pool 254
  Prefix Length:       /30
  Preserve In Netbox:  false
  Tenant:              Dunder-Mifflin, Inc.
Status:
  Conditions:
    Last Transition Time:  2024-11-12T14:27:11Z
    Message:               The parent prefix was computed successfully. parentPrefix is computed: 1.254.0.0/27
    Reason:                ParentPrefixComputed
    Status:                True
    Type:                  ParentPrefixComputed
    Last Transition Time:  2024-11-12T14:28:13Z
    Message:               Failed to fetch new Prefix from NetBox. parent prefix exhausted
    Reason:                PrefixCRNotCreated
    Status:                False
    Type:                  PrefixAssigned
  Parent Prefix:           1.254.0.0/27
Events:
  Type     Reason                    Age    From                     Message
  ----     ------                    ----   ----                     -------
  Normal   ParentPrefixComputed      4m41s  prefix-claim-controller  The parent prefix was computed successfully. parentPrefix is computed: 1.254.0.0/27
  Warning  PrefixCRNotCreated        3m39s  prefix-claim-controller  Failed to fetch new Prefix from NetBox. parent prefix exhausted
  Warning  FailedToLockParentPrefix  2m     prefix-claim-controller  failed to lock parent prefix 1.254.0.0/27
Could we fix this by removing .status.parentPrefix if we come to the condition that has the message "parent prefix exhausted"?
Quick question, what's the desired behavior?
IMO, prefix exhaustion might be a temporary issue, so we should requeue and keep trying.
WDYT?
The desired behavior is that the Operator can recover from this case. Yes, we should assume that prefix exhaustion is a temporary issue only. The behaviour I've seen above was deadlock: The parent prefix was chosen but it had no space left, but there were other parent prefix candidates that weren't chosen. So I think removing .status.parentPrefix where the controllers writes the condition/event that contains the message "parent prefix exhausted" should fix this.
Tracking under bug #131

Fixed. Please take a look @jstudler, thanks

jstudler

lgtm. Thanks a lot for the work @henrybear327 !

config/samples/kustomization.yaml

Notes: According to [2], the `oneOf` validation will only come in the next version Reference: [1] https://kubernetes.io/blog/2022/09/29/enforce-immutability-using-cel/ [2] https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-ratcheting Signed-off-by: Hoanganh.Mai <[email protected]> Signed-off-by: Chun-Hung Tseng <[email protected]> Co-authored-by: Sergio <[email protected]> Co-authored-by: bruelea <[email protected]>

henrybear327 requested a review from bruelea October 8, 2024 11:07

henrybear327 self-assigned this Oct 8, 2024

henrybear327 marked this pull request as draft October 8, 2024 11:08

henrybear327 force-pushed the feat/issue_79 branch 7 times, most recently from 335e04b to 97c512d Compare October 8, 2024 11:25

bruelea reviewed Oct 9, 2024

View reviewed changes

internal/controller/prefix_controller.go Outdated Show resolved Hide resolved

internal/controller/prefixclaim_controller.go Outdated Show resolved Hide resolved

henrybear327 force-pushed the feat/issue_79 branch 2 times, most recently from 787fecd to 1ad0f81 Compare October 10, 2024 21:25

henrybear327 requested a review from bruelea October 10, 2024 21:27

henrybear327 marked this pull request as ready for review October 10, 2024 21:27

henrybear327 force-pushed the feat/issue_79 branch from 1ad0f81 to f65550b Compare October 10, 2024 22:00

bruelea reviewed Oct 11, 2024

View reviewed changes

internal/controller/prefix_controller.go Outdated Show resolved Hide resolved

internal/controller/prefixclaim_controller.go Show resolved Hide resolved

pkg/netbox/api/ip_address_claim.go Outdated Show resolved Hide resolved

bruelea reviewed Oct 11, 2024

View reviewed changes

api/v1/prefixclaim_types.go Outdated Show resolved Hide resolved

henrybear327 force-pushed the feat/issue_79 branch 3 times, most recently from 5c97a94 to 592375a Compare October 15, 2024 08:46

henrybear327 force-pushed the feat/issue_79 branch from 592375a to cac0ce6 Compare October 15, 2024 09:23

henrybear327 mentioned this pull request Oct 15, 2024

Document (or revisit) the reason that site is a mutable field #100

Closed

jstudler reviewed Nov 13, 2024

View reviewed changes

api/v1/prefixclaim_types.go Outdated Show resolved Hide resolved

jstudler reviewed Nov 13, 2024

View reviewed changes

api/v1/prefixclaim_types.go Outdated Show resolved Hide resolved

jstudler reviewed Nov 13, 2024

View reviewed changes

api/v1/prefixclaim_types.go Outdated Show resolved Hide resolved

henrybear327 requested a review from jstudler November 13, 2024 22:37

CapiSSS reviewed Nov 14, 2024

View reviewed changes

ParentPrefixSelectorGuide.md Outdated Show resolved Hide resolved

CapiSSS approved these changes Nov 14, 2024

View reviewed changes

henrybear327 force-pushed the feat/issue_79 branch from 5ae7b50 to 1b9b95e Compare November 14, 2024 12:57

bruelea reviewed Nov 14, 2024

View reviewed changes

internal/controller/prefixclaim_controller.go Show resolved Hide resolved

This was referenced Nov 15, 2024

Under some circumstances the parent prefix will be computed but it's already exhausted #131

Closed

The event indicates "The parent prefix was not able to be computed" when the real problem is that the user set an invalid tenant #132

Open

jstudler approved these changes Nov 18, 2024

View reviewed changes

henrybear327 force-pushed the feat/issue_79 branch 2 times, most recently from 6b5b695 to 47eebdd Compare November 18, 2024 12:32

bruelea reviewed Nov 18, 2024

View reviewed changes

config/samples/kustomization.yaml Outdated Show resolved Hide resolved

henrybear327 requested a review from bruelea November 19, 2024 08:54

bruelea approved these changes Nov 19, 2024

View reviewed changes

henrybear327 force-pushed the feat/issue_79 branch from d17ac16 to ef07396 Compare November 19, 2024 14:06

henrybear327 merged commit f002bf8 into netbox-community:main Nov 19, 2024
5 checks passed

henrybear327 deleted the feat/issue_79 branch November 19, 2024 14:06

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement dynamic selection of parent prefix from a set of custom fields #90

Implement dynamic selection of parent prefix from a set of custom fields #90

henrybear327 commented Oct 8, 2024 •

edited

Loading

henrybear327 commented Oct 9, 2024

henrybear327 commented Oct 9, 2024

henrybear327 commented Oct 10, 2024 •

edited

Loading

henrybear327 commented Oct 10, 2024 •

edited

Loading

henrybear327 commented Oct 11, 2024

jitendrs commented Oct 14, 2024

henrybear327 commented Oct 15, 2024 •

edited

Loading

jstudler commented Nov 12, 2024

jstudler commented Nov 12, 2024 •

edited

Loading

henrybear327 commented Nov 13, 2024

henrybear327 commented Nov 13, 2024

henrybear327 commented Nov 13, 2024

jstudler commented Nov 14, 2024

jstudler commented Nov 14, 2024

henrybear327 commented Nov 15, 2024

henrybear327 commented Nov 15, 2024

henrybear327 commented Nov 18, 2024

jstudler left a comment

Implement dynamic selection of parent prefix from a set of custom fields #90

Implement dynamic selection of parent prefix from a set of custom fields #90

Conversation

henrybear327 commented Oct 8, 2024 • edited Loading

Design

Known issue

TODO

Notes

henrybear327 commented Oct 9, 2024

henrybear327 commented Oct 9, 2024

henrybear327 commented Oct 10, 2024 • edited Loading

henrybear327 commented Oct 10, 2024 • edited Loading

henrybear327 commented Oct 11, 2024

jitendrs commented Oct 14, 2024

henrybear327 commented Oct 15, 2024 • edited Loading

jstudler commented Nov 12, 2024

jstudler commented Nov 12, 2024 • edited Loading

henrybear327 commented Nov 13, 2024

henrybear327 commented Nov 13, 2024

henrybear327 commented Nov 13, 2024

jstudler commented Nov 14, 2024

jstudler commented Nov 14, 2024

henrybear327 commented Nov 15, 2024

henrybear327 commented Nov 15, 2024

henrybear327 commented Nov 18, 2024

jstudler left a comment

Choose a reason for hiding this comment

henrybear327 commented Oct 8, 2024 •

edited

Loading

henrybear327 commented Oct 10, 2024 •

edited

Loading

henrybear327 commented Oct 10, 2024 •

edited

Loading

henrybear327 commented Oct 15, 2024 •

edited

Loading

jstudler commented Nov 12, 2024 •

edited

Loading