potiuk commented on code in PR #24185:
URL: https://github.com/apache/airflow/pull/24185#discussion_r889703138
##########
dev/breeze/src/airflow_breeze/commands/developer_commands.py:
##########
@@ -601,7 +602,13 @@ def run_shell(verbose: bool, dry_run: bool, shell_params:
ShellParams) -> RunCom
env_variables = get_env_variables_for_docker_commands(shell_params)
if cmd_added is not None:
cmd.extend(['-c', cmd_added])
-
+ if "arm64" in DOCKER_DEFAULT_PLATFORM:
Review Comment:
BTW. This is just a "diagnostics" check that prints clear and explanatory
message to the user. We do not "check" if ARM is supported for MySQL and MsSQL
- that is far more complex than this simple diagnostics message:
* first of all the images have to be supported for MySQL and MsSQL for ARM.
this is not happening now:
* MSSQL images are AMD-only
https://hub.docker.com/_/microsoft-mssql-server
* MYSQL images have an ARM image https://hub.docker.com/_/mysql?tab=tags
which is tagged as -oracle for MySQL 10 only.
* but more importantly - our ARM images currently have no MySQL/MSSQL
clients included - mssql does not provide ARM client at all and MySQL only has
one for CentOS but not one for debian
(https://www.mysql.com/fr/support/supportedplatforms/database.html) MySQL on
the other hand provides ARM clients for debian (so we could theorethically
include them as of March) but it makes little sense as they cannot be tested as
there is no mysql ARM64 server image.
So a number of conditions there to support ARM for those two database is not
simple, and I attempt - from time to to time - to see if they are included
(also every time before we start preparing to new release)
For MySQL we might also (this is a thought I have and we might want to do
it) is to complicate our image quit a bit and have a variant based on CentOS
(there are were some people who wanted it), but that would be quite major
undertaking as CentoOS uses yum rather than apt and we would have to make quite
more complex installation scripts to account for that (or even end up with
splitting the Dockerfile. So for now we just support debian buster/bullseye
(and I am not sure about the -oracle image from MySQL, I could not easily find
what is a difference vs. the base MySQL image and the `-oracle` one but it
smells licensing might be different there (but I have not looked too much into
it as we would also have to make CentOS variant of the image). But maybe soon
CentOS idea will be back.
If you think we can add such description to some of our vast documentation -
feel free to make PR:).
But I feel that documenting such "temporary" state and all the why's and
how's is quite a bit too detailed - especially that it will likely change in a
couple of months. We already have too much documentaion in places and we need
to trim it down and likely approach it differently - for example in Breeze I
converted the docs to "ADR" (Architecture Decision Records") where we captured
all context and "whys" and "decisions" and separate User documentation where we
simply target the users (and it's actually now split according to "types" of
users using Breeze). I don't see the kind of temporary "why we do not currently
support ARM and how to check it and what are the steps to migrate when we can "
to fit either of the doc types to be honest.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
