You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a confusing case with StatesCurrent and deploying.
When we have:
an S3Bucket and an S3Object
the S3Object has a parameter built from S3Bucket
Then:
The initial state from DiscoverCmd is null (since the parameter is unknown).
After deploying and cleaning, S3Object's state is None, because when we clean it up, we know it is None.
When EnsureCmd is run, the discovered value is null (unknown).
This is detected as out-of-sync.
./envman deploy --fast
# Errors
peace_rt_model::apply_cmd_error::states_current_out_of_sync
× Stored current states were not up to date with actual current states.
│
│ * s3_object:
│
│ - stored: does not exist
│ - discovered: <none>
│
│
help: Run `StatesDiscoverCmd::current` to update the stored current states,
and re-check the difference before applying changes.
Solutions
Option A: We should not consider null vs SomeItemState::None as out-of-sync when deploying?
🟢 Usually null (unknown) is alright to tolerate ItemState::None on discovery on ensure.
🔴 If the item actually exists, maybe we should stop, maybe we should "just use it".
Option B: We save states as null after cleaning up.
🔴 Doesn't work with the other items that need to be non-null when deploying next.
Option C: Discover states again after cleaning
🟢 Ensures consistency with the States that will be discovered upon the next deploy
🔴 Adds another discovery duration to the current execution.
The text was updated successfully, but these errors were encountered:
There is a confusing case with
StatesCurrent
and deploying.When we have:
S3Bucket
and anS3Object
S3Object
has a parameter built fromS3Bucket
Then:
DiscoverCmd
isnull
(since the parameter is unknown).S3Object
's state isNone
, because when we clean it up, we know it isNone
.EnsureCmd
is run, the discovered value isnull
(unknown).Solutions
Option A: We should not consider
null
vsSomeItemState::None
as out-of-sync when deploying?null
(unknown) is alright to tolerateItemState::None
on discovery on ensure.Option B: We save states as
null
after cleaning up.Option C: Discover states again after cleaning
States
that will be discovered upon the next deployThe text was updated successfully, but these errors were encountered: