https://pulumi.com logo
Join Slack
Powered by
Hi, yet another `has a problem: marshaling propert...
# kubernetes
g
Hi, yet another 
has a problem: marshaling properties: awaiting input property "resources": failed to determine if the following GVK is namespaced
question - what is pulumi trying to do here precisely? I saw a bunch of comments about webhook but I thought this has more to do about crd registration, which does not require webhooks (i think) ?
I faced it with kyverno and a cluster policy and some others operators, just trying to understand a bit better the whole problem
would a 
<http://pulumi.com/waitFor|pulumi.com/waitFor>
annotation works for a resource managed by a 
Release
? is the engine checking this annotation on every templated resources? i'm guessing not 😞
h
does https://github.com/pulumi/pulumi-kubernetes/issues/3176 essentially capture what you’re trying to do? (create a CRD and consume it in the same update?)
g
Hi Bryce, yes but even adding a 60s sleep doesn't work and i can't deploy the crds on their own. i even tried applying the manifest manually while the program is sleeping, which works fine but then pulumi still fails, like so • pulumi up • 
Release
• manual 
kubectl apply
, works fine • 
time.Sleep
60 • 
ConfigFile
marshaling issue
So i switched from 
ConfigFile
to 
CustomResource
and that worked like a charm, no need to wait for anything - i did not dig enough but i m pretty sure the provider/client has an issue around here, like the cache never gets refreshed
fwiw i do a `Release`/`ConfigFile` setup later in my stack and that works just fine ( for karpenter this time )
disregard the above comment, it just does not work 
error: kubernetes:yaml/v2:ConfigFile resource 'karpenter-nodepools' has a problem: marshaling properties: awaiting input property "resources": failed to determine if the following GVK is namespaced: <http://karpenter.sh/v1|karpenter.sh/v1>, Kind=NodePool
h
definitely give #3176 a 👍 to help us prioritize. if it would help unblock you, here’s an example of how to install cert-manager CRDs and CRs in the same update. it’s probably similar to kyverno in that you’ve got some setup to wait for before you can proceed to installing the CR. https://github.com/pulumi/pulumi-kubernetes/blob/605307c42f5c0044227064c357afe4ec852735e3/tests/sdk/nodejs/testdata/await/cert-manager/index.ts#[…]8
g
Oh right I saw that but can't really use it, I'll leave some comments on the issue, been doing progress and quite a lot of testing
my point really is that there should not have to wait for anything because CRDs are deployed/registered very early, way before the deployments are ready webhooks are not exactly in the picture (for karpenter at least, because they re being ditched anyway) - but that's a nice annotation to know
h
yes, this is a side effect of the Release implementation so awaiting won’t help. the example i linked shows how to install without using a Release, but in that case you might need to handle some await logic that helm would normally handle for you.
g
is that because 
Release
is unaware of the underlying resources? interesting anyway, thanks! it's not always possible to use this trick, it depends on the packaging and some operators sometimes register their own CRDs, I think Karpenter does that if you don't install the CRDs explicitly
assuming folks will follow best practices is somewhat risky 🙂 but perhaps a simple flag to control this behaviour could be useful? to control the behaviour
40 Views
Open in Slack
PreviousNext
Powered by