You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Gyula Fóra <gy...@apache.org> on 2022/06/14 12:10:14 UTC
[DISCUSS] Dockerimage + Helm chart only patch releases for the Kubernetes operator
Hi Devs!
I would like to discuss/propose a new release flow for the Kubernetes
operator patch releases.
For the operator the main logic (and the bugs) are part of the operator
docker image and the helm charts associated with it. It would be nice to be
able to have lightweight patch releases that only contain the docker
image + updated Helm chart.
This would allow us to give users new docker image releases in a short
period of time with reduced testing and voting overhead (these patch
releases could have a shorter voting period also).
This would also have the implication that any API related change / fix has
to be a minor version bump, but I think that is also reasonable.
Another alternative would be to simply not have these patch releases and
encourage users to pick up the latest automatic image builds from
https://ghcr.io/apache/flink-kubernetes-operator for the current release
branch, but I feel that production users would not feel very good about
this.
Cheers,
Gyula
Re: [DISCUSS] Dockerimage + Helm chart only patch releases for the Kubernetes operator
Posted by Yang Wang <da...@gmail.com>.
From what I have learned from the last 1.0.0 release, I think it is not too
complicated and a big burden for flink-kubernetes-operator patch releases.
The major bottleneck might be the VOTE duration(e.g. jet lag, the weekend).
We almost need one week for the release after all the blockers are resolved.
Given that we already provide the snapshot image via github packages for
every commit, I believe it is easy for users to upgrade the operator if it
is really necessary and could not wait for the next release.
Best,
Yang
Chesnay Schepler <ch...@apache.org> 于2022年6月14日周二 20:46写道：
> My bad, our bylaws actually state that release votes must have a minimum
> 3 days duration.
>
> On 14/06/2022 14:46, Chesnay Schepler wrote:
> > Yes, pretty much.
> >
> > Mind you that the 72h voting duration is a recommendation by the ASF;
> > it's not a strict rule.
> > AFAICT we also haven't locked this down in our bylaws, apart from
> > requiring 3 votes.
> >
> > On 14/06/2022 14:25, Gyula Fóra wrote:
> >> I think what you are referring to is here:
> >> https://www.apache.org/legal/release-policy.html#source-packages
> >>
> >> Based on this we probably cannot simply release the docker image. We
> >> could
> >> decide to not release the maven artifacts though, but that seems to be a
> >> minor difference and probably not worth it.
> >>
> >> Gyula
> >>
> >> On Tue, Jun 14, 2022 at 2:19 PM Gyula Fóra <gy...@apache.org> wrote:
> >>
> >>> Thanks Chesnay, these are exactly the questions I would like to clarify
> >>> because I don't really understand the limitations/boundaries of the
> >>> apache
> >>> release process.
> >>>
> >>> Is there a strict requirement to have a source release accompany the
> >>> docker image? I will have to look this up.
> >>>
> >>> Gyula
> >>>
> >>> On Tue, Jun 14, 2022 at 2:16 PM Chesnay Schepler <ch...@apache.org>
> >>> wrote:
> >>>
> >>>> On 14/06/2022 14:10, Gyula Fóra wrote:
> >>>>> For the operator the main logic (and the bugs) are part of the
> >>>>> operator
> >>>>> docker image and the helm charts associated with it. It would be nice
> >>>> to be
> >>>>> able to have lightweight patch releases that only contain the docker
> >>>>> image + updated Helm chart.
> >>>>>
> >>>>> This would allow us to give users new docker image releases in a
> >>>>> short
> >>>>> period of time with reduced testing and voting overhead (these patch
> >>>>> releases could have a shorter voting period also).
> >>>> I'm not sure if this is allowed because it sounds like you're
> >>>> proposing
> >>>> to release binaries without an associated source release
> >>>>
> >>>>
> >
>
>
Re: [DISCUSS] Dockerimage + Helm chart only patch releases for the Kubernetes operator
Posted by Chesnay Schepler <ch...@apache.org>.
My bad, our bylaws actually state that release votes must have a minimum
3 days duration.
On 14/06/2022 14:46, Chesnay Schepler wrote:
> Yes, pretty much.
>
> Mind you that the 72h voting duration is a recommendation by the ASF;
> it's not a strict rule.
> AFAICT we also haven't locked this down in our bylaws, apart from
> requiring 3 votes.
>
> On 14/06/2022 14:25, Gyula Fóra wrote:
>> I think what you are referring to is here:
>> https://www.apache.org/legal/release-policy.html#source-packages
>>
>> Based on this we probably cannot simply release the docker image. We
>> could
>> decide to not release the maven artifacts though, but that seems to be a
>> minor difference and probably not worth it.
>>
>> Gyula
>>
>> On Tue, Jun 14, 2022 at 2:19 PM Gyula Fóra <gy...@apache.org> wrote:
>>
>>> Thanks Chesnay, these are exactly the questions I would like to clarify
>>> because I don't really understand the limitations/boundaries of the
>>> apache
>>> release process.
>>>
>>> Is there a strict requirement to have a source release accompany the
>>> docker image? I will have to look this up.
>>>
>>> Gyula
>>>
>>> On Tue, Jun 14, 2022 at 2:16 PM Chesnay Schepler <ch...@apache.org>
>>> wrote:
>>>
>>>> On 14/06/2022 14:10, Gyula Fóra wrote:
>>>>> For the operator the main logic (and the bugs) are part of the
>>>>> operator
>>>>> docker image and the helm charts associated with it. It would be nice
>>>> to be
>>>>> able to have lightweight patch releases that only contain the docker
>>>>> image + updated Helm chart.
>>>>>
>>>>> This would allow us to give users new docker image releases in a
>>>>> short
>>>>> period of time with reduced testing and voting overhead (these patch
>>>>> releases could have a shorter voting period also).
>>>> I'm not sure if this is allowed because it sounds like you're
>>>> proposing
>>>> to release binaries without an associated source release
>>>>
>>>>
>
Re: [DISCUSS] Dockerimage + Helm chart only patch releases for the Kubernetes operator
Posted by Chesnay Schepler <ch...@apache.org>.
Yes, pretty much.
Mind you that the 72h voting duration is a recommendation by the ASF;
it's not a strict rule.
AFAICT we also haven't locked this down in our bylaws, apart from
requiring 3 votes.
On 14/06/2022 14:25, Gyula Fóra wrote:
> I think what you are referring to is here:
> https://www.apache.org/legal/release-policy.html#source-packages
>
> Based on this we probably cannot simply release the docker image. We could
> decide to not release the maven artifacts though, but that seems to be a
> minor difference and probably not worth it.
>
> Gyula
>
> On Tue, Jun 14, 2022 at 2:19 PM Gyula Fóra <gy...@apache.org> wrote:
>
>> Thanks Chesnay, these are exactly the questions I would like to clarify
>> because I don't really understand the limitations/boundaries of the apache
>> release process.
>>
>> Is there a strict requirement to have a source release accompany the
>> docker image? I will have to look this up.
>>
>> Gyula
>>
>> On Tue, Jun 14, 2022 at 2:16 PM Chesnay Schepler <ch...@apache.org>
>> wrote:
>>
>>> On 14/06/2022 14:10, Gyula Fóra wrote:
>>>> For the operator the main logic (and the bugs) are part of the operator
>>>> docker image and the helm charts associated with it. It would be nice
>>> to be
>>>> able to have lightweight patch releases that only contain the docker
>>>> image + updated Helm chart.
>>>>
>>>> This would allow us to give users new docker image releases in a short
>>>> period of time with reduced testing and voting overhead (these patch
>>>> releases could have a shorter voting period also).
>>> I'm not sure if this is allowed because it sounds like you're proposing
>>> to release binaries without an associated source release
>>>
>>>
Re: [DISCUSS] Dockerimage + Helm chart only patch releases for the Kubernetes operator
Posted by Gyula Fóra <gy...@apache.org>.
I think what you are referring to is here:
https://www.apache.org/legal/release-policy.html#source-packages
Based on this we probably cannot simply release the docker image. We could
decide to not release the maven artifacts though, but that seems to be a
minor difference and probably not worth it.
Gyula
On Tue, Jun 14, 2022 at 2:19 PM Gyula Fóra <gy...@apache.org> wrote:
> Thanks Chesnay, these are exactly the questions I would like to clarify
> because I don't really understand the limitations/boundaries of the apache
> release process.
>
> Is there a strict requirement to have a source release accompany the
> docker image? I will have to look this up.
>
> Gyula
>
> On Tue, Jun 14, 2022 at 2:16 PM Chesnay Schepler <ch...@apache.org>
> wrote:
>
>> On 14/06/2022 14:10, Gyula Fóra wrote:
>> > For the operator the main logic (and the bugs) are part of the operator
>> > docker image and the helm charts associated with it. It would be nice
>> to be
>> > able to have lightweight patch releases that only contain the docker
>> > image + updated Helm chart.
>> >
>> > This would allow us to give users new docker image releases in a short
>> > period of time with reduced testing and voting overhead (these patch
>> > releases could have a shorter voting period also).
>>
>> I'm not sure if this is allowed because it sounds like you're proposing
>> to release binaries without an associated source release
>>
>>
Re: [DISCUSS] Dockerimage + Helm chart only patch releases for the Kubernetes operator
Posted by Gyula Fóra <gy...@apache.org>.
Thanks Chesnay, these are exactly the questions I would like to clarify
because I don't really understand the limitations/boundaries of the apache
release process.
Is there a strict requirement to have a source release accompany the docker
image? I will have to look this up.
Gyula
On Tue, Jun 14, 2022 at 2:16 PM Chesnay Schepler <ch...@apache.org> wrote:
> On 14/06/2022 14:10, Gyula Fóra wrote:
> > For the operator the main logic (and the bugs) are part of the operator
> > docker image and the helm charts associated with it. It would be nice to
> be
> > able to have lightweight patch releases that only contain the docker
> > image + updated Helm chart.
> >
> > This would allow us to give users new docker image releases in a short
> > period of time with reduced testing and voting overhead (these patch
> > releases could have a shorter voting period also).
>
> I'm not sure if this is allowed because it sounds like you're proposing
> to release binaries without an associated source release
>
>
Re: [DISCUSS] Dockerimage + Helm chart only patch releases for the Kubernetes operator
Posted by Chesnay Schepler <ch...@apache.org>.
On 14/06/2022 14:10, Gyula Fóra wrote:
> For the operator the main logic (and the bugs) are part of the operator
> docker image and the helm charts associated with it. It would be nice to be
> able to have lightweight patch releases that only contain the docker
> image + updated Helm chart.
>
> This would allow us to give users new docker image releases in a short
> period of time with reduced testing and voting overhead (these patch
> releases could have a shorter voting period also).
I'm not sure if this is allowed because it sounds like you're proposing
to release binaries without an associated source release
Re: [DISCUSS] Dockerimage + Helm chart only patch releases for the Kubernetes operator
Posted by Chesnay Schepler <ch...@apache.org>.
On 14/06/2022 14:10, Gyula Fóra wrote:
> Another alternative would be to simply not have these patch releases and
> encourage users to pick up the latest automatic image builds from
> https://ghcr.io/apache/flink-kubernetes-operator for the current release
> branch, but I feel that production users would not feel very good about
> this.
This is not an alternative. We are straight-up not allowed to direct
users to artifacts that weren't voted on.