@@ -358,8 +358,8 @@ This only affects the creation of new Services without an IP specified, there is
358
358
359
359
###### What specific metrics should inform a rollback?
360
360
361
- The allocation logic already has the following metrics, that will be expanded with a new label containing information about the
362
- type of allocation requested (dynamic or static ):
361
+ The allocation logic already has the following metrics, [some metrics have been extended with a
362
+ new label to contain information about the allocation scope requested](#monitoring-requirements ):
363
363
364
364
- allocated_ips
365
365
- available_ips
@@ -370,11 +370,12 @@ The increase of the errors metrics or the trend of the allocated_ips and availab
370
370
371
371
###### Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?
372
372
373
+ Since it is a purely in-memory feature the upgrade or downgrande doesn't have any impact.
373
374
###### Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.?
374
375
375
376
### Monitoring Requirements
376
377
377
- Following allocator metrics will be expanded with a new label to each metric containing information about the
378
+ Following allocator metrics have been expanded with a new label to each metric containing information about the
378
379
type of allocation requested (dynamic or static):
379
380
380
381
- allocation_total
@@ -387,20 +388,7 @@ The other allocator the metrics can not use the additional label because, when a
387
388
388
389
###### How can an operator determine if the feature is in use by workloads?
389
390
390
- A new metric will be added containing the information of the range configuration in the allocator.
391
-
392
- ` ` ` go
393
- allocatorInfo = metrics.NewGaugeVec (
394
- &metrics.GaugeOpts {
395
- Name: " allocator_info" ,
396
- Help: " A metric with a constant '1' value labeled by Service CIDR, " ,
397
- StabilityLevel: metrics.ALPHA ,
398
- },
399
- []string {" cidr" , " allocator_size" , " dynamic_range_offset" },
400
- )
401
- ` ` `
402
-
403
- The allocator using this feature will have a ` dynamic_range_offset` value different than 0.
391
+ An operator will only observe that the change in behavior described for dynamically assigned ClusterIP for Services.
404
392
405
393
###### How can someone using this feature know that it is working for their instance?
406
394
@@ -409,14 +397,14 @@ The allocator using this feature will have a `dynamic_range_offset` value differ
409
397
- [ ] API .status
410
398
- Condition name:
411
399
- Other field:
412
- - [ ] Other (treat as last resort)
400
+ - [X ] Other (treat as last resort)
413
401
- Details:
414
402
- Create services without setting the ClusterIP and observe that all the services IPs allocated belong the upper band of the range,
415
403
and once the upper band is exhausted it keep assigning IPs on the lower band until the whole range is exhausted.
416
404
417
405
###### What are the reasonable SLOs (Service Level Objectives) for the enhancement?
418
406
419
-
407
+ N/A
420
408
###### What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?
421
409
422
410
@@ -429,6 +417,9 @@ The allocator using this feature will have a `dynamic_range_offset` value differ
429
417
430
418
###### Are there any missing metrics that would be useful to have to improve observability of this feature?
431
419
420
+ We could have a metric exposing the configuration parameters of the allocator, but that will collide
421
+ and is incompatible with a new KEP that expand the Service allocators to make the dynamically configurable.
422
+
432
423
### Dependencies
433
424
434
425
###### Does this feature depend on any specific services running in the cluster?
0 commit comments