DLPX-74859 Stack fails to come up for GCP engines because delphix-platform service failed #275
Conversation
| - blockinfile: | ||
| path: /etc/default/instance_configs.cfg.template |
There was a problem hiding this comment.
Do we need to undo any configuration that might have previously been applied to the .template file? E.g. remove the file? or remove the block we may have added in an earlier version?
There was a problem hiding this comment.
I had a meeting with google to discuss how the new packages changed behavior and they mentioned that they maintained the template file in the new packages too even though it's not documented. I decided that it would be best to remove both the template file and the cfg file and just recreate it as part of our ansible logic.
| # Make sure that the account daemon is always disabled. The override file | ||
| # above should prevent this and this is designed to catch any corner cases. | ||
| # | ||
| - command: systemctl disable google-accounts-daemon.service |
There was a problem hiding this comment.
Do we need to undo any configuration that might have previously been applied? E.g. re-enable the service (assuming it's default state is to be enabled)?
There was a problem hiding this comment.
We don't need to do anything as part of upgrade. The packaging remove the old services but does leave them masked:
root@gwilson-gcp:/var/tmp# systemctl list-unit-files \*google\*
UNIT FILE STATE
google-accounts-daemon.service masked
google-clock-skew-daemon.service masked
google-guest-agent.service enabled
google-instance-setup.service masked
google-network-daemon.service masked
google-oslogin-cache.service static
google-shutdown-scripts.service enabled
google-startup-scripts.service enabled
google-oslogin-cache.timer enabled
If someone ever unmasks the service then it just gets removed.
There was a problem hiding this comment.
I have the same concern/question as Prakash regarding the config file. If we ever have to change what's in there, or if a human were to accidentally tweak what's in there, then I think this ansible logic won't quite do what we want. It might be safest to remove the file, and write it from scratch every time.
…tform service failed
|
I have also upgraded an engine with these changes. |
Pull request checklist
Please check if your PR fulfills the following requirements:
Pull request type
Please check the type of change your PR introduces:
What is the current behavior?
Issue Number: DLPX-74859
What is the new behavior?
Does this introduce a breaking change?
Other information