Don't evaluate edge rules if property is set by constraints #952
Conversation
Also don't apply edge rules if a property sets a value explicitly via constraints
|
we need a way to then signal if an edge rule is critical if we want to guarantee correctness, otherwise we cant make that guarantee. We could say that validation is that method also but thats a lot more work for us to bake this in then |
| // NOTE(gg): does operator even matter here? If it's not a collection, | ||
| // what does an 'add' mean? Should it allow edges to overwrite? |
There was a problem hiding this comment.
if its not a collection yeah im not sure that it would matter
| // Check to see if the whole path is valid before adding phantoms and edges. | ||
| // It's a miniscule performance benefit, and is mostly done for clarity in the debug graph output. | ||
| validPath := true | ||
| for i, res := range path { | ||
| if i == 0 { | ||
| continue | ||
| } | ||
| edgeTemplate := kb.GetEdgeTemplate(path[i-1].Id(), res.Id()) | ||
| if edgeTemplate == nil || edgeTemplate.DirectEdgeOnly { | ||
| validPath = false | ||
| break | ||
| } | ||
| } | ||
| if !validPath { | ||
| continue | ||
| } | ||
|
|
||
| satisfied_paths++ |
There was a problem hiding this comment.
dont we already do this when building the path selection graph? Isnt this redundant
There was a problem hiding this comment.
Ah, yeah, I meant to move it instead of duplicate it. The main impact of this is that it removed resources used in paths that never connected to the target. Per the comment, it's mostly to support the kb tool to prevent extra irrelevant resources.
I agree, added #953 to track |
Edge Rules
This is required for
giteaStackPack to change HealthCheck protocol on an NLB to beHTTP(and others, I don't remember).kbAlso adds
kbtool to help inspect the knowledgebase.Example
Support EnableExecuteCommand on ECS Service
For debugging ECS services
Standard checks