Skip to content

Conversation

@potiuk
Copy link
Member

@potiuk potiuk commented Sep 24, 2022

In order to avoid initialisation of database and other integrations when you are entering/leaving breeze, those are started when breeze starts but not stopped when you leave. Then stopping such running auxiliary containers should be done with breeze stop after you are done. However those who do not do it, and will restart their machine will find that the containers get restarted.

This has been added as part of #13446 where health-checks are added. However "always" was not a good choice. It should have been "on-failure"


^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

In order to avoid initialisation of database and other integrations
when you are entering/leaving breeze, those are started when breeze
starts but not stopped when you leave. Then stopping such running
auxiliary containers should be done with `breeze stop` after you
are done. However those who do not do it, and will restart their
machine will find that the containers get restarted.

This has been added as part of apache#13446 where health-checks are added.
However "always" was not a good choice. It should have been "on-failure"
@potiuk
Copy link
Member Author

potiuk commented Sep 24, 2022

@mik-laj -> as @dstandish noticed in https://apache-airflow.slack.com/archives/CCPRP7943/p1663959432825839 - we have containers restarting on rebooting the machine/docker after adding the health check (so if you have not run breeze stop, the docker containers will be restarted even after you stop and start the daemon) and I believe it can be just replaced by "on-failure", but maybe there was other reason for "always"?

@potiuk potiuk merged commit 337146d into apache:main Sep 25, 2022
@potiuk potiuk deleted the disable-restarting-of-breeze-dockers branch September 25, 2022 19:52
@ephraimbuddy ephraimbuddy added the changelog:skip Changes that should be skipped from the changelog (CI, tests, etc..) label Oct 18, 2022
@ephraimbuddy ephraimbuddy modified the milestone: Airflow 2.4.2 Oct 18, 2022
ephraimbuddy pushed a commit that referenced this pull request Nov 10, 2022
In order to avoid initialisation of database and other integrations
when you are entering/leaving breeze, those are started when breeze
starts but not stopped when you leave. Then stopping such running
auxiliary containers should be done with `breeze stop` after you
are done. However those who do not do it, and will restart their
machine will find that the containers get restarted.

This has been added as part of #13446 where health-checks are added.
However "always" was not a good choice. It should have been "on-failure"

(cherry picked from commit 337146d)
ephraimbuddy pushed a commit that referenced this pull request Nov 10, 2022
In order to avoid initialisation of database and other integrations
when you are entering/leaving breeze, those are started when breeze
starts but not stopped when you leave. Then stopping such running
auxiliary containers should be done with `breeze stop` after you
are done. However those who do not do it, and will restart their
machine will find that the containers get restarted.

This has been added as part of #13446 where health-checks are added.
However "always" was not a good choice. It should have been "on-failure"

(cherry picked from commit 337146d)
@ephraimbuddy ephraimbuddy added this to the Airflow 2.4.3 milestone Nov 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:dev-tools changelog:skip Changes that should be skipped from the changelog (CI, tests, etc..)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants