set_lsb_release: only set update-engine GROUP in /usr, not /etc #212
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pothos
force-pushed
the
kai/set-group-only-in-usr
branch
from
c19553c to
53ad3ec
Compare
krnowak
approved these changes
Jan 11, 2022
The default image group is already encoded in /usr/share/flatcar/update.conf but it was written to /etc/flatcar/update.conf as well. This can cause problems when the user switches channels by forcing an update to a specific release from the different channel (e.g., through the flatcar-update tool) as it leaves the file under /etc/flatcar/update.conf out of sync with the new channel version in /usr/share/flatcar/update.conf. Since we don't really need to write a specific channel to /etc on new images as we can rely on the value from /usr, we now leave any possible overwriting of the value in /etc entirely to the user.
pothos
force-pushed
the
kai/set-group-only-in-usr
branch
from
9f355d8 to
0c9804a
Compare
jkoelker
added a commit
to mesosphere/konvoy-image-builder
that referenced
this pull request
Apr 13, 2022
As of flatcar/scripts#212 `/etc/flatcar/update.conf` does not exist by default and is up to the user to create it.
faiq
pushed a commit
to mesosphere/konvoy-image-builder
that referenced
this pull request
Apr 13, 2022
As of flatcar/scripts#212 `/etc/flatcar/update.conf` does not exist by default and is up to the user to create it.
invidian
added a commit
to kinvolk/image-builder
that referenced
this pull request
Apr 25, 2022
Flatcar stable relase since 3139.2.0 has removed /etc/flatcar/update.conf file from default instalation, which was used by Ansible to determine the distro type and effectively the value of 'ansible_os_family' fact, which broke building Flatcar images, as now the conditions for tasks does not evaluate properly when running on Flatcar, as 'ansible_os_family' is reported as 'Flatcar Container Linux by Kinvolk' instead of just 'Flatcar'. This commit adds a workaround for this issue by overriding the value for 'ansible_os_family' fact if problematic value is detected. An alternative to this would be to set a custom fact named e.g. 'is_flatcar' and use that in code, which allows to deduplicate and encapsulate the logic of determining if Flatcar is in use. However, once Ansible bug is fixed on determining 'ansible_os_family' value, this code can be removed and remaining code can stay as is. See links below for more details: - flatcar/scripts#212 - ansible/ansible#77537 - kubernetes-sigs#862 Refs kubernetes-sigs#862 Signed-off-by: Mateusz Gozdek <mgozdekof@gmail.com>
invidian
added a commit
to kinvolk/image-builder
that referenced
this pull request
Apr 25, 2022
Flatcar stable relase since 3139.2.0 has removed /etc/flatcar/update.conf file from default instalation, which was used by Ansible to determine the distro type and effectively the value of 'ansible_os_family' fact, which broke building Flatcar images, as now the conditions for tasks does not evaluate properly when running on Flatcar, as 'ansible_os_family' is reported as 'Flatcar Container Linux by Kinvolk' instead of just 'Flatcar'. This commit adds a workaround for this issue by overriding the value for 'ansible_os_family' fact if problematic value is detected. An alternative to this would be to set a custom fact named e.g. 'is_flatcar' and use that in code, which allows to deduplicate and encapsulate the logic of determining if Flatcar is in use. However, once Ansible bug is fixed on determining 'ansible_os_family' value, this code can be removed and remaining code can stay as is. See links below for more details: - flatcar/scripts#212 - ansible/ansible#77537 - kubernetes-sigs#862 Refs kubernetes-sigs#862 Signed-off-by: Mateusz Gozdek <mgozdekof@gmail.com>
invidian
added a commit
to kinvolk/image-builder
that referenced
this pull request
Apr 25, 2022
Flatcar stable relase since 3139.2.0 has removed /etc/flatcar/update.conf file from default instalation, which was used by Ansible to determine the distro type and effectively the value of 'ansible_os_family' fact, which broke building Flatcar images, as now the conditions for tasks does not evaluate properly when running on Flatcar, as 'ansible_os_family' is reported as 'Flatcar Container Linux by Kinvolk' instead of just 'Flatcar'. This commit adds a workaround for this issue by overriding the value for 'ansible_os_family' fact if problematic value is detected. An alternative to this would be to set a custom fact named e.g. 'is_flatcar' and use that in code, which allows to deduplicate and encapsulate the logic of determining if Flatcar is in use. However, once Ansible bug is fixed on determining 'ansible_os_family' value, this code can be removed and remaining code can stay as is. See links below for more details: - flatcar/scripts#212 - ansible/ansible#77537 - kubernetes-sigs#862 Refs kubernetes-sigs#862 Signed-off-by: Mateusz Gozdek <mgozdekof@gmail.com>
invidian
added a commit
to kinvolk/image-builder
that referenced
this pull request
Apr 27, 2022
Flatcar stable relase since 3139.2.0 has removed /etc/flatcar/update.conf file from default instalation, which was used by Ansible to determine the distro type and effectively the value of 'ansible_os_family' fact, which broke building Flatcar images, as now the conditions for tasks does not evaluate properly when running on Flatcar, as 'ansible_os_family' is reported as 'Flatcar Container Linux by Kinvolk' instead of just 'Flatcar'. This commit adds a workaround for this issue by overriding the value for 'ansible_os_family' fact if problematic value is detected. An alternative to this would be to set a custom fact named e.g. 'is_flatcar' and use that in code, which allows to deduplicate and encapsulate the logic of determining if Flatcar is in use. However, once Ansible bug is fixed on determining 'ansible_os_family' value, this code can be removed and remaining code can stay as is. See links below for more details: - flatcar/scripts#212 - ansible/ansible#77537 - kubernetes-sigs#862 Refs kubernetes-sigs#862 Signed-off-by: Mateusz Gozdek <mgozdekof@gmail.com>
invidian
added a commit
to kinvolk/image-builder
that referenced
this pull request
Apr 27, 2022
Flatcar stable relase since 3139.2.0 has removed /etc/flatcar/update.conf file from default instalation, which was used by Ansible to determine the distro type and effectively the value of 'ansible_os_family' fact, which broke building Flatcar images, as now the conditions for tasks does not evaluate properly when running on Flatcar, as 'ansible_os_family' is reported as 'Flatcar Container Linux by Kinvolk' instead of just 'Flatcar'. This commit adds a workaround for this issue by overriding the value for 'ansible_os_family' fact if problematic value is detected. An alternative to this would be to set a custom fact named e.g. 'is_flatcar' and use that in code, which allows to deduplicate and encapsulate the logic of determining if Flatcar is in use. However, once Ansible bug is fixed on determining 'ansible_os_family' value, this code can be removed and remaining code can stay as is. See links below for more details: - flatcar/scripts#212 - ansible/ansible#77537 - kubernetes-sigs#862 Refs kubernetes-sigs#862 Signed-off-by: Mateusz Gozdek <mgozdekof@gmail.com>
Jeremy-Boyle
pushed a commit
to Jeremy-Boyle/image-builder
that referenced
this pull request
Jun 2, 2022
Flatcar stable relase since 3139.2.0 has removed /etc/flatcar/update.conf file from default instalation, which was used by Ansible to determine the distro type and effectively the value of 'ansible_os_family' fact, which broke building Flatcar images, as now the conditions for tasks does not evaluate properly when running on Flatcar, as 'ansible_os_family' is reported as 'Flatcar Container Linux by Kinvolk' instead of just 'Flatcar'. This commit adds a workaround for this issue by overriding the value for 'ansible_os_family' fact if problematic value is detected. An alternative to this would be to set a custom fact named e.g. 'is_flatcar' and use that in code, which allows to deduplicate and encapsulate the logic of determining if Flatcar is in use. However, once Ansible bug is fixed on determining 'ansible_os_family' value, this code can be removed and remaining code can stay as is. See links below for more details: - flatcar/scripts#212 - ansible/ansible#77537 - kubernetes-sigs#862 Refs kubernetes-sigs#862 Signed-off-by: Mateusz Gozdek <mgozdekof@gmail.com>
MaxRink
pushed a commit
to Das-SCHIFF/image-builder
that referenced
this pull request
Jul 19, 2022
Flatcar stable relase since 3139.2.0 has removed /etc/flatcar/update.conf file from default instalation, which was used by Ansible to determine the distro type and effectively the value of 'ansible_os_family' fact, which broke building Flatcar images, as now the conditions for tasks does not evaluate properly when running on Flatcar, as 'ansible_os_family' is reported as 'Flatcar Container Linux by Kinvolk' instead of just 'Flatcar'. This commit adds a workaround for this issue by overriding the value for 'ansible_os_family' fact if problematic value is detected. An alternative to this would be to set a custom fact named e.g. 'is_flatcar' and use that in code, which allows to deduplicate and encapsulate the logic of determining if Flatcar is in use. However, once Ansible bug is fixed on determining 'ansible_os_family' value, this code can be removed and remaining code can stay as is. See links below for more details: - flatcar/scripts#212 - ansible/ansible#77537 - kubernetes-sigs/image-builder#862 Refs #862 Signed-off-by: Mateusz Gozdek <mgozdekof@gmail.com>
mweibel
pushed a commit
to helio/image-builder
that referenced
this pull request
Aug 11, 2022
Flatcar stable relase since 3139.2.0 has removed /etc/flatcar/update.conf file from default instalation, which was used by Ansible to determine the distro type and effectively the value of 'ansible_os_family' fact, which broke building Flatcar images, as now the conditions for tasks does not evaluate properly when running on Flatcar, as 'ansible_os_family' is reported as 'Flatcar Container Linux by Kinvolk' instead of just 'Flatcar'. This commit adds a workaround for this issue by overriding the value for 'ansible_os_family' fact if problematic value is detected. An alternative to this would be to set a custom fact named e.g. 'is_flatcar' and use that in code, which allows to deduplicate and encapsulate the logic of determining if Flatcar is in use. However, once Ansible bug is fixed on determining 'ansible_os_family' value, this code can be removed and remaining code can stay as is. See links below for more details: - flatcar/scripts#212 - ansible/ansible#77537 - kubernetes-sigs#862 Refs kubernetes-sigs#862 Signed-off-by: Mateusz Gozdek <mgozdekof@gmail.com>
t-lo
pushed a commit
that referenced
this pull request
Apr 17, 2023
Initial steps for python3 transition
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The default image group is already encoded in
/usr/share/flatcar/update.conf but it was written to
/etc/flatcar/update.conf as well. This can cause problems when the user
switches channels by forcing an update to a specific release from the
different channel (e.g., through the flatcar-update tool) as it leaves
the file under /etc/flatcar/update.conf out of sync with the new
channel version in /usr/share/flatcar/update.conf.
Since we don't really need to write a specific channel to /etc on new
images as we can rely on the value from /usr, we now leave any possible
overwriting of the value in /etc entirely to the user.
How to use
Testing done
Scheduled test build and checked that the resulting image has the file missing as expected
changelog/directory (user-facing change, bug fix, security fix, update)