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/03/28 14:14:38 UTC
[VOTE] Apache Flink Kubernetes Operator Release 0.1.0, release candidate #1
Hi everyone,
Please review and vote on the release candidate #1 for the version 0.1.0 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 the following:
a) Kubernetes Operator canonical source distribution (including the
Dockerfile), to be deployed to the release repository at dist.apache.org
b) Kubernetes Operator Helm Chart to be deployed to the release repository
at dist.apache.org
c) Maven artifacts to be deployed to the Maven Central Repository
**Staging Areas to Review**
The staging areas containing the above mentioned artifacts are as follows,
for your review:
* All artifacts for a,b) can be found in the corresponding dev repository
at dist.apache.org [1]
* All artifacts for c) can be found at the Apache Nexus Repository [2]
All artifacts are signed with the
key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3]
Other links for your review:
* JIRA release notes [4]
* source code tag "release-0.1.0-rc1" [5]
* PR to update the website Downloads page to include Kubernetes Operator
links [6]
**Vote Duration**
The voting time will run for at least 72 hours.
It is adopted by majority approval, with at least 3 PMC affirmative votes.
**Note for Functional Verification**
Please use the source distribution and helm chart directly from [1] to
build and deploy the operator in your testing environment.
Thanks,
Gyula
[1]
https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/
[2] https://repository.apache.org/content/repositories/orgapacheflink-1490/
[3] https://dist.apache.org/repos/dist/release/flink/KEYS
[4]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499
[5]
https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1
[6] https://github.com/apache/flink-web/pull/519
Re: [VOTE] Apache Flink Kubernetes Operator Release 0.1.0, release candidate #1
Posted by Gyula Fóra <gy...@apache.org>.
Hi devs,
I am cancelling this vote, and will prepare a new RC with the notice fixes
included.
Thanks,
Gyula
On Tue, Mar 29, 2022 at 7:42 AM Gyula Fóra <gy...@gmail.com> wrote:
> Thank you all for the input, let’s consider this a blocker.
>
> As soon as we have the NOTICE fix , I will prepare the new RC.
>
> Gyula
>
> On Tue, 29 Mar 2022 at 06:51, Yang Wang <da...@gmail.com> wrote:
>
>> Given that *flink-kubernetes-shaded* already contains a NOTICE file, and
>> *flink-kubernetes-webhook* does not bundle any dependencies.
>> IIUC, what we should do now is to add a correct NOTICE file only for the
>> *flink-kubernetes-operator* module.
>>
>> If I do not miss anything, this would not be very difficult and I would
>> like to fix it.
>>
>>
>> Best,
>> Yang
>>
>> Thomas Weise <th...@apache.org> 于2022年3月29日周二 11:25写道：
>>
>> > I believe if we as the PMC distribute a docker image (which is optional,
>> > "convenience"), then that image has to follow the rules for binary
>> packages
>> > [1]. (And I would assume that applies regardless where we host the
>> images.)
>> >
>> > Now to say that we only publish sources kind of side steps that
>> problem. At
>> > the same time it probably also defeats the purpose of the preview
>> release,
>> > which is to make it easier for folks that are not active contributors to
>> > take the operator for a test drive.
>> >
>> > So I'm leaning towards publishing the images with respective NOTICE
>> > requirements (for the layers that we add).
>> >
>> > We are also planning to publish the jar files in the future as it helps
>> to
>> > build clients and those would need to have the binary NOTICE also.
>> >
>> > Cheers,
>> > Thomas
>> >
>> > [1] https://infra.apache.org/licensing-howto.html#binary
>> >
>> > On Mon, Mar 28, 2022 at 9:20 AM Gyula Fóra <gy...@apache.org> wrote:
>> >
>> > > I see your point and the value for having such a notice added.
>> > >
>> > > I think there are 2 completely distinct questions at play here:
>> > >
>> > > a) Is there a legal requirement for a NOTICE file for the docker
>> image?
>> > > b) If not, should we block the release on this and add it immediately?
>> > >
>> > > For a)
>> > > I think from a legal (and ASF policy) perspective there is one
>> question
>> > > that decides whether this is a requirement for this release or not:
>> > > Is the docker image part of the release?
>> > >
>> > > I think the answer here is clearly no, the image is not part of the
>> > > release. Only the Dockerfile is part of the release.
>> > >
>> > > For b)
>> > > I think adding the NOTICE is a good idea but it will take some work
>> so I
>> > > would not block the preview release on it.
>> > > If someone has some handy utility or experience generating it, I don't
>> > mind
>> > > including it in later RCs of course.
>> > > Otherwise we can aim for the next release.
>> > >
>> > > Gyula
>> > >
>> > >
>> > > On Mon, Mar 28, 2022 at 6:03 PM Chesnay Schepler <ch...@apache.org>
>> > > wrote:
>> > >
>> > > > One difference to Flink is that the distribution bundled in the
>> docker
>> > > > image still contains the NOTICE covering the contents of it.
>> > > >
>> > > > It may admittedly not be the most discoverable place, but a
>> reasonable
>> > > one
>> > > > I think.
>> > > >
>> > > > Docker as a whole is very weird when it comes to licensing.
>> > > > Think of all the things are are shipped in an image; I don't think
>> we
>> > can
>> > > > (nor should) try to document everything in there.
>> > > > For the most part this is also not necessary as the Flink images are
>> > > based
>> > > > on Debian,
>> > > > where (al)most every installed package already embeds licensing
>> > > > information into the image.
>> > > >
>> > > > However, for content that we copy into the image (i.e., the jars), I
>> > > think
>> > > > it would be reasonable to document that.
>> > > > (and based on experience from the Flink side has also shown other
>> > > > advantages beyond licensing...)
>> > > >
>> > > > On 28/03/2022 17:41, Gyula Fóra wrote:
>> > > >
>> > > > Thanks for the input!
>> > > >
>> > > > I am not an expert on this topic and have been contemplating this
>> > myself
>> > > > also.
>> > > > We are basically trying to follow the precedent set by Flink and
>> > Statefun
>> > > > projects where the docker builds that we use to publish images to
>> > > > dockerhub do not declare any notices.
>> > > >
>> > > > We will not use ghcr.io for the final release but will use
>> dockerhub
>> > > like
>> > > > flink and other apache projects.
>> > > >
>> > > > If I look at it from a strictly technical point of view, the docker
>> > image
>> > > > is not part of the official release (as it's also not part of the
>> > > > flink/statefun release).
>> > > >
>> > > > It would be good to get some input from others on this. It's not
>> > > > impossible to add the notices but it's considerable work and
>> > maintenance
>> > > > overhead.
>> > > > By extending the logic would you then also add license information
>> for
>> > > the
>> > > > base images of the docker container (and so on so forth)?
>> > > >
>> > > > My gut feeling would be that we could highlight this in the NOTICE
>> of
>> > the
>> > > > main project (or some other appropriate place) but we do not
>> > explicitly
>> > > > list the dependencies.
>> > > >
>> > > > Would be good to hear how others feel about this!
>> > > >
>> > > > Gyula
>> > > >
>> > > > On Mon, Mar 28, 2022 at 5:26 PM Chesnay Schepler <
>> chesnay@apache.org>
>> > > > wrote:
>> > > >
>> > > >> I don't think having users build the fat-jar & docker image
>> absolves
>> > us
>> > > >> of all responsibility w.r.t. the licensing of used products.
>> > > >>
>> > > >> At the very least we need to inform users what licenses the
>> fat-jar &
>> > > >> docker image fall under such that they can make an informed
>> decision
>> > as
>> > > to
>> > > >> whether they can adhere to said restrictions.
>> > > >> In particular since building it yourself is (apparently) a hard
>> > > >> requirement for using said product.
>> > > >>
>> > > >> Even beyond that though, as *we* push images to ghcr.io we still
>> need
>> > > to
>> > > >> adhere to the licensing requirements in any case afaict.
>> > > >>
>> > > >> On 28/03/2022 17:07, Gyula Fóra wrote:
>> > > >>
>> > > >> Hi Chesnay,
>> > > >>
>> > > >> Let me try to explain the "strange stuff"
>> > > >>
>> > > >> flink-kubernetes-shaded relocates some classes found in
>> > flink-kubernetes
>> > > >> in order to not conflict with some of the operator dependencies.
>> > > >> This is necessary as flink-kubernetes packages almost everything in
>> > the
>> > > >> fat-jar as-is without relocation. I think this should be fine from
>> a
>> > > >> release perspective, as flink-kubernetes already contains the
>> > > >> relevant notice files.
>> > > >>
>> > > >> For flink-kubernetes-operator we are not releasing a fat-jar as we
>> > > don't
>> > > >> have any client binaries etc. It is not necessary for the users
>> > > therefore
>> > > >> it's not part of the release.
>> > > >> We release the Dockerfile instead so that users can build the
>> image.
>> > > >> Since the fatjar is not part of the release we do not have bundled
>> > > >> dependencies, and we do not need extra licensing information I
>> > believe.
>> > > >>
>> > > >> Cheers,
>> > > >> Gyula
>> > > >>
>> > > >> On Mon, Mar 28, 2022 at 4:40 PM Chesnay Schepler <
>> chesnay@apache.org>
>> > > >> wrote:
>> > > >>
>> > > >>> There's some strange stuff in here.
>> > > >>>
>> > > >>> What exactly is the purpose of flink-kubernetes-shaded? You're
>> just
>> > > >>> re-packaging flink-kubernetes without making any changes.
>> > > >>>
>> > > >>> The uploaded flink-kubernetes-operator jar isn't bundling any
>> > > >>> dependencies. Why is the fat jar not uploaded? Is it used anywhere
>> > else
>> > > >>> (e.g., directly embedded into a docker image)
>> > > >>> If it is used, where do you have the appropriate licensing
>> > information
>> > > >>> for the bundled dependencies?
>> > > >>>
>> > > >>> On 28/03/2022 16:14, Gyula Fóra wrote:
>> > > >>> > Hi everyone,
>> > > >>> >
>> > > >>> > Please review and vote on the release candidate #1 for the
>> version
>> > > >>> 0.1.0 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 the following:
>> > > >>> > a) Kubernetes Operator canonical source distribution (including
>> the
>> > > >>> > Dockerfile), to be deployed to the release repository at
>> > > >>> dist.apache.org
>> > > >>> > b) Kubernetes Operator Helm Chart to be deployed to the release
>> > > >>> repository
>> > > >>> > at dist.apache.org
>> > > >>> > c) Maven artifacts to be deployed to the Maven Central
>> Repository
>> > > >>> >
>> > > >>> > **Staging Areas to Review**
>> > > >>> >
>> > > >>> > The staging areas containing the above mentioned artifacts are
>> as
>> > > >>> follows,
>> > > >>> > for your review:
>> > > >>> > * All artifacts for a,b) can be found in the corresponding dev
>> > > >>> repository
>> > > >>> > at dist.apache.org [1]
>> > > >>> > * All artifacts for c) can be found at the Apache Nexus
>> Repository
>> > > [2]
>> > > >>> >
>> > > >>> > All artifacts are signed with the
>> > > >>> > key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3]
>> > > >>> >
>> > > >>> > Other links for your review:
>> > > >>> > * JIRA release notes [4]
>> > > >>> > * source code tag "release-0.1.0-rc1" [5]
>> > > >>> > * PR to update the website Downloads page to include Kubernetes
>> > > >>> Operator
>> > > >>> > links [6]
>> > > >>> >
>> > > >>> > **Vote Duration**
>> > > >>> >
>> > > >>> > The voting time will run for at least 72 hours.
>> > > >>> > It is adopted by majority approval, with at least 3 PMC
>> affirmative
>> > > >>> votes.
>> > > >>> >
>> > > >>> > **Note for Functional Verification**
>> > > >>> > Please use the source distribution and helm chart directly from
>> [1]
>> > > to
>> > > >>> > build and deploy the operator in your testing environment.
>> > > >>> >
>> > > >>> > Thanks,
>> > > >>> > Gyula
>> > > >>> >
>> > > >>> > [1]
>> > > >>> >
>> > > >>>
>> > >
>> >
>> https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/
>> > > >>> > [2]
>> > > >>>
>> > >
>> https://repository.apache.org/content/repositories/orgapacheflink-1490/
>> > > >>> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
>> > > >>> > [4]
>> > > >>> >
>> > > >>>
>> > >
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499
>> > > >>> > [5]
>> > > >>> >
>> > > >>>
>> > >
>> >
>> https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1
>> > > >>> > [6] https://github.com/apache/flink-web/pull/519
>> > > >>> >
>> > > >>>
>> > > >>>
>> > > >>
>> > > >
>> > >
>> >
>>
>
Re: [VOTE] Apache Flink Kubernetes Operator Release 0.1.0, release candidate #1
Posted by Gyula Fóra <gy...@gmail.com>.
Thank you all for the input, let’s consider this a blocker.
As soon as we have the NOTICE fix , I will prepare the new RC.
Gyula
On Tue, 29 Mar 2022 at 06:51, Yang Wang <da...@gmail.com> wrote:
> Given that *flink-kubernetes-shaded* already contains a NOTICE file, and
> *flink-kubernetes-webhook* does not bundle any dependencies.
> IIUC, what we should do now is to add a correct NOTICE file only for the
> *flink-kubernetes-operator* module.
>
> If I do not miss anything, this would not be very difficult and I would
> like to fix it.
>
>
> Best,
> Yang
>
> Thomas Weise <th...@apache.org> 于2022年3月29日周二 11:25写道：
>
> > I believe if we as the PMC distribute a docker image (which is optional,
> > "convenience"), then that image has to follow the rules for binary
> packages
> > [1]. (And I would assume that applies regardless where we host the
> images.)
> >
> > Now to say that we only publish sources kind of side steps that problem.
> At
> > the same time it probably also defeats the purpose of the preview
> release,
> > which is to make it easier for folks that are not active contributors to
> > take the operator for a test drive.
> >
> > So I'm leaning towards publishing the images with respective NOTICE
> > requirements (for the layers that we add).
> >
> > We are also planning to publish the jar files in the future as it helps
> to
> > build clients and those would need to have the binary NOTICE also.
> >
> > Cheers,
> > Thomas
> >
> > [1] https://infra.apache.org/licensing-howto.html#binary
> >
> > On Mon, Mar 28, 2022 at 9:20 AM Gyula Fóra <gy...@apache.org> wrote:
> >
> > > I see your point and the value for having such a notice added.
> > >
> > > I think there are 2 completely distinct questions at play here:
> > >
> > > a) Is there a legal requirement for a NOTICE file for the docker image?
> > > b) If not, should we block the release on this and add it immediately?
> > >
> > > For a)
> > > I think from a legal (and ASF policy) perspective there is one question
> > > that decides whether this is a requirement for this release or not:
> > > Is the docker image part of the release?
> > >
> > > I think the answer here is clearly no, the image is not part of the
> > > release. Only the Dockerfile is part of the release.
> > >
> > > For b)
> > > I think adding the NOTICE is a good idea but it will take some work so
> I
> > > would not block the preview release on it.
> > > If someone has some handy utility or experience generating it, I don't
> > mind
> > > including it in later RCs of course.
> > > Otherwise we can aim for the next release.
> > >
> > > Gyula
> > >
> > >
> > > On Mon, Mar 28, 2022 at 6:03 PM Chesnay Schepler <ch...@apache.org>
> > > wrote:
> > >
> > > > One difference to Flink is that the distribution bundled in the
> docker
> > > > image still contains the NOTICE covering the contents of it.
> > > >
> > > > It may admittedly not be the most discoverable place, but a
> reasonable
> > > one
> > > > I think.
> > > >
> > > > Docker as a whole is very weird when it comes to licensing.
> > > > Think of all the things are are shipped in an image; I don't think we
> > can
> > > > (nor should) try to document everything in there.
> > > > For the most part this is also not necessary as the Flink images are
> > > based
> > > > on Debian,
> > > > where (al)most every installed package already embeds licensing
> > > > information into the image.
> > > >
> > > > However, for content that we copy into the image (i.e., the jars), I
> > > think
> > > > it would be reasonable to document that.
> > > > (and based on experience from the Flink side has also shown other
> > > > advantages beyond licensing...)
> > > >
> > > > On 28/03/2022 17:41, Gyula Fóra wrote:
> > > >
> > > > Thanks for the input!
> > > >
> > > > I am not an expert on this topic and have been contemplating this
> > myself
> > > > also.
> > > > We are basically trying to follow the precedent set by Flink and
> > Statefun
> > > > projects where the docker builds that we use to publish images to
> > > > dockerhub do not declare any notices.
> > > >
> > > > We will not use ghcr.io for the final release but will use dockerhub
> > > like
> > > > flink and other apache projects.
> > > >
> > > > If I look at it from a strictly technical point of view, the docker
> > image
> > > > is not part of the official release (as it's also not part of the
> > > > flink/statefun release).
> > > >
> > > > It would be good to get some input from others on this. It's not
> > > > impossible to add the notices but it's considerable work and
> > maintenance
> > > > overhead.
> > > > By extending the logic would you then also add license information
> for
> > > the
> > > > base images of the docker container (and so on so forth)?
> > > >
> > > > My gut feeling would be that we could highlight this in the NOTICE of
> > the
> > > > main project (or some other appropriate place) but we do not
> > explicitly
> > > > list the dependencies.
> > > >
> > > > Would be good to hear how others feel about this!
> > > >
> > > > Gyula
> > > >
> > > > On Mon, Mar 28, 2022 at 5:26 PM Chesnay Schepler <chesnay@apache.org
> >
> > > > wrote:
> > > >
> > > >> I don't think having users build the fat-jar & docker image absolves
> > us
> > > >> of all responsibility w.r.t. the licensing of used products.
> > > >>
> > > >> At the very least we need to inform users what licenses the fat-jar
> &
> > > >> docker image fall under such that they can make an informed decision
> > as
> > > to
> > > >> whether they can adhere to said restrictions.
> > > >> In particular since building it yourself is (apparently) a hard
> > > >> requirement for using said product.
> > > >>
> > > >> Even beyond that though, as *we* push images to ghcr.io we still
> need
> > > to
> > > >> adhere to the licensing requirements in any case afaict.
> > > >>
> > > >> On 28/03/2022 17:07, Gyula Fóra wrote:
> > > >>
> > > >> Hi Chesnay,
> > > >>
> > > >> Let me try to explain the "strange stuff"
> > > >>
> > > >> flink-kubernetes-shaded relocates some classes found in
> > flink-kubernetes
> > > >> in order to not conflict with some of the operator dependencies.
> > > >> This is necessary as flink-kubernetes packages almost everything in
> > the
> > > >> fat-jar as-is without relocation. I think this should be fine from a
> > > >> release perspective, as flink-kubernetes already contains the
> > > >> relevant notice files.
> > > >>
> > > >> For flink-kubernetes-operator we are not releasing a fat-jar as we
> > > don't
> > > >> have any client binaries etc. It is not necessary for the users
> > > therefore
> > > >> it's not part of the release.
> > > >> We release the Dockerfile instead so that users can build the image.
> > > >> Since the fatjar is not part of the release we do not have bundled
> > > >> dependencies, and we do not need extra licensing information I
> > believe.
> > > >>
> > > >> Cheers,
> > > >> Gyula
> > > >>
> > > >> On Mon, Mar 28, 2022 at 4:40 PM Chesnay Schepler <
> chesnay@apache.org>
> > > >> wrote:
> > > >>
> > > >>> There's some strange stuff in here.
> > > >>>
> > > >>> What exactly is the purpose of flink-kubernetes-shaded? You're just
> > > >>> re-packaging flink-kubernetes without making any changes.
> > > >>>
> > > >>> The uploaded flink-kubernetes-operator jar isn't bundling any
> > > >>> dependencies. Why is the fat jar not uploaded? Is it used anywhere
> > else
> > > >>> (e.g., directly embedded into a docker image)
> > > >>> If it is used, where do you have the appropriate licensing
> > information
> > > >>> for the bundled dependencies?
> > > >>>
> > > >>> On 28/03/2022 16:14, Gyula Fóra wrote:
> > > >>> > Hi everyone,
> > > >>> >
> > > >>> > Please review and vote on the release candidate #1 for the
> version
> > > >>> 0.1.0 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 the following:
> > > >>> > a) Kubernetes Operator canonical source distribution (including
> the
> > > >>> > Dockerfile), to be deployed to the release repository at
> > > >>> dist.apache.org
> > > >>> > b) Kubernetes Operator Helm Chart to be deployed to the release
> > > >>> repository
> > > >>> > at dist.apache.org
> > > >>> > c) Maven artifacts to be deployed to the Maven Central Repository
> > > >>> >
> > > >>> > **Staging Areas to Review**
> > > >>> >
> > > >>> > The staging areas containing the above mentioned artifacts are as
> > > >>> follows,
> > > >>> > for your review:
> > > >>> > * All artifacts for a,b) can be found in the corresponding dev
> > > >>> repository
> > > >>> > at dist.apache.org [1]
> > > >>> > * All artifacts for c) can be found at the Apache Nexus
> Repository
> > > [2]
> > > >>> >
> > > >>> > All artifacts are signed with the
> > > >>> > key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3]
> > > >>> >
> > > >>> > Other links for your review:
> > > >>> > * JIRA release notes [4]
> > > >>> > * source code tag "release-0.1.0-rc1" [5]
> > > >>> > * PR to update the website Downloads page to include Kubernetes
> > > >>> Operator
> > > >>> > links [6]
> > > >>> >
> > > >>> > **Vote Duration**
> > > >>> >
> > > >>> > The voting time will run for at least 72 hours.
> > > >>> > It is adopted by majority approval, with at least 3 PMC
> affirmative
> > > >>> votes.
> > > >>> >
> > > >>> > **Note for Functional Verification**
> > > >>> > Please use the source distribution and helm chart directly from
> [1]
> > > to
> > > >>> > build and deploy the operator in your testing environment.
> > > >>> >
> > > >>> > Thanks,
> > > >>> > Gyula
> > > >>> >
> > > >>> > [1]
> > > >>> >
> > > >>>
> > >
> >
> https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/
> > > >>> > [2]
> > > >>>
> > >
> https://repository.apache.org/content/repositories/orgapacheflink-1490/
> > > >>> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> > > >>> > [4]
> > > >>> >
> > > >>>
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499
> > > >>> > [5]
> > > >>> >
> > > >>>
> > >
> >
> https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1
> > > >>> > [6] https://github.com/apache/flink-web/pull/519
> > > >>> >
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> >
>
Re: [VOTE] Apache Flink Kubernetes Operator Release 0.1.0, release candidate #1
Posted by Yang Wang <da...@gmail.com>.
Given that *flink-kubernetes-shaded* already contains a NOTICE file, and
*flink-kubernetes-webhook* does not bundle any dependencies.
IIUC, what we should do now is to add a correct NOTICE file only for the
*flink-kubernetes-operator* module.
If I do not miss anything, this would not be very difficult and I would
like to fix it.
Best,
Yang
Thomas Weise <th...@apache.org> 于2022年3月29日周二 11:25写道：
> I believe if we as the PMC distribute a docker image (which is optional,
> "convenience"), then that image has to follow the rules for binary packages
> [1]. (And I would assume that applies regardless where we host the images.)
>
> Now to say that we only publish sources kind of side steps that problem. At
> the same time it probably also defeats the purpose of the preview release,
> which is to make it easier for folks that are not active contributors to
> take the operator for a test drive.
>
> So I'm leaning towards publishing the images with respective NOTICE
> requirements (for the layers that we add).
>
> We are also planning to publish the jar files in the future as it helps to
> build clients and those would need to have the binary NOTICE also.
>
> Cheers,
> Thomas
>
> [1] https://infra.apache.org/licensing-howto.html#binary
>
> On Mon, Mar 28, 2022 at 9:20 AM Gyula Fóra <gy...@apache.org> wrote:
>
> > I see your point and the value for having such a notice added.
> >
> > I think there are 2 completely distinct questions at play here:
> >
> > a) Is there a legal requirement for a NOTICE file for the docker image?
> > b) If not, should we block the release on this and add it immediately?
> >
> > For a)
> > I think from a legal (and ASF policy) perspective there is one question
> > that decides whether this is a requirement for this release or not:
> > Is the docker image part of the release?
> >
> > I think the answer here is clearly no, the image is not part of the
> > release. Only the Dockerfile is part of the release.
> >
> > For b)
> > I think adding the NOTICE is a good idea but it will take some work so I
> > would not block the preview release on it.
> > If someone has some handy utility or experience generating it, I don't
> mind
> > including it in later RCs of course.
> > Otherwise we can aim for the next release.
> >
> > Gyula
> >
> >
> > On Mon, Mar 28, 2022 at 6:03 PM Chesnay Schepler <ch...@apache.org>
> > wrote:
> >
> > > One difference to Flink is that the distribution bundled in the docker
> > > image still contains the NOTICE covering the contents of it.
> > >
> > > It may admittedly not be the most discoverable place, but a reasonable
> > one
> > > I think.
> > >
> > > Docker as a whole is very weird when it comes to licensing.
> > > Think of all the things are are shipped in an image; I don't think we
> can
> > > (nor should) try to document everything in there.
> > > For the most part this is also not necessary as the Flink images are
> > based
> > > on Debian,
> > > where (al)most every installed package already embeds licensing
> > > information into the image.
> > >
> > > However, for content that we copy into the image (i.e., the jars), I
> > think
> > > it would be reasonable to document that.
> > > (and based on experience from the Flink side has also shown other
> > > advantages beyond licensing...)
> > >
> > > On 28/03/2022 17:41, Gyula Fóra wrote:
> > >
> > > Thanks for the input!
> > >
> > > I am not an expert on this topic and have been contemplating this
> myself
> > > also.
> > > We are basically trying to follow the precedent set by Flink and
> Statefun
> > > projects where the docker builds that we use to publish images to
> > > dockerhub do not declare any notices.
> > >
> > > We will not use ghcr.io for the final release but will use dockerhub
> > like
> > > flink and other apache projects.
> > >
> > > If I look at it from a strictly technical point of view, the docker
> image
> > > is not part of the official release (as it's also not part of the
> > > flink/statefun release).
> > >
> > > It would be good to get some input from others on this. It's not
> > > impossible to add the notices but it's considerable work and
> maintenance
> > > overhead.
> > > By extending the logic would you then also add license information for
> > the
> > > base images of the docker container (and so on so forth)?
> > >
> > > My gut feeling would be that we could highlight this in the NOTICE of
> the
> > > main project (or some other appropriate place) but we do not
> explicitly
> > > list the dependencies.
> > >
> > > Would be good to hear how others feel about this!
> > >
> > > Gyula
> > >
> > > On Mon, Mar 28, 2022 at 5:26 PM Chesnay Schepler <ch...@apache.org>
> > > wrote:
> > >
> > >> I don't think having users build the fat-jar & docker image absolves
> us
> > >> of all responsibility w.r.t. the licensing of used products.
> > >>
> > >> At the very least we need to inform users what licenses the fat-jar &
> > >> docker image fall under such that they can make an informed decision
> as
> > to
> > >> whether they can adhere to said restrictions.
> > >> In particular since building it yourself is (apparently) a hard
> > >> requirement for using said product.
> > >>
> > >> Even beyond that though, as *we* push images to ghcr.io we still need
> > to
> > >> adhere to the licensing requirements in any case afaict.
> > >>
> > >> On 28/03/2022 17:07, Gyula Fóra wrote:
> > >>
> > >> Hi Chesnay,
> > >>
> > >> Let me try to explain the "strange stuff"
> > >>
> > >> flink-kubernetes-shaded relocates some classes found in
> flink-kubernetes
> > >> in order to not conflict with some of the operator dependencies.
> > >> This is necessary as flink-kubernetes packages almost everything in
> the
> > >> fat-jar as-is without relocation. I think this should be fine from a
> > >> release perspective, as flink-kubernetes already contains the
> > >> relevant notice files.
> > >>
> > >> For flink-kubernetes-operator we are not releasing a fat-jar as we
> > don't
> > >> have any client binaries etc. It is not necessary for the users
> > therefore
> > >> it's not part of the release.
> > >> We release the Dockerfile instead so that users can build the image.
> > >> Since the fatjar is not part of the release we do not have bundled
> > >> dependencies, and we do not need extra licensing information I
> believe.
> > >>
> > >> Cheers,
> > >> Gyula
> > >>
> > >> On Mon, Mar 28, 2022 at 4:40 PM Chesnay Schepler <ch...@apache.org>
> > >> wrote:
> > >>
> > >>> There's some strange stuff in here.
> > >>>
> > >>> What exactly is the purpose of flink-kubernetes-shaded? You're just
> > >>> re-packaging flink-kubernetes without making any changes.
> > >>>
> > >>> The uploaded flink-kubernetes-operator jar isn't bundling any
> > >>> dependencies. Why is the fat jar not uploaded? Is it used anywhere
> else
> > >>> (e.g., directly embedded into a docker image)
> > >>> If it is used, where do you have the appropriate licensing
> information
> > >>> for the bundled dependencies?
> > >>>
> > >>> On 28/03/2022 16:14, Gyula Fóra wrote:
> > >>> > Hi everyone,
> > >>> >
> > >>> > Please review and vote on the release candidate #1 for the version
> > >>> 0.1.0 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 the following:
> > >>> > a) Kubernetes Operator canonical source distribution (including the
> > >>> > Dockerfile), to be deployed to the release repository at
> > >>> dist.apache.org
> > >>> > b) Kubernetes Operator Helm Chart to be deployed to the release
> > >>> repository
> > >>> > at dist.apache.org
> > >>> > c) Maven artifacts to be deployed to the Maven Central Repository
> > >>> >
> > >>> > **Staging Areas to Review**
> > >>> >
> > >>> > The staging areas containing the above mentioned artifacts are as
> > >>> follows,
> > >>> > for your review:
> > >>> > * All artifacts for a,b) can be found in the corresponding dev
> > >>> repository
> > >>> > at dist.apache.org [1]
> > >>> > * All artifacts for c) can be found at the Apache Nexus Repository
> > [2]
> > >>> >
> > >>> > All artifacts are signed with the
> > >>> > key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3]
> > >>> >
> > >>> > Other links for your review:
> > >>> > * JIRA release notes [4]
> > >>> > * source code tag "release-0.1.0-rc1" [5]
> > >>> > * PR to update the website Downloads page to include Kubernetes
> > >>> Operator
> > >>> > links [6]
> > >>> >
> > >>> > **Vote Duration**
> > >>> >
> > >>> > The voting time will run for at least 72 hours.
> > >>> > It is adopted by majority approval, with at least 3 PMC affirmative
> > >>> votes.
> > >>> >
> > >>> > **Note for Functional Verification**
> > >>> > Please use the source distribution and helm chart directly from [1]
> > to
> > >>> > build and deploy the operator in your testing environment.
> > >>> >
> > >>> > Thanks,
> > >>> > Gyula
> > >>> >
> > >>> > [1]
> > >>> >
> > >>>
> >
> https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/
> > >>> > [2]
> > >>>
> > https://repository.apache.org/content/repositories/orgapacheflink-1490/
> > >>> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> > >>> > [4]
> > >>> >
> > >>>
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499
> > >>> > [5]
> > >>> >
> > >>>
> >
> https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1
> > >>> > [6] https://github.com/apache/flink-web/pull/519
> > >>> >
> > >>>
> > >>>
> > >>
> > >
> >
>
Re: [VOTE] Apache Flink Kubernetes Operator Release 0.1.0, release candidate #1
Posted by Thomas Weise <th...@apache.org>.
I believe if we as the PMC distribute a docker image (which is optional,
"convenience"), then that image has to follow the rules for binary packages
[1]. (And I would assume that applies regardless where we host the images.)
Now to say that we only publish sources kind of side steps that problem. At
the same time it probably also defeats the purpose of the preview release,
which is to make it easier for folks that are not active contributors to
take the operator for a test drive.
So I'm leaning towards publishing the images with respective NOTICE
requirements (for the layers that we add).
We are also planning to publish the jar files in the future as it helps to
build clients and those would need to have the binary NOTICE also.
Cheers,
Thomas
[1] https://infra.apache.org/licensing-howto.html#binary
On Mon, Mar 28, 2022 at 9:20 AM Gyula Fóra <gy...@apache.org> wrote:
> I see your point and the value for having such a notice added.
>
> I think there are 2 completely distinct questions at play here:
>
> a) Is there a legal requirement for a NOTICE file for the docker image?
> b) If not, should we block the release on this and add it immediately?
>
> For a)
> I think from a legal (and ASF policy) perspective there is one question
> that decides whether this is a requirement for this release or not:
> Is the docker image part of the release?
>
> I think the answer here is clearly no, the image is not part of the
> release. Only the Dockerfile is part of the release.
>
> For b)
> I think adding the NOTICE is a good idea but it will take some work so I
> would not block the preview release on it.
> If someone has some handy utility or experience generating it, I don't mind
> including it in later RCs of course.
> Otherwise we can aim for the next release.
>
> Gyula
>
>
> On Mon, Mar 28, 2022 at 6:03 PM Chesnay Schepler <ch...@apache.org>
> wrote:
>
> > One difference to Flink is that the distribution bundled in the docker
> > image still contains the NOTICE covering the contents of it.
> >
> > It may admittedly not be the most discoverable place, but a reasonable
> one
> > I think.
> >
> > Docker as a whole is very weird when it comes to licensing.
> > Think of all the things are are shipped in an image; I don't think we can
> > (nor should) try to document everything in there.
> > For the most part this is also not necessary as the Flink images are
> based
> > on Debian,
> > where (al)most every installed package already embeds licensing
> > information into the image.
> >
> > However, for content that we copy into the image (i.e., the jars), I
> think
> > it would be reasonable to document that.
> > (and based on experience from the Flink side has also shown other
> > advantages beyond licensing...)
> >
> > On 28/03/2022 17:41, Gyula Fóra wrote:
> >
> > Thanks for the input!
> >
> > I am not an expert on this topic and have been contemplating this myself
> > also.
> > We are basically trying to follow the precedent set by Flink and Statefun
> > projects where the docker builds that we use to publish images to
> > dockerhub do not declare any notices.
> >
> > We will not use ghcr.io for the final release but will use dockerhub
> like
> > flink and other apache projects.
> >
> > If I look at it from a strictly technical point of view, the docker image
> > is not part of the official release (as it's also not part of the
> > flink/statefun release).
> >
> > It would be good to get some input from others on this. It's not
> > impossible to add the notices but it's considerable work and maintenance
> > overhead.
> > By extending the logic would you then also add license information for
> the
> > base images of the docker container (and so on so forth)?
> >
> > My gut feeling would be that we could highlight this in the NOTICE of the
> > main project (or some other appropriate place) but we do not explicitly
> > list the dependencies.
> >
> > Would be good to hear how others feel about this!
> >
> > Gyula
> >
> > On Mon, Mar 28, 2022 at 5:26 PM Chesnay Schepler <ch...@apache.org>
> > wrote:
> >
> >> I don't think having users build the fat-jar & docker image absolves us
> >> of all responsibility w.r.t. the licensing of used products.
> >>
> >> At the very least we need to inform users what licenses the fat-jar &
> >> docker image fall under such that they can make an informed decision as
> to
> >> whether they can adhere to said restrictions.
> >> In particular since building it yourself is (apparently) a hard
> >> requirement for using said product.
> >>
> >> Even beyond that though, as *we* push images to ghcr.io we still need
> to
> >> adhere to the licensing requirements in any case afaict.
> >>
> >> On 28/03/2022 17:07, Gyula Fóra wrote:
> >>
> >> Hi Chesnay,
> >>
> >> Let me try to explain the "strange stuff"
> >>
> >> flink-kubernetes-shaded relocates some classes found in flink-kubernetes
> >> in order to not conflict with some of the operator dependencies.
> >> This is necessary as flink-kubernetes packages almost everything in the
> >> fat-jar as-is without relocation. I think this should be fine from a
> >> release perspective, as flink-kubernetes already contains the
> >> relevant notice files.
> >>
> >> For flink-kubernetes-operator we are not releasing a fat-jar as we
> don't
> >> have any client binaries etc. It is not necessary for the users
> therefore
> >> it's not part of the release.
> >> We release the Dockerfile instead so that users can build the image.
> >> Since the fatjar is not part of the release we do not have bundled
> >> dependencies, and we do not need extra licensing information I believe.
> >>
> >> Cheers,
> >> Gyula
> >>
> >> On Mon, Mar 28, 2022 at 4:40 PM Chesnay Schepler <ch...@apache.org>
> >> wrote:
> >>
> >>> There's some strange stuff in here.
> >>>
> >>> What exactly is the purpose of flink-kubernetes-shaded? You're just
> >>> re-packaging flink-kubernetes without making any changes.
> >>>
> >>> The uploaded flink-kubernetes-operator jar isn't bundling any
> >>> dependencies. Why is the fat jar not uploaded? Is it used anywhere else
> >>> (e.g., directly embedded into a docker image)
> >>> If it is used, where do you have the appropriate licensing information
> >>> for the bundled dependencies?
> >>>
> >>> On 28/03/2022 16:14, Gyula Fóra wrote:
> >>> > Hi everyone,
> >>> >
> >>> > Please review and vote on the release candidate #1 for the version
> >>> 0.1.0 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 the following:
> >>> > a) Kubernetes Operator canonical source distribution (including the
> >>> > Dockerfile), to be deployed to the release repository at
> >>> dist.apache.org
> >>> > b) Kubernetes Operator Helm Chart to be deployed to the release
> >>> repository
> >>> > at dist.apache.org
> >>> > c) Maven artifacts to be deployed to the Maven Central Repository
> >>> >
> >>> > **Staging Areas to Review**
> >>> >
> >>> > The staging areas containing the above mentioned artifacts are as
> >>> follows,
> >>> > for your review:
> >>> > * All artifacts for a,b) can be found in the corresponding dev
> >>> repository
> >>> > at dist.apache.org [1]
> >>> > * All artifacts for c) can be found at the Apache Nexus Repository
> [2]
> >>> >
> >>> > All artifacts are signed with the
> >>> > key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3]
> >>> >
> >>> > Other links for your review:
> >>> > * JIRA release notes [4]
> >>> > * source code tag "release-0.1.0-rc1" [5]
> >>> > * PR to update the website Downloads page to include Kubernetes
> >>> Operator
> >>> > links [6]
> >>> >
> >>> > **Vote Duration**
> >>> >
> >>> > The voting time will run for at least 72 hours.
> >>> > It is adopted by majority approval, with at least 3 PMC affirmative
> >>> votes.
> >>> >
> >>> > **Note for Functional Verification**
> >>> > Please use the source distribution and helm chart directly from [1]
> to
> >>> > build and deploy the operator in your testing environment.
> >>> >
> >>> > Thanks,
> >>> > Gyula
> >>> >
> >>> > [1]
> >>> >
> >>>
> https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/
> >>> > [2]
> >>>
> https://repository.apache.org/content/repositories/orgapacheflink-1490/
> >>> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> >>> > [4]
> >>> >
> >>>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499
> >>> > [5]
> >>> >
> >>>
> https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1
> >>> > [6] https://github.com/apache/flink-web/pull/519
> >>> >
> >>>
> >>>
> >>
> >
>
Re: [VOTE] Apache Flink Kubernetes Operator Release 0.1.0, release candidate #1
Posted by Gyula Fóra <gy...@apache.org>.
I see your point and the value for having such a notice added.
I think there are 2 completely distinct questions at play here:
a) Is there a legal requirement for a NOTICE file for the docker image?
b) If not, should we block the release on this and add it immediately?
For a)
I think from a legal (and ASF policy) perspective there is one question
that decides whether this is a requirement for this release or not:
Is the docker image part of the release?
I think the answer here is clearly no, the image is not part of the
release. Only the Dockerfile is part of the release.
For b)
I think adding the NOTICE is a good idea but it will take some work so I
would not block the preview release on it.
If someone has some handy utility or experience generating it, I don't mind
including it in later RCs of course.
Otherwise we can aim for the next release.
Gyula
On Mon, Mar 28, 2022 at 6:03 PM Chesnay Schepler <ch...@apache.org> wrote:
> One difference to Flink is that the distribution bundled in the docker
> image still contains the NOTICE covering the contents of it.
>
> It may admittedly not be the most discoverable place, but a reasonable one
> I think.
>
> Docker as a whole is very weird when it comes to licensing.
> Think of all the things are are shipped in an image; I don't think we can
> (nor should) try to document everything in there.
> For the most part this is also not necessary as the Flink images are based
> on Debian,
> where (al)most every installed package already embeds licensing
> information into the image.
>
> However, for content that we copy into the image (i.e., the jars), I think
> it would be reasonable to document that.
> (and based on experience from the Flink side has also shown other
> advantages beyond licensing...)
>
> On 28/03/2022 17:41, Gyula Fóra wrote:
>
> Thanks for the input!
>
> I am not an expert on this topic and have been contemplating this myself
> also.
> We are basically trying to follow the precedent set by Flink and Statefun
> projects where the docker builds that we use to publish images to
> dockerhub do not declare any notices.
>
> We will not use ghcr.io for the final release but will use dockerhub like
> flink and other apache projects.
>
> If I look at it from a strictly technical point of view, the docker image
> is not part of the official release (as it's also not part of the
> flink/statefun release).
>
> It would be good to get some input from others on this. It's not
> impossible to add the notices but it's considerable work and maintenance
> overhead.
> By extending the logic would you then also add license information for the
> base images of the docker container (and so on so forth)?
>
> My gut feeling would be that we could highlight this in the NOTICE of the
> main project (or some other appropriate place) but we do not explicitly
> list the dependencies.
>
> Would be good to hear how others feel about this!
>
> Gyula
>
> On Mon, Mar 28, 2022 at 5:26 PM Chesnay Schepler <ch...@apache.org>
> wrote:
>
>> I don't think having users build the fat-jar & docker image absolves us
>> of all responsibility w.r.t. the licensing of used products.
>>
>> At the very least we need to inform users what licenses the fat-jar &
>> docker image fall under such that they can make an informed decision as to
>> whether they can adhere to said restrictions.
>> In particular since building it yourself is (apparently) a hard
>> requirement for using said product.
>>
>> Even beyond that though, as *we* push images to ghcr.io we still need to
>> adhere to the licensing requirements in any case afaict.
>>
>> On 28/03/2022 17:07, Gyula Fóra wrote:
>>
>> Hi Chesnay,
>>
>> Let me try to explain the "strange stuff"
>>
>> flink-kubernetes-shaded relocates some classes found in flink-kubernetes
>> in order to not conflict with some of the operator dependencies.
>> This is necessary as flink-kubernetes packages almost everything in the
>> fat-jar as-is without relocation. I think this should be fine from a
>> release perspective, as flink-kubernetes already contains the
>> relevant notice files.
>>
>> For flink-kubernetes-operator we are not releasing a fat-jar as we don't
>> have any client binaries etc. It is not necessary for the users therefore
>> it's not part of the release.
>> We release the Dockerfile instead so that users can build the image.
>> Since the fatjar is not part of the release we do not have bundled
>> dependencies, and we do not need extra licensing information I believe.
>>
>> Cheers,
>> Gyula
>>
>> On Mon, Mar 28, 2022 at 4:40 PM Chesnay Schepler <ch...@apache.org>
>> wrote:
>>
>>> There's some strange stuff in here.
>>>
>>> What exactly is the purpose of flink-kubernetes-shaded? You're just
>>> re-packaging flink-kubernetes without making any changes.
>>>
>>> The uploaded flink-kubernetes-operator jar isn't bundling any
>>> dependencies. Why is the fat jar not uploaded? Is it used anywhere else
>>> (e.g., directly embedded into a docker image)
>>> If it is used, where do you have the appropriate licensing information
>>> for the bundled dependencies?
>>>
>>> On 28/03/2022 16:14, Gyula Fóra wrote:
>>> > Hi everyone,
>>> >
>>> > Please review and vote on the release candidate #1 for the version
>>> 0.1.0 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 the following:
>>> > a) Kubernetes Operator canonical source distribution (including the
>>> > Dockerfile), to be deployed to the release repository at
>>> dist.apache.org
>>> > b) Kubernetes Operator Helm Chart to be deployed to the release
>>> repository
>>> > at dist.apache.org
>>> > c) Maven artifacts to be deployed to the Maven Central Repository
>>> >
>>> > **Staging Areas to Review**
>>> >
>>> > The staging areas containing the above mentioned artifacts are as
>>> follows,
>>> > for your review:
>>> > * All artifacts for a,b) can be found in the corresponding dev
>>> repository
>>> > at dist.apache.org [1]
>>> > * All artifacts for c) can be found at the Apache Nexus Repository [2]
>>> >
>>> > All artifacts are signed with the
>>> > key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3]
>>> >
>>> > Other links for your review:
>>> > * JIRA release notes [4]
>>> > * source code tag "release-0.1.0-rc1" [5]
>>> > * PR to update the website Downloads page to include Kubernetes
>>> Operator
>>> > links [6]
>>> >
>>> > **Vote Duration**
>>> >
>>> > The voting time will run for at least 72 hours.
>>> > It is adopted by majority approval, with at least 3 PMC affirmative
>>> votes.
>>> >
>>> > **Note for Functional Verification**
>>> > Please use the source distribution and helm chart directly from [1] to
>>> > build and deploy the operator in your testing environment.
>>> >
>>> > Thanks,
>>> > Gyula
>>> >
>>> > [1]
>>> >
>>> https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/
>>> > [2]
>>> https://repository.apache.org/content/repositories/orgapacheflink-1490/
>>> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
>>> > [4]
>>> >
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499
>>> > [5]
>>> >
>>> https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1
>>> > [6] https://github.com/apache/flink-web/pull/519
>>> >
>>>
>>>
>>
>
Re: [VOTE] Apache Flink Kubernetes Operator Release 0.1.0, release candidate #1
Posted by Chesnay Schepler <ch...@apache.org>.
One difference to Flink is that the distribution bundled in the docker
image still contains the NOTICE covering the contents of it.
It may admittedly not be the most discoverable place, but a reasonable
one I think.
Docker as a whole is very weird when it comes to licensing.
Think of all the things are are shipped in an image; I don't think we
can (nor should) try to document everything in there.
For the most part this is also not necessary as the Flink images are
based on Debian,
where (al)most every installed package already embeds licensing
information into the image.
However, for content that we copy into the image (i.e., the jars), I
think it would be reasonable to document that.
(and based on experience from the Flink side has also shown other
advantages beyond licensing...)
On 28/03/2022 17:41, Gyula Fóra wrote:
> Thanks for the input!
>
> I am not an expert on this topic and have been contemplating this
> myself also.
> We are basically trying to follow the precedent set by Flink and
> Statefun projects where the docker builds that we use to publish
> images to dockerhub do not declare any notices.
>
> We will not use ghcr.io <http://ghcr.io> for the final release but
> will use dockerhub like flink and other apache projects.
>
> If I look at it from a strictly technical point of view, the docker
> image is not part of the official release (as it's also not part of
> the flink/statefun release).
>
> It would be good to get some input from others on this. It's not
> impossible to add the notices but it's considerable work and
> maintenance overhead.
> By extending the logic would you then also add license information for
> the base images of the docker container (and so on so forth)?
>
> My gut feeling would be that we could highlight this in the NOTICE of
> the main project (or some other appropriate place) but we do not
> explicitly list the dependencies.
>
> Would be good to hear how others feel about this!
>
> Gyula
>
> On Mon, Mar 28, 2022 at 5:26 PM Chesnay Schepler <ch...@apache.org>
> wrote:
>
> I don't think having users build the fat-jar & docker image
> absolves us of all responsibility w.r.t. the licensing of used
> products.
>
> At the very least we need to inform users what licenses the
> fat-jar & docker image fall under such that they can make an
> informed decision as to whether they can adhere to said restrictions.
> In particular since building it yourself is (apparently) a hard
> requirement for using said product.
>
> Even beyond that though, as /we/ push images to ghcr.io
> <http://ghcr.io> we still need to adhere to the licensing
> requirements in any case afaict.
>
> On 28/03/2022 17:07, Gyula Fóra wrote:
>> Hi Chesnay,
>>
>> Let me try to explain the "strange stuff"
>>
>> flink-kubernetes-shaded relocates some classes found in
>> flink-kubernetes in order to not conflict with some of the
>> operator dependencies.
>> This is necessary as flink-kubernetes packages almost everything
>> in the fat-jar as-is without relocation. I think this should be
>> fine from a release perspective, as flink-kubernetes already
>> contains the relevant notice files.
>>
>> For flink-kubernetes-operator we are not releasing a fat-jar as
>> we don't have any client binaries etc. It is not necessary for
>> the users therefore it's not part of the release.
>> We release the Dockerfile instead so that users can build the
>> image. Since the fatjar is not part of the release we do not have
>> bundled dependencies, and we do not need extra licensing
>> information I believe.
>>
>> Cheers,
>> Gyula
>>
>> On Mon, Mar 28, 2022 at 4:40 PM Chesnay Schepler
>> <ch...@apache.org> wrote:
>>
>> There's some strange stuff in here.
>>
>> What exactly is the purpose of flink-kubernetes-shaded?
>> You're just
>> re-packaging flink-kubernetes without making any changes.
>>
>> The uploaded flink-kubernetes-operator jar isn't bundling any
>> dependencies. Why is the fat jar not uploaded? Is it used
>> anywhere else
>> (e.g., directly embedded into a docker image)
>> If it is used, where do you have the appropriate licensing
>> information
>> for the bundled dependencies?
>>
>> On 28/03/2022 16:14, Gyula Fóra wrote:
>> > Hi everyone,
>> >
>> > Please review and vote on the release candidate #1 for the
>> version 0.1.0 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 the following:
>> > a) Kubernetes Operator canonical source distribution
>> (including the
>> > Dockerfile), to be deployed to the release repository at
>> dist.apache.org <http://dist.apache.org>
>> > b) Kubernetes Operator Helm Chart to be deployed to the
>> release repository
>> > at dist.apache.org <http://dist.apache.org>
>> > c) Maven artifacts to be deployed to the Maven Central
>> Repository
>> >
>> > **Staging Areas to Review**
>> >
>> > The staging areas containing the above mentioned artifacts
>> are as follows,
>> > for your review:
>> > * All artifacts for a,b) can be found in the corresponding
>> dev repository
>> > at dist.apache.org <http://dist.apache.org> [1]
>> > * All artifacts for c) can be found at the Apache Nexus
>> Repository [2]
>> >
>> > All artifacts are signed with the
>> > key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3]
>> >
>> > Other links for your review:
>> > * JIRA release notes [4]
>> > * source code tag "release-0.1.0-rc1" [5]
>> > * PR to update the website Downloads page to include
>> Kubernetes Operator
>> > links [6]
>> >
>> > **Vote Duration**
>> >
>> > The voting time will run for at least 72 hours.
>> > It is adopted by majority approval, with at least 3 PMC
>> affirmative votes.
>> >
>> > **Note for Functional Verification**
>> > Please use the source distribution and helm chart directly
>> from [1] to
>> > build and deploy the operator in your testing environment.
>> >
>> > Thanks,
>> > Gyula
>> >
>> > [1]
>> >
>> https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/
>> > [2]
>> https://repository.apache.org/content/repositories/orgapacheflink-1490/
>> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
>> > [4]
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499
>> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499>
>> > [5]
>> >
>> https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1
>> > [6] https://github.com/apache/flink-web/pull/519
>> >
>>
>
Re: [VOTE] Apache Flink Kubernetes Operator Release 0.1.0, release candidate #1
Posted by Gyula Fóra <gy...@apache.org>.
Thanks for the input!
I am not an expert on this topic and have been contemplating this myself
also.
We are basically trying to follow the precedent set by Flink and Statefun
projects where the docker builds that we use to publish images to
dockerhub do not declare any notices.
We will not use ghcr.io for the final release but will use dockerhub like
flink and other apache projects.
If I look at it from a strictly technical point of view, the docker image
is not part of the official release (as it's also not part of the
flink/statefun release).
It would be good to get some input from others on this. It's not impossible
to add the notices but it's considerable work and maintenance overhead.
By extending the logic would you then also add license information for the
base images of the docker container (and so on so forth)?
My gut feeling would be that we could highlight this in the NOTICE of the
main project (or some other appropriate place) but we do not explicitly
list the dependencies.
Would be good to hear how others feel about this!
Gyula
On Mon, Mar 28, 2022 at 5:26 PM Chesnay Schepler <ch...@apache.org> wrote:
> I don't think having users build the fat-jar & docker image absolves us of
> all responsibility w.r.t. the licensing of used products.
>
> At the very least we need to inform users what licenses the fat-jar &
> docker image fall under such that they can make an informed decision as to
> whether they can adhere to said restrictions.
> In particular since building it yourself is (apparently) a hard
> requirement for using said product.
>
> Even beyond that though, as *we* push images to ghcr.io we still need to
> adhere to the licensing requirements in any case afaict.
>
> On 28/03/2022 17:07, Gyula Fóra wrote:
>
> Hi Chesnay,
>
> Let me try to explain the "strange stuff"
>
> flink-kubernetes-shaded relocates some classes found in flink-kubernetes
> in order to not conflict with some of the operator dependencies.
> This is necessary as flink-kubernetes packages almost everything in the
> fat-jar as-is without relocation. I think this should be fine from a
> release perspective, as flink-kubernetes already contains the
> relevant notice files.
>
> For flink-kubernetes-operator we are not releasing a fat-jar as we don't
> have any client binaries etc. It is not necessary for the users therefore
> it's not part of the release.
> We release the Dockerfile instead so that users can build the image. Since
> the fatjar is not part of the release we do not have bundled dependencies,
> and we do not need extra licensing information I believe.
>
> Cheers,
> Gyula
>
> On Mon, Mar 28, 2022 at 4:40 PM Chesnay Schepler <ch...@apache.org>
> wrote:
>
>> There's some strange stuff in here.
>>
>> What exactly is the purpose of flink-kubernetes-shaded? You're just
>> re-packaging flink-kubernetes without making any changes.
>>
>> The uploaded flink-kubernetes-operator jar isn't bundling any
>> dependencies. Why is the fat jar not uploaded? Is it used anywhere else
>> (e.g., directly embedded into a docker image)
>> If it is used, where do you have the appropriate licensing information
>> for the bundled dependencies?
>>
>> On 28/03/2022 16:14, Gyula Fóra wrote:
>> > Hi everyone,
>> >
>> > Please review and vote on the release candidate #1 for the version
>> 0.1.0 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 the following:
>> > a) Kubernetes Operator canonical source distribution (including the
>> > Dockerfile), to be deployed to the release repository at
>> dist.apache.org
>> > b) Kubernetes Operator Helm Chart to be deployed to the release
>> repository
>> > at dist.apache.org
>> > c) Maven artifacts to be deployed to the Maven Central Repository
>> >
>> > **Staging Areas to Review**
>> >
>> > The staging areas containing the above mentioned artifacts are as
>> follows,
>> > for your review:
>> > * All artifacts for a,b) can be found in the corresponding dev
>> repository
>> > at dist.apache.org [1]
>> > * All artifacts for c) can be found at the Apache Nexus Repository [2]
>> >
>> > All artifacts are signed with the
>> > key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3]
>> >
>> > Other links for your review:
>> > * JIRA release notes [4]
>> > * source code tag "release-0.1.0-rc1" [5]
>> > * PR to update the website Downloads page to include Kubernetes Operator
>> > links [6]
>> >
>> > **Vote Duration**
>> >
>> > The voting time will run for at least 72 hours.
>> > It is adopted by majority approval, with at least 3 PMC affirmative
>> votes.
>> >
>> > **Note for Functional Verification**
>> > Please use the source distribution and helm chart directly from [1] to
>> > build and deploy the operator in your testing environment.
>> >
>> > Thanks,
>> > Gyula
>> >
>> > [1]
>> >
>> https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/
>> > [2]
>> https://repository.apache.org/content/repositories/orgapacheflink-1490/
>> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
>> > [4]
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499
>> > [5]
>> >
>> https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1
>> > [6] https://github.com/apache/flink-web/pull/519
>> >
>>
>>
>
Re: [VOTE] Apache Flink Kubernetes Operator Release 0.1.0, release candidate #1
Posted by Chesnay Schepler <ch...@apache.org>.
I don't think having users build the fat-jar & docker image absolves us
of all responsibility w.r.t. the licensing of used products.
At the very least we need to inform users what licenses the fat-jar &
docker image fall under such that they can make an informed decision as
to whether they can adhere to said restrictions.
In particular since building it yourself is (apparently) a hard
requirement for using said product.
Even beyond that though, as /we/ push images to ghcr.io we still need to
adhere to the licensing requirements in any case afaict.
On 28/03/2022 17:07, Gyula Fóra wrote:
> Hi Chesnay,
>
> Let me try to explain the "strange stuff"
>
> flink-kubernetes-shaded relocates some classes found in
> flink-kubernetes in order to not conflict with some of the operator
> dependencies.
> This is necessary as flink-kubernetes packages almost everything in
> the fat-jar as-is without relocation. I think this should be fine from
> a release perspective, as flink-kubernetes already contains the
> relevant notice files.
>
> For flink-kubernetes-operator we are not releasing a fat-jar as we
> don't have any client binaries etc. It is not necessary for the users
> therefore it's not part of the release.
> We release the Dockerfile instead so that users can build the image.
> Since the fatjar is not part of the release we do not have bundled
> dependencies, and we do not need extra licensing information I believe.
>
> Cheers,
> Gyula
>
> On Mon, Mar 28, 2022 at 4:40 PM Chesnay Schepler <ch...@apache.org>
> wrote:
>
> There's some strange stuff in here.
>
> What exactly is the purpose of flink-kubernetes-shaded? You're just
> re-packaging flink-kubernetes without making any changes.
>
> The uploaded flink-kubernetes-operator jar isn't bundling any
> dependencies. Why is the fat jar not uploaded? Is it used anywhere
> else
> (e.g., directly embedded into a docker image)
> If it is used, where do you have the appropriate licensing
> information
> for the bundled dependencies?
>
> On 28/03/2022 16:14, Gyula Fóra wrote:
> > Hi everyone,
> >
> > Please review and vote on the release candidate #1 for the
> version 0.1.0 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 the following:
> > a) Kubernetes Operator canonical source distribution (including the
> > Dockerfile), to be deployed to the release repository at
> dist.apache.org <http://dist.apache.org>
> > b) Kubernetes Operator Helm Chart to be deployed to the release
> repository
> > at dist.apache.org <http://dist.apache.org>
> > c) Maven artifacts to be deployed to the Maven Central Repository
> >
> > **Staging Areas to Review**
> >
> > The staging areas containing the above mentioned artifacts are
> as follows,
> > for your review:
> > * All artifacts for a,b) can be found in the corresponding dev
> repository
> > at dist.apache.org <http://dist.apache.org> [1]
> > * All artifacts for c) can be found at the Apache Nexus
> Repository [2]
> >
> > All artifacts are signed with the
> > key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3]
> >
> > Other links for your review:
> > * JIRA release notes [4]
> > * source code tag "release-0.1.0-rc1" [5]
> > * PR to update the website Downloads page to include Kubernetes
> Operator
> > links [6]
> >
> > **Vote Duration**
> >
> > The voting time will run for at least 72 hours.
> > It is adopted by majority approval, with at least 3 PMC
> affirmative votes.
> >
> > **Note for Functional Verification**
> > Please use the source distribution and helm chart directly from
> [1] to
> > build and deploy the operator in your testing environment.
> >
> > Thanks,
> > Gyula
> >
> > [1]
> >
> https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/
> > [2]
> https://repository.apache.org/content/repositories/orgapacheflink-1490/
> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> > [4]
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499>
> > [5]
> >
> https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1
> > [6] https://github.com/apache/flink-web/pull/519
> >
>
Re: [VOTE] Apache Flink Kubernetes Operator Release 0.1.0, release candidate #1
Posted by Gyula Fóra <gy...@apache.org>.
Hi Chesnay,
Let me try to explain the "strange stuff"
flink-kubernetes-shaded relocates some classes found in flink-kubernetes in
order to not conflict with some of the operator dependencies.
This is necessary as flink-kubernetes packages almost everything in the
fat-jar as-is without relocation. I think this should be fine from a
release perspective, as flink-kubernetes already contains the
relevant notice files.
For flink-kubernetes-operator we are not releasing a fat-jar as we don't
have any client binaries etc. It is not necessary for the users therefore
it's not part of the release.
We release the Dockerfile instead so that users can build the image. Since
the fatjar is not part of the release we do not have bundled dependencies,
and we do not need extra licensing information I believe.
Cheers,
Gyula
On Mon, Mar 28, 2022 at 4:40 PM Chesnay Schepler <ch...@apache.org> wrote:
> There's some strange stuff in here.
>
> What exactly is the purpose of flink-kubernetes-shaded? You're just
> re-packaging flink-kubernetes without making any changes.
>
> The uploaded flink-kubernetes-operator jar isn't bundling any
> dependencies. Why is the fat jar not uploaded? Is it used anywhere else
> (e.g., directly embedded into a docker image)
> If it is used, where do you have the appropriate licensing information
> for the bundled dependencies?
>
> On 28/03/2022 16:14, Gyula Fóra wrote:
> > Hi everyone,
> >
> > Please review and vote on the release candidate #1 for the version 0.1.0
> 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 the following:
> > a) Kubernetes Operator canonical source distribution (including the
> > Dockerfile), to be deployed to the release repository at dist.apache.org
> > b) Kubernetes Operator Helm Chart to be deployed to the release
> repository
> > at dist.apache.org
> > c) Maven artifacts to be deployed to the Maven Central Repository
> >
> > **Staging Areas to Review**
> >
> > The staging areas containing the above mentioned artifacts are as
> follows,
> > for your review:
> > * All artifacts for a,b) can be found in the corresponding dev repository
> > at dist.apache.org [1]
> > * All artifacts for c) can be found at the Apache Nexus Repository [2]
> >
> > All artifacts are signed with the
> > key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3]
> >
> > Other links for your review:
> > * JIRA release notes [4]
> > * source code tag "release-0.1.0-rc1" [5]
> > * PR to update the website Downloads page to include Kubernetes Operator
> > links [6]
> >
> > **Vote Duration**
> >
> > The voting time will run for at least 72 hours.
> > It is adopted by majority approval, with at least 3 PMC affirmative
> votes.
> >
> > **Note for Functional Verification**
> > Please use the source distribution and helm chart directly from [1] to
> > build and deploy the operator in your testing environment.
> >
> > Thanks,
> > Gyula
> >
> > [1]
> >
> https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/
> > [2]
> https://repository.apache.org/content/repositories/orgapacheflink-1490/
> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> > [4]
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499
> > [5]
> >
> https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1
> > [6] https://github.com/apache/flink-web/pull/519
> >
>
>
Re: [VOTE] Apache Flink Kubernetes Operator Release 0.1.0, release candidate #1
Posted by Chesnay Schepler <ch...@apache.org>.
There's some strange stuff in here.
What exactly is the purpose of flink-kubernetes-shaded? You're just
re-packaging flink-kubernetes without making any changes.
The uploaded flink-kubernetes-operator jar isn't bundling any
dependencies. Why is the fat jar not uploaded? Is it used anywhere else
(e.g., directly embedded into a docker image)
If it is used, where do you have the appropriate licensing information
for the bundled dependencies?
On 28/03/2022 16:14, Gyula Fóra wrote:
> Hi everyone,
>
> Please review and vote on the release candidate #1 for the version 0.1.0 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 the following:
> a) Kubernetes Operator canonical source distribution (including the
> Dockerfile), to be deployed to the release repository at dist.apache.org
> b) Kubernetes Operator Helm Chart to be deployed to the release repository
> at dist.apache.org
> c) Maven artifacts to be deployed to the Maven Central Repository
>
> **Staging Areas to Review**
>
> The staging areas containing the above mentioned artifacts are as follows,
> for your review:
> * All artifacts for a,b) can be found in the corresponding dev repository
> at dist.apache.org [1]
> * All artifacts for c) can be found at the Apache Nexus Repository [2]
>
> All artifacts are signed with the
> key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3]
>
> Other links for your review:
> * JIRA release notes [4]
> * source code tag "release-0.1.0-rc1" [5]
> * PR to update the website Downloads page to include Kubernetes Operator
> links [6]
>
> **Vote Duration**
>
> The voting time will run for at least 72 hours.
> It is adopted by majority approval, with at least 3 PMC affirmative votes.
>
> **Note for Functional Verification**
> Please use the source distribution and helm chart directly from [1] to
> build and deploy the operator in your testing environment.
>
> Thanks,
> Gyula
>
> [1]
> https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/
> [2] https://repository.apache.org/content/repositories/orgapacheflink-1490/
> [3] https://dist.apache.org/repos/dist/release/flink/KEYS
> [4]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499
> [5]
> https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1
> [6] https://github.com/apache/flink-web/pull/519
>