Makes sense, let's move this discussion to JIRA instead of using this
closed vote thread!
Gyula
On Wed, Feb 1, 2023 at 12:08 PM Maximilian Michels wrote:
> +1 Not updating the generation id when the effective deployment spec
> does not change is an oversight, which we missed here, but it can
+1 Not updating the generation id when the effective deployment spec
does not change is an oversight, which we missed here, but it can be
fixed.
On Wed, Feb 1, 2023 at 2:07 AM Thomas Weise wrote:
>
> Hi,
>
> Sorry for the late reply to this thread, but in the meantime we learned that
> the
Hi,
Sorry for the late reply to this thread, but in the meantime we learned
that the assumption based on which the above mentioned change to
upgradeMode was approved does not hold true. The assumption was that the
generation id in spec metadata and reconciled spec can be used to determine
if
I'm happy to announce that we have unanimously approved this release.
There are 6 approving votes, 3 of which are binding:
* Marton Balassi (binding)
* Gyula Fora (binding)
* Maximilian Mixhels (binding)
* Jim Busche
* Geng Biao
* Hao t Chang
There are no disapproving votes.
Thanks everyone!
Thank you all for testing this, closing the vote now.
Gyula
On Mon, Jan 9, 2023 at 5:27 PM Maximilian Michels wrote:
> +1 (binding)
>
> Thanks for clarifying. I wanted to make sure this is not an unintended
> regression.
>
> On Mon, Jan 9, 2023 at 4:26 PM Gyula Fóra wrote:
>
> > @Maximilian
+1 (binding)
Thanks for clarifying. I wanted to make sure this is not an unintended
regression.
On Mon, Jan 9, 2023 at 4:26 PM Gyula Fóra wrote:
> @Maximilian Michels this is a completely intentional
> improvement and it is required to ensure consistency for some operations
> within the
@Maximilian Michels this is a completely intentional
improvement and it is required to ensure consistency for some operations
within the operator logic.
On Mon, Jan 9, 2023 at 4:06 PM Maximilian Michels wrote:
> +0
>
> 1. Downloaded the source archive release staged at
>
>
+0
1. Downloaded the source archive release staged at
https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-1.3.1-rc1/
2. Verified the signature
3. Inspected the extracted source code for binaries
4. Compiled the source code
5. Verified license files / headers
6. Deployed to test
I did the following:
Ran OLM bundle CI test suite for Kubernetes.
Generated and Deployed OLM bundle.
Created standalone/session jobs.
All Look good. Thanks for managing the release!
--
Best,
Ted Chang | Software Engineer | htch...@us.ibm.com
with basic HA example
- Verified the Dynamic Operator Configuration works as expected by editing the
operator’s ConfigMap
Best,
Biao Geng
From: Gyula Fóra
Date: Monday, January 2, 2023 at 2:42 AM
To: dev
Subject: [VOTE] Apache Flink Kubernetes Operator Release 1.3.1, release
candidate #1
Hi
+1 (binding)
- Verified hashes, signatures, notice files and source release.
- Verified and tested Helm chart/repo
- Ran stateful examples with complex upgrade scenarios involving failures,
verified all works as expected and logs look good.
Cheers,
Gyula
On Wed, Jan 4, 2023 at 12:49 AM Jim
Thanks Gyula for the release.
+1 (non-binding)
I tested the following:
* Helm repo install from flink-kubernetes-operator-1.3.1-helm.tgz
* podman Dockerfile build from source looks good
*twistlock security scans of the proposed image look good, no currently
known vulnerabilities
Thank you, Gyula.
+1 (binding)
- Verified Helm repo works as expected, points to correct image tag, build,
version
- Verified basic examples + checked operator logs everything looks as
expected
- Verified hashes, signatures and source release contains no binaries
- Ran built-in tests, built jars
Hi everyone,
Please review and vote on the release candidate #1 for the version 1.3.1 of
Apache Flink Kubernetes Operator,
as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)
**Release Overview**
As an overview, the release consists of
14 matches
Mail list logo
