background: - Currently we use buildkite to automa...
# troubleshooting
a
background: • Currently we use buildkite to automate workflows through meltano container hosted on AWS, but we want to start testing out airflow as the scheduler. • I am currently testing locally, but still containerized, I have run the meltano install command and added airflow everywhere to the docker-compose so that the right containers are spun up. My question is: Is there a way to create an airflow user within the invoke statement? or is there best recommended practices or where to create that airflow user so when we invoke it, the user already exists? (not sure if this should go in best-practices or here, felt more like troubleshooting to start)
p
@aditya_goyal are you running airflow in a container too? Maybe sharing your docker compose or your commands could help. My first thought is that you could use docker exec to run a command like
Copy code
meltano invoke airflow users create --username melty \
 --firstname melty \
 --lastname meltano \
 --role Admin \
 --password melty \
 --email <mailto:melty@meltano.com|melty@meltano.com>
from https://docs.meltano.com/getting-started#schedule-pipelines-to-run-regularly inside your airflow container after its up. Am I understanding what youre looking for? Its not an ideal solution, if you have an idea of how to do it better you can submit an issue to suggest
a
oops sorry for not sharing that earlier. Basically I just uncommented out all the yaml from the docker-compose.prod.yaml file from gitlab.
my first thought was to add an airflow-init part to the yaml. Was mostly wondering if there is a best practice for creating that user or not
Copy code
airflow-init:
    <<: *airflow-common
    command: version
    environment:
      <<: *airflow-common-env
      _AIRFLOW_DB_UPGRADE: 'true'
      _AIRFLOW_WWW_USER_CREATE: 'true'
      _AIRFLOW_WWW_USER_USERNAME: ${_AIRFLOW_WWW_USER_USERNAME:-airflow}
      _AIRFLOW_WWW_USER_PASSWORD: ${_AIRFLOW_WWW_USER_PASSWORD:-airflow}
@pat_nadolny just checking in if you have any thoughts, otherwise I will just go with the docs solution! thanks!
p
Hey @aditya_goyal your init container option seems like a good one! I know init containers are a common practice. If it ends up working well for you, definitely consider contributing it back to the gitlab docker compose so others can benefit too!
a
will test out!