Add doc describing provisioning restrictions #4499
Conversation
A common problem users have is that they can't directly edit the NGINX resources that we provision, and we direct them to our docs on how to set the fields they want. I'm adding this document here to describe why this restriction is in place. This can help developers on the team understand it, to help explain it if needed, and can also be used as a reference to any users who may be curious.
github-actions
bot
added
the
documentation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4499 +/- ##
=======================================
Coverage 86.31% 86.31%
=======================================
Files 132 132
Lines 14859 14859
Branches 35 35
=======================================
+ Hits 12825 12826 +1
+ Misses 1815 1814 -1
Partials 219 219 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I feel like an added section to https://docs.nginx.com/nginx-gateway-fabric/troubleshooting/ might help too, not sure if that page is used by users. |
|
@bjee19 Interesting thought. @ADubhlaoich What do you think? Does it make sense to copy this there, or link to it from the docs? It's written a bit casual and informational, versus solving a direct problem. |
bjee19
left a comment
bjee19
left a comment
There was a problem hiding this comment.
that can always be an add on after the fact, so this lgtm
salonichf5
left a comment
salonichf5
left a comment
There was a problem hiding this comment.
I do agree with Ben, we need a small section in troubleshooting docs, linking this page. Usually that's the first place to look when something is not working. Maybe a known issues section
|
everything else looks good and makes sense |
A common problem users have is that they can't directly edit the NGINX resources that we provision, and we direct them to our docs on how to set the fields they want.
I'm adding this document here to describe why this restriction is in place. This can help developers on the team understand it, to help explain it if needed, and can also be used as a reference to any users who may be curious.