List automations objects #2765
List automations objects #2765
Conversation
joshri
force-pushed
the
list-automations-objects
branch
from
a03e4b7
to
a6576ed
Compare
joshri
force-pushed
the
list-automations-objects
branch
from
3432a83
to
1f847fd
Compare
joshri
force-pushed
the
list-automations-objects
branch
2 times, most recently
from
8027de2
to
607e3fd
Compare
core/server/fluxruntime.go
Outdated
| @@ -164,18 +164,18 @@ func (cs *coreServer) GetReconciledObjects(ctx context.Context, msg *pb.GetRecon | |||
| var opts client.MatchingLabels | |||
|
|
|||
| switch msg.AutomationKind { | |||
| case pb.FluxObjectKind_KindKustomization: | |||
| case "Kustomization": | |||
There was a problem hiding this comment.
kustomizev1.KustomizationKind or pb.Kind_Kustomization (or equivalent for other kinds), to avoid the risks of misspellings.
There was a problem hiding this comment.
This is why it felt weird to me to delete FluxObjectKind all together, since if I do a typed thing here it has to match on the frontend request. If the type field on objects is string and not Kind in the frontend this will not work.......I think? At least that's what I thought was going on while I worked on this. I guess I can convert the string going in into this type and add a slot for "other" or something?
api/core/types.proto
Outdated
| message ObjectRef { | ||
| string kind = 1; | ||
| Kind kind = 1; |
There was a problem hiding this comment.
❌ I missed this before - this changes the same "can't dynamically add more kinds and have the endpoint work" thing for listEvents that I was mentioning for listObjects and getObject
There was a problem hiding this comment.
Same thing here - every time we reference ObjectRef / ClusteredObjectRef in the backend this will have to be a string and not typed?
joshri
force-pushed
the
list-automations-objects
branch
from
be8cc17
to
d233509
Compare
|
@ozamosi All strings of flux primitives have been changed to their flux controller types - tests are going but things look good from my end. Check it out <|:^) |
joshri
force-pushed
the
list-automations-objects
branch
from
106b9b1
to
8b8b297
Compare
joshri
force-pushed
the
list-automations-objects
branch
from
8b8b297
to
16304c8
Compare
This requires adding dedicated inventory handling for helm releases - rather than redesigning the inventory handling, I added an inventory field to the object envelope and only set it when the kind is helmrelease. This isn't good, but also it works and maintains the old behaviour. There is one change in behaviour, which is that inventory read failures from the inventory secret no longer causes the object to disappear from lists or refuse to render details. It'll now show up, you just won't see any of the objects it's created. This is required for #2664 but as listObjects isn't used to list helmReleases yet, it doesn't actually resolve it.
joshri
force-pushed
the
list-automations-objects
branch
from
16304c8
to
1ff8a09
Compare
We should only get events for the current cluster - we used to search all clusters, and if another cluster had the same object then we'd show incorrect events. This makes the new, correct object ref kind introduced in #2765 the only object ref used in our APIs, and then copy-pastes the client creation code from c3a407a.
We should only get events for the current cluster - we used to search all clusters, and if another cluster had the same object then we'd show incorrect events. This makes the new, correct object ref kind introduced in #2765 the only object ref used in our APIs, and then copy-pastes the client creation code from c3a407a.
We should only get events for the current cluster - we used to search all clusters, and if another cluster had the same object then we'd show incorrect events. This makes the new, correct object ref kind introduced in #2765 the only object ref used in our APIs, and then copy-pastes the client creation code from c3a407a.
We should only get events for the current cluster - we used to search all clusters, and if another cluster had the same object then we'd show incorrect events. This makes the new, correct object ref kind introduced in #2765 the only object ref used in our APIs, and then copy-pastes the client creation code from c3a407a.
We should only get events for the current cluster - we used to search all clusters, and if another cluster had the same object then we'd show incorrect events. This makes the new, correct object ref kind introduced in #2765 the only object ref used in our APIs, and then copy-pastes the client creation code from c3a407a.
We should only get events for the current cluster - we used to search all clusters, and if another cluster had the same object then we'd show incorrect events. This makes the new, correct object ref kind introduced in #2765 the only object ref used in our APIs, and then copy-pastes the client creation code from c3a407a.
|
I find it weird that we have deleted so many |
|
Hi @amulyakish!! The only code remaining in |
No I haven't noticed any errors as such. I'm yet to test this in fact. My comment was based only on the list of changes that I saw in this PR. I missed the fact that the Thank you for all the work you've done here! |
Closes #2763
This is a branch off of #2751. It extends the useListObjects hook to Automations (Kustomizations and HelmReleases) - this then allowed for a BUNCH of things to be deleted, which caused a bunch of problems, and so on and so on. The main things being deleted are the full kustomization and helmrelease.go files, and the change of the FluxObjectKind type to just Kind, which then removes a bunch of conversion utilities such as addKind and removeKind.
There are probably other things that can be deleted - extra types like Syncable were on my radar. But this is certainly a start.