Closed mssola closed 5 years ago
@mssola about point 3) If this is a migration, reenable it always.
since Caasp v4 doesn't support if migration from v3 to v4, i'm thinking we should simplify it here and add that logic in v3
@mssola about point 3) If this is a migration, reenable it always. since Caasp v4 doesn't support if migration from v3 to v4, i'm thinking we should simplify it here and add that logic in v3
I'm not sure I understand. This was already in place before my change, actually. My change tries to preserve the past behavior (point 3), and adds points 1, 2 and 4.
@mssola about point 3) If this is a migration, reenable it always. since Caasp v4 doesn't support if migration from v3 to v4, i'm thinking we should simplify it here and add that logic in v3
I'm not sure I understand. This was already in place before my change, actually. My change tries to preserve the past behavior (point 3), and adds points 1, 2 and 4.
ah ok i was thinking you added (point 3) ok thx for comment. ( i could also not found the point 3 in the pr :smile: ) thx
This PR will also need to be backported into 3.0 once this is merged (since the bug originally targets 3.0)
When executing the update orchestration, it's not always desired to reenable the transactional-update. Moreover, sometimes the timer was on a weird state if the update failed. This commit refines the update orchestration following this logic:
Last but not least, I've also tweaked the
transactional-update/init.sls
file so the timer is not touched by this file when updating.bsc#1113518
Signed-off-by: Miquel Sabaté Solà msabate@suse.com