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
@bpg Hello! Sorry for not following up earlier for the issue, I got quite busy. I see that you have reverted it, that's good, rather not keep something not working properly that long in the latest release. However, I am still interested by this feature and would like to know if you are as well. In my mind, I was thinking that the only reason that a disk is to be re-imported is if the source has changed, the size shouldn't have had triggered it in the first place. instead of opening a new PR, I would like to discuss the feature properly, and see what do you think and if you're (still) interested in having it.
I will speak a bit more about why I feel it would be useful. currently, I am creating these ephemeral boot disks with data disks, because they're ephemeral, nothing that changes in there will be kept, including updates to the system to keep the software inside up to date and spec. So, to update the boot disk, I change the source, pointing towards a new boot disk source that has the updated configuration.
in the reverted PR, the code was intended to only update the disk if the backing source was changed. now this can be a breaking change, so along side fixing the original functionality, we should most likely introduce a new parameter disk_update_on_source_change or something along those lines to control the new functionality, this parameter should be false by default, which, would maintain the original v87 functionality and avoid the regression scenario we saw earlier in the week. Of course, if we're re-introducing this, I intend to extend the work with new tests to ensure that the new code does not break something like this again.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
@bpg Hello! Sorry for not following up earlier for the issue, I got quite busy. I see that you have reverted it, that's good, rather not keep something not working properly that long in the latest release. However, I am still interested by this feature and would like to know if you are as well. In my mind, I was thinking that the only reason that a disk is to be re-imported is if the source has changed, the size shouldn't have had triggered it in the first place. instead of opening a new PR, I would like to discuss the feature properly, and see what do you think and if you're (still) interested in having it.
I will speak a bit more about why I feel it would be useful. currently, I am creating these ephemeral boot disks with data disks, because they're ephemeral, nothing that changes in there will be kept, including updates to the system to keep the software inside up to date and spec. So, to update the boot disk, I change the source, pointing towards a new boot disk source that has the updated configuration.
in the reverted PR, the code was intended to only update the disk if the backing source was changed. now this can be a breaking change, so along side fixing the original functionality, we should most likely introduce a new parameter
disk_update_on_source_changeor something along those lines to control the new functionality, this parameter should be false by default, which, would maintain the original v87 functionality and avoid the regression scenario we saw earlier in the week. Of course, if we're re-introducing this, I intend to extend the work with new tests to ensure that the new code does not break something like this again.Beta Was this translation helpful? Give feedback.
All reactions