I had recently upgraded airflow version from airflow 1.8 to apache-airflow 1.9, the upgrade was successful and I have scaled the environment using Celery Executor, everything seemed to be working fine but the dag and tasks start dates, execution dates etc all are appearing in UTC timezone and the scheduled dags are running in UTC, earlier before the upgrade they used to run in Local timezone which is pdt.
Any ideas on how to make pdt as the default timezone in airflow?
I have tried using default_timezone in the airflow.cfg to default_timezone = pdt but even after restarting all the services it schedules the dags and tasks in UTC. Looking forward to your help on fixing the default timezone to pdt.
Airflow running in the local timezone prior to version 1.9.0 was unintended and just a side effect of Airflow code using datetime.now() and datetime.today() instead of datetime.utcnow(). This was rectified in 1.9.0 under AIRFLOW-289, making things timezone independent (always UTC) as you have observed.
Official support for Airflow to be timezone aware is merged into the master branch. This work was completed as part of AIRFLOW-288 and is not available in the latest stable version (1.9.0). You can probably expect it in the next major release.
Once you have that change, Matt's answer should get you what you're looking for.
According to these docs, the default_timezone accepts an IANA TZ Database time zone identifier. They are listed here.
If you want US Pacific Time, you should set default_timezone=America/Los_Angeles.
Related
I am trying to upgrade Jenkins from version 2.176.1 to 2.375.2. I tried two methods and both of them failed.
Method-1: Download the jenkins.war and copy it into /usr/lib/jenkins/ directory by replacing the original one. After copying, when I restart Jenkins, it simply fails to restart.
Method-2: Upgrade Jenkins' RPM using yum update jenkins. This command runs successfully and process exists without any error. But, again when I restart Jenkins, it fails to start.
CentOS version: CentOS-7
First of all - I can only support opinion of Dmitriy Tarasevich about reading upgrade guides. You can find theme here: https://www.jenkins.io/doc/upgrade-guide/
Then - stick to the version upgrade process that you've used previously (or for the first time with installation). If you did install it via .*war, don¨t worry and use your Method-1. On the other hand, if you used yum, stick to that method-2.
Then - such a "big" upgrade at once from 2.176.1 to 2.375.1 is, I'd say, the reason it's failing for you as the version in between contain several major/breaking changes (our team has faced the same problem (we "just" wanted to bump the versions too much after a long time of no upgrading and we've faced several problems we weren't able to solve together). So it was necessary to split it into several independent upgrades which appeared to be doable and we managed to get to LTS 2.375).
To summarize recommended steps - I'd you need to:
1/ Split your upgrade into several steps and upgrade LTS more gradually: try to upgrade to first to some not-current LTS version. I believe something less than or precisely 2.303.3 could work and see if you can start it.
then actually run Jenkins and check administration page,
upgrade your plugins (if you want). FYI: this is recommended officially in Jenkins docs after every Jenkins core upgrade.
check Jenkins administration page and apply necessary changes / manage necessary decision that might appear there (if applicable).
2/ Try to upgrade to a higher LTS version (repeat step 1 with its sub-steps)
To be a very specific and give some examples (although I don't remember everything by hearth):
you skipped a gradually upgrade to version 2.319 LTS that brings a major change of working with master node --> built-in node that needs to be applied (confirmed) from within the administration section of Jenkins (see docs: https://www.jenkins.io/doc/book/managing/built-in-node-migration/ )
version 2.332.1 LTS brings an important change. I would say that you've hit exactly this issue (covered here): https://community.jenkins.io/t/jenkins-cant-find-java-after-update-running-on-centos-7/3615 - exact steps and more resources are within that thread and also here: https://www.jenkins.io/doc/upgrade-guide/2.332/#upgrading-to-jenkins-lts-2-332-1
from version 2.361 LTS Jenkins requires Java 11 or higher (see docs https://www.jenkins.io/doc/upgrade-guide/2.361/ ). So - you will need to ensure that you have a proper Java installed (you already might have it though). Including your agents!. Otherwise you would start your Jenkins but it would not connect any agent (usually undesired state).
Please, try to make some gradual progress and let us know where you managed to get
After accidental run, I can't get nextcloud's database and image in sync.
My database is somehow updated to the latest version, but the image (apps) are not.
In my config.php the version is: 'version' => '20.0.5.2'
My version.php shows: $OC_Version = array(22,1,1,2);
If I spin up docker image version 20.0.12, the image keeps restarting with this error:
Can't start Nextcloud because the version of the data (22.1.1.2) is higher than the docker image version (20.0.12.1) and downgrading is not supported. Are you sure you have pulled the newest image version?
But If I start the latest (the same version of the "data") v22.1.1.2, I can't finish the update because:
Updates between multiple major versions and downgrades are unsupported. Can't start Nextcloud because the version of the datais higher than the docker image version and downgrading is not supported.
So I am kind of stuck! I can't run previous the version because the database reports it is updated, and I can't update to the last version, because it is not supported.
What should I do?
I read I have to update 'gradually' but the database reports it's already the latest version.
Just in case somebody is still looking for answer, you need to change your version.php file back to the version matching your last working configuration (in this case probably to 20.0.5.2). Definitely use backup of this file if you have it.
If you have no backup, you can make it yourself as described here: https://help.nextcloud.com/t/skipped-major-version-21-23-did-not-run-the-updater-yet/139638/2?u=vset
I'm developing an python-django app running in docker containers (django, celery, postgres, redist...etc). It runs on Windows 10 with WSL2-Debian & Docker Desktop.
During my work I need to observe the consoles of all those containers, so I can monitor apps behavior, like when you run docker-compose up so you got all of them live.
When you click on the container within windowed Docker Desktop app you can see the container's console output, but not actual - it looks like it works until some point of time and there are no updates of the consoles output.
I remember it was working live just prior to a two or three Docker Desktop updates, and I'm sure it was real time there, but not now.
Did I change a setting or Docker Desktop was bugged?
PS. When I start my containers with docker-compose up (without -d) I can observe live logs on my shell console, but not in Docker Desktop anymore.
Any help how to restore Docker Desktop live console view?
The Docker Desktop 3.4 (released June 9th, yesterday) is supposed to have resolved docker/for-win issue 11251.
I don't see the error after upgrading (with the normal docker-compose, not the beta docker-compose v2).
However, as commented by the OP twk and in issue 11251:
the live log is somehow broken - extra newline is added after every new line, but historical log entries (Eg. when you switch to/from another container) are displayed without newlines between entries (which is OK).
Update June 29th from Mathieu Champlon
Sorry it took a while but we now have an internal build that should fix it, if you wanted to give it a try:
win/stable/amd64/66242/Docker Desktop Installer.exe
Update Aug. 2021: Issue 11251 just closed with:
Docker Desktop 3.6.0 has been released containing a fix for this issue.
It's a bug in Docker Desktop v3.3.3
GitHub issue: https://github.com/docker/for-win/issues/11251 as pointed by #Drarig29
I am having some performance problems when I am starting Jenkins inside Kubernetes cluster.
One of the points that sometimes occurs and it takes so much time is next operation:
INFO: Finished Download metadata. 1,397 ms
In this case, it is just 1 second but sometimes it takes like 40 seconds. I have tried to find this log message in Jenkins core but I have not found it, so I suspect it is some plugin. My question where is this happening, what is doing and why it is required.
Thanks.
Feb 10, 2018 2:04:22 PM hudson.model.AsyncPeriodicWork$1 run
INFO: Started Download metadata
Feb 10, 2018 2:04:22 PM hudson.model.AsyncPeriodicWork$1 run
INFO: Finished Download metadata. 4 ms
Believe you are referring to the logs like the one above. If yes, these are the log rotation strategy logs thats gets executed through AsyncPeriodicWork class and it is configured in Jenkins specifically for discarding Old Builds.
Following image gives you the configuration in Jenkins UI
You can appropriately configure this based on your project requirements, if you feel this is impacting your startup time.
I successfully installed a freshly downloaded virtual instance a few days ago, running in VirtualBox on Windows 10. Seems to be working fine. Noticed that under 'Statistics' on the home page is was dated April 2016. Configured with a key for replication, ran 'bin/replicate start' and now the Statistics page update is 05/22/16. Interestingly the mirror http://musicbrainz-mirror.eu:5000/ shows the same 05/22/16 date.
It seems the database schema changed on 05/23/16 (https://blog.musicbrainz.org/2016/05/25/schema-change-release-2016-05-23-with-upgrade-instructions/) but the virtual machine available for download is dated 2015-08-06 on http://musicbrainz.org/doc/MusicBrainz_Server/Setup
So automatic updating stops at 5/22 with the current virtual machine. Seems to make sense but where is the latest virtual machine build, or is that left to the user to build from the GitHub repository?
Follow the instructions to update the schema:
https://blog.musicbrainz.org/2016/05/25/schema-change-release-2016-05-23-with-upgrade-instructions/
Note that you may need to update PostgreSQL to 9.5 (the VM image has an older version) first. Also, since more than a month has passed from your version, it may be easier to import a new dump and then turn the replication on, rather than go through all incremental updates.
EDIT:
You can find the latest VM here.