You can start the vote, don't think only PMC needs to do this.
On Wed, Jun 26, 2019, 12:10 Jarek Potiuk wrote:
> Hello everyone (other committers especially) - do you think we need formal
> voting on this? If yes, can I start it, or do we need someone from PMC :)?
>
> Since I am in the last stag
Hello everyone (other committers especially) - do you think we need formal
voting on this? If yes, can I start it, or do we need someone from PMC :)?
Since I am in the last stages of the CI Docker image (all tests are passing
now including Kubernetes) I can apply this scheme to the images in our r
Yes I know. Being perfectionist, I could not help myself to correct it ;).
*Versions from master (development use only):*
- CI slim image *: airflow:master-python3.5-ci-slim,
airflow:**master-python3.6-ci-slim,
airflow:master-ci-slim*==airflow:master-python3.6-ci-slim
- CI full image *:
I like the ordering too. Below is updated proposal:
Ash:
* FROM: - not really, we are using optimised multi-staging Dockerfile to
generate different variants of the images. The variants are independent
from each other but we use one common Dockerfile to generate all of them
(AKA one source of tru
I like this ordering and the reasoning given for it.
> On 18 Jun 2019, at 13:54, Philippe Gagnon wrote:
>
> I know this is bikeshedding at this point but I think something more alone
> the lines of:
>
> `apache/airflow:1.10.4-python3.5[-ci][-slim]`
>
> would be more appropriate as a standard.
Only objection is around airflow:1.10.4-slimci-python3.5 - the way our release
process works that should probably be airflow:1.10.x-slimci-python3.5 or
similar - to represent the release branch, but we don't need a CI version for
the tagged release, just the release branch. I think.
Would the v
I know this is bikeshedding at this point but I think something more alone
the lines of:
`apache/airflow:1.10.4-python3.5[-ci][-slim]`
would be more appropriate as a standard. Here is my rationale:
- The airflow version should definitely come first.
- The python version is the second-most signif
Great :). I'd prefer to use single word rather than ci-slim (then we can
use "-" as separator when splitting image name). The "slimci" seem like
most appropriate :
I also think that it might make sense to build production-optimised images
all the time. This way we will notice when they break and w
"slim" is common amongst docker, so that sounds good.
I think the "primary" docker images should be production focused, and anything
else tagged (i.e. it is prod unless it says otherwise.) Since master is not
meant for end use we could also _only_ have the CI versions of those images.
*Version
Just my 2 cents, at work we tend to use “slim” to denote things that are pared
down.
How about “ci-slim”?
James Coder
> On Jun 18, 2019, at 4:06 AM, Jarek Potiuk wrote:
>
> Ok so then next iteration of proposal: The only doubt I have myself is the
> "master" vs. "master-prod". Maybe we should
Ok so then next iteration of proposal: The only doubt I have myself is the
"master" vs. "master-prod". Maybe we should rather have "master" for
"production-ready" image and use a different name for the "small-ci"
image". Maybe "trimci" or "ci-lite" or "liteci" ?
What do you think?
*Versions from m
That makes sense. The reason I had doubts is because of the way docker hub
lists image tags together -- there's no real differentiation between
pre-release and release builds. But then I suppose that if the tagging
scheme is explicit enough it shouldn't be an issue.
+1 on `:latest` being an offici
* Yeah v2.0.0dev seemed superfluous - we only have one master at the end :)
* The Main image is now "bare" airflow - it contains just bare minimum of
apt-get dependencies needed to install "*all*" extras it's around 415 MB -
In the latest version of the CI image I use it to do all the lightweight
Thinking about it a bit I'd suggest we remove "v2.0.0dev0" when master - at the
point we release 2.0.0 and master becomes 2.1.0dev0 we want master to be that
(and I don't think we want to have the old tags hanging around)
What's the difference between Main non-CI and prod? The "prod" flavour sho
OK. The next build should prepare "master" tags for all the "master"
images: Would such revised labelling make sense?
V*ersions from master (development use only):*
- Main non-CI images (small) *: airflow:master-v2.0.0dev0-python3.5,
airflow:**master-v2.0.0dev0-python3.6, airflow:master*
Sure. I agree "latest" might be misleading until we work out how we release
it so I am fine with changing to master :). It's super easy - merely
changing tags in DockerHub.
On Mon, Jun 17, 2019 at 4:25 PM Ash Berlin-Taylor wrote:
> That page does mention "Nightly" builds which is close to what b
That page does mention "Nightly" builds which is close to what building master
would be. The other thing that matters is what we actual call A Release.
> Do not include any links on the project website that might encourage
> non-developers to download and use nightly builds, snapshots, release
One thing: we talked about releasing images under a "master" tag (perhaps
in another thread?), we should check if this is compatible with Apache's
release policy [1]. It's not clear to me if this is allowable or not after
a cursory reading.
[1] http://www.apache.org/legal/release-policy.html#what
Anyone has more comments. I think prevailing opnion is:
1) To keep all images in one repo (apache/airflow)
2) I am not sure about labelling but I might try to document all cases in a
"production" image proposal that I would like to start as soon as we merge
the current CI image (which I think is qu
It's super easy to do :)
On Tue, Jun 11, 2019 at 10:33 PM Ash Berlin-Taylor wrote:
> I'm fine with us just publishing release images using the newest python
> release (i.e. 3.7) as the main reason we support older python versions is
> to support distros thats ship those versions.(i.e. Deb stable
I'm fine with us just publishing release images using the newest python release
(i.e. 3.7) as the main reason we support older python versions is to support
distros thats ship those versions.(i.e. Deb stable), but I don't think we need
to support that in docker.
(But if it's easy to do since we
Yeah Kamil - python 3.5 is the default one for now. I think we should have
another discussion here - how many versions to support. There is this
ticket opened today : https://issues.apache.org/jira/browse/AIRFLOW-4762 about
supporting python 3.6 and 3.7 in tests. Anyone has a strong opinion on
this
We are already using version.py which is also used by setup.py so we have
one source of truth :).
Principal Software Engineer
Phone: +48660796129
I would prefer to use one repository as well. Building from multiple
repositories, in my opinion, this can become very complex, very easily.
>From what I understand, we should avoid using the latest tag in Docker. The
meaning of the *latest* tag is the latest untagged container. I'm more on
the ex
1) I would prefer to use one repository.
+1
2) The presented schema looks logical to me. I had doubts whether
Python 3.5 was a good choice for "latest" version, but I checked that
travis uses only this version.
On Tue, Jun 11, 2019 at 3:04 PM Jarek Potiuk wrote:
>
> Hello everyone,
>
> We are cl
Hello everyone,
We are close to finish AIP-10 (Airlfow image for CI) and seems that we will
start working soon on an official image AIP, but in the meantime we have
1.10.4 release coming and we would like to agree tagging scheme used for
the current CI images. We discussed it a bit on Slack, but i
26 matches
Mail list logo
