Hi Aljoscha,
Thanks for your advice. +1 to align the config pattern.
I also agree that we need to move the long discussion to the [DISCUSS]
thread. Sorry if it bothers you.
Best,
Yangze Guo
On Thu, Apr 16, 2020 at 7:52 AM Becket Qin <becket....@gmail.com> wrote:
>
> I agree with Aljoscha. It is important to keep API the same style. And we
> probably should move the long discussion to the [DISCUSS] thread.
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
> On Wed, Apr 15, 2020 at 11:27 PM Aljoscha Krettek <aljos...@apache.org>
> wrote:
>
> > Is the only really new method on the public APIs
> > getExternalResourceInfos(..) on the RuntimeContext? I'm generally quite
> > skeptical about adding anything to that interface but the method seems ok.
> >
> > Side note for the configuration keys: the pattern is similar to metrics
> > configuration. There we have "metrics.reporters" = <list of reporter
> > names> and then metrics.reporter.<foobazzle>... Your proposal is
> > slightly different in that it uses "external-resource.list". Keeping
> > this in line with metrics configuration would suggest to use
> > "external-resources", and then "external-resource.<foobazzle>...". What
> > do you think?
> >
> > Also, why is there this long discussion in a [VOTE] thread?
> >
> > Best,
> > Aljoscha
> >
> > On 15.04.20 10:32, Yangze Guo wrote:
> > > Thanks for the explanation. I do not have a strong opinion regarding
> > > this interface. So, if it is better from your perspective, I'm +1 for
> > > this. I just saying it may not help a lot regarding the type-safe.
> > >
> > > Regarding the bounded wildcard type, yes, it's the implementation
> > > detail. If it won't make a difference for user, I'm also +1 for not
> > > using bounded wildcard type there.
> > >
> > > Best,
> > > Yangze Guo
> > >
> > > On Wed, Apr 15, 2020 at 4:23 PM Till Rohrmann <trohrm...@apache.org>
> > wrote:
> > >>
> > >> I think <T extends ExternalResourceInfo> Set<T>
> > >> getExternalResourceInfos(String resourceName, Class<T>
> > >> externalResourceType) is not less flexible than the other API since you
> > can
> > >> always pass in ExternalResourceInfo.class as the second argument.
> > >>
> > >> The benefit I see for the user is that he does not have to do the
> > >> instanceof checks and type casts himself. This is admittedly not a big
> > deal
> > >> but still a better API imo.
> > >>
> > >> I think the interface of the Driver and what is returned by the
> > >> RuntimeContext don't have to have the same type because you can cast it
> > or
> > >> repack it. If the current implementation simply stores what the Driver
> > >> returns and RuntimeContext returns this map, then it might seem that
> > there
> > >> is a connection. But this should be an implementation detail rather
> > than a
> > >> necessity.
> > >>
> > >> Maybe we could also pull in someone from the SDK team to give us his
> > >> opinion on the user facing API.
> > >>
> > >> Cheers,
> > >> Till
> > >>
> > >> On Wed, Apr 15, 2020 at 10:13 AM Xintong Song <tonysong...@gmail.com>
> > wrote:
> > >>
> > >>>>
> > >>>> I agree that such an interface won't give compile time checks but I
> > think
> > >>>> that it could be easier to use from a user's perspective because
> > there is
> > >>>> no explicit casting required.
> > >>>> public interface RuntimeContext {
> > >>>> <T extends ExternalResourceInfo> Set<T>
> > >>> getExternalResourceInfos(String
> > >>>> resourceName, Class<T> externalResourceType);
> > >>>> }
> > >>>
> > >>>
> > >>> I'm not sure how less efforts is required from users to pass in a
> > >>> `externalResourceType` compared to do an explicit type casting.
> > >>> A potential side effect of passing in a `externalResourceType` is
> > that, it
> > >>> requires user (e.g. the operator) to know which specific type should be
> > >>> returned in advance, which may limit the flexibility.
> > >>>
> > >>> E.g., we might have an operator that can work with multiple different
> > >>> implementations of `ExternalResourceInfo`. It may decide its behavior
> > based
> > >>> on the actually type returned by `getExternalResourceInfos` at runtime.
> > >>>
> > >>>
> > >>> Thank you~
> > >>>
> > >>> Xintong Song
> > >>>
> > >>>
> > >>>
> > >>> On Wed, Apr 15, 2020 at 4:09 PM Yangze Guo <karma...@gmail.com> wrote:
> > >>>
> > >>>> @Till
> > >>>> If we add "Class<T> externalResourceType" param, what if there are
> > >>>> multiple subtypes in the ExternalResourceInfos set of one external
> > >>>> resource? It seems user has to set the T to ExternalResourceInfo and
> > >>>> the mechanism is useless at this case.
> > >>>>
> > >>>> Best,
> > >>>> Yangze Guo
> > >>>>
> > >>>> On Wed, Apr 15, 2020 at 3:57 PM Till Rohrmann <trohrm...@apache.org>
> > >>>> wrote:
> > >>>>>
> > >>>>> Ok, if there can be multiple resources of the same type then we
> > >>>> definitely
> > >>>>> need the name as a differentiator.
> > >>>>>
> > >>>>> I agree that such an interface won't give compile time checks but I
> > >>> think
> > >>>>> that it could be easier to use from a user's perspective because
> > there
> > >>> is
> > >>>>> no explicit casting required.
> > >>>>>
> > >>>>> public interface RuntimeContext {
> > >>>>> <T extends ExternalResourceInfo> Set<T>
> > >>>> getExternalResourceInfos(String
> > >>>>> resourceName, Class<T> externalResourceType);
> > >>>>> }
> > >>>>>
> > >>>>> One minor note: I think the value of the returned map does not need
> > to
> > >>>> use
> > >>>>> a bounded wildcard type because for the user it won't make a
> > >>> difference.
> > >>>>>
> > >>>>> Cheers,
> > >>>>> Till
> > >>>>>
> > >>>>> On Wed, Apr 15, 2020 at 8:20 AM Yangze Guo <karma...@gmail.com>
> > wrote:
> > >>>>>
> > >>>>>> Hi Till,
> > >>>>>>
> > >>>>>>> ExternalResourceDriver could return a Set<? extends
> > >>>>>> ExternalResourceInfo>.
> > >>>>>> It sounds good.
> > >>>>>>
> > >>>>>>> then one could make the interface type-safe by changing it to
> > >>>>>>> public interface RuntimeContext {
> > >>>>>>> <T extends ExternalResourceInfo> Set<T>
> > >>>>>>> getExternalResourceInfo(Class<T> externalResourceType);
> > >>>>>>> }
> > >>>>>> I think it may not help.
> > >>>>>> - I think the assumption of "there is always only one resource of a
> > >>>>>> specific type" is too strong. The external resource framework should
> > >>>>>> only assume it gets a set of ExternalResourceInfo from the driver.
> > >>> The
> > >>>>>> concrete implementation is given by user. So, if we give such an
> > >>>>>> assumption, it would hurt the flexibility. There could be multiple
> > >>>>>> types in the returned externalResourceInfo set. There could also be
> > >>>>>> different types returned from different driver implementation or
> > >>>>>> version. The contract about the return type between Driver and
> > >>>>>> Operator should be guaranteed by user.
> > >>>>>> - Since the Drivers are loaded dynamically in runtime, if there is a
> > >>>>>> type mismatch, the job would fail in runtime instead of in compile
> > >>>>>> time, no matter the type extraction is done by Operator or Flink
> > >>> core.
> > >>>>>> This interface would not gain benefits for type safety.
> > >>>>>>
> > >>>>>> Best,
> > >>>>>> Yangze Guo
> > >>>>>>
> > >>>>>> On Wed, Apr 15, 2020 at 1:38 AM Till Rohrmann <trohrm...@apache.org
> > >
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>> Thanks for updating the FLIP, Yangze.
> > >>>>>>>
> > >>>>>>> If ExternalResourceInfo is a marker interface, then
> > >>>>>> ExternalResourceDriver
> > >>>>>>> could return a Set<? extends ExternalResourceInfo>. This makes is a
> > >>>> bit
> > >>>>>>> nicer for the implementor because he can use the concrete subtype.
> > >>>>>>>
> > >>>>>>> If we assume that users will always cast the ExternalResourceInfo
> > >>>>>> instance
> > >>>>>>> into the concrete subtype and if we assume that there is always
> > >>> only
> > >>>> one
> > >>>>>>> resource of a specific type, then one could make the interface
> > >>>> type-safe
> > >>>>>> by
> > >>>>>>> changing it to
> > >>>>>>>
> > >>>>>>> public interface RuntimeContext {
> > >>>>>>> <T extends ExternalResourceInfo> Set<T>
> > >>>>>>> getExternalResourceInfo(Class<T> externalResourceType);
> > >>>>>>> }
> > >>>>>>>
> > >>>>>>> If we want to support multiple GPU resources, then one would need
> > >>> to
> > >>>> use
> > >>>>>>> the name of the respective resource as well.
> > >>>>>>>
> > >>>>>>> Cheers,
> > >>>>>>> Till
> > >>>>>>>
> > >>>>>>> On Mon, Apr 13, 2020 at 4:19 AM Xintong Song <
> > >>> tonysong...@gmail.com>
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Thanks for updating the FLIP, Yangze.
> > >>>>>>>> The latest FLIP looks good to me.
> > >>>>>>>>
> > >>>>>>>> nit: Javadoc of `ExternalResourceDriver#retrieveResourceInfo` is
> > >>>> out of
> > >>>>>>>> sync.
> > >>>>>>>>
> > >>>>>>>>> Retrieve the information of the external resources according to
> > >>>> the
> > >>>>>>>>> resourceProfile.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Thank you~
> > >>>>>>>>
> > >>>>>>>> Xintong Song
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Sat, Apr 11, 2020 at 11:04 AM Becket Qin <
> > >>> becket....@gmail.com>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Good feedback form Xintong. The latest FLIP looks good to me.
> > >>>>>>>>>
> > >>>>>>>>> Thanks,
> > >>>>>>>>>
> > >>>>>>>>> Jiangjie (Becket) Qin
> > >>>>>>>>>
> > >>>>>>>>> On Sat, Apr 11, 2020 at 9:20 AM Yangze Guo <karma...@gmail.com
> > >>>>
> > >>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Hi there,
> > >>>>>>>>>> I've updated the FLIP accordingly. Please take a look. If you
> > >>>> have
> > >>>>>> any
> > >>>>>>>>>> further concerns please let me know.
> > >>>>>>>>>>
> > >>>>>>>>>> Best,
> > >>>>>>>>>> Yangze Guo
> > >>>>>>>>>>
> > >>>>>>>>>> On Fri, Apr 10, 2020 at 6:40 PM Yangze Guo <
> > >>> karma...@gmail.com
> > >>>>>
> > >>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks for the feedback, Xintong.
> > >>>>>>>>>>>
> > >>>>>>>>>>> - Should we have a factory interface for
> > >>>>>> `ExternalResourceDriver`,
> > >>>>>>>> that
> > >>>>>>>>>>> takes the configuration and returns a driver instance?
> > >>>>>> Otherwise, if
> > >>>>>>>> we
> > >>>>>>>>>> are
> > >>>>>>>>>>> creating the driver instance with reflection, we kind of
> > >>>>>> implicitly
> > >>>>>>>>>>> requires the driver to have a public non-argument
> > >>>> constructor.
> > >>>>>> If we
> > >>>>>>>>>>> decided to go with this approach, then we will not need
> > >>>>>>>>>>> `ExternalResourceDriver#open`.
> > >>>>>>>>>>>
> > >>>>>>>>>>> True, we could have an `ExternalResourceDriverFactory`,
> > >>> like
> > >>>>>>>>>>> interface ExternalResourceDriverFactory {
> > >>>>>>>>>>> ExternalResourceDriver fromConfiguration(Configuration
> > >>>>>> config);
> > >>>>>>>>>>> }
> > >>>>>>>>>>> Regarding the configuration, the user should provide
> > >>>>>>>>>>> "external-resource.{resourceName}.driver-factory.class"
> > >>>> instead.
> > >>>>>>>>>>>
> > >>>>>>>>>>> - Not sure about the necessity of
> > >>>>>> `ExternalResourceDriver#close`. I
> > >>>>>>>>> would
> > >>>>>>>>>>> suggest to avoid introduce more interfaces if not
> > >>> absolutely
> > >>>>>>>> necessary.
> > >>>>>>>>>>>
> > >>>>>>>>>>> I add `ExternalResourceDriver#close` in case user needs to
> > >>>> clean
> > >>>>>> up
> > >>>>>>>>>>> internal states and any other resources. It's true that it
> > >>>> may
> > >>>>>> not
> > >>>>>>>>>>> absolutely necessary for our GPUDriver. From my side, I'm
> > >>> ok
> > >>>> to
> > >>>>>>>> remove
> > >>>>>>>>>>> it.
> > >>>>>>>>>>>
> > >>>>>>>>>>> - `ExternalResourceDriver#retrieveResourceInfo` should not
> > >>>> take
> > >>>>>>>>>>> `ResourceProfile` as argument. This exposes more
> > >>> information
> > >>>>>> than it
> > >>>>>>>>>> needs.
> > >>>>>>>>>>> In addition, it requires the runtime/core to understand how
> > >>>> to
> > >>>>>>>> properly
> > >>>>>>>>>>> wrap the external resource into `ResourceProfile`. E.g.,
> > >>>>>>>>>>> `ResourceProfile#extendedResources` takes `Resource`, which
> > >>>> is an
> > >>>>>>>>>> abstract
> > >>>>>>>>>>> class. Runtime/core has to known which implementation of
> > >>>>>> `Resource`
> > >>>>>>>> to
> > >>>>>>>>>> use.
> > >>>>>>>>>>>
> > >>>>>>>>>>> True, at the moment, I think the amount of the resource is
> > >>>>>> enough for
> > >>>>>>>>>>> the `ExternalResourceDriver#retrieveResourceInfo`. In the
> > >>>>>> future, if
> > >>>>>>>>>>> the fine-grained external resource management is supported,
> > >>>> the
> > >>>>>>>> amount
> > >>>>>>>>>>> of the resource seems to be enough either. If we want to
> > >>>> leverage
> > >>>>>>>> some
> > >>>>>>>>>>> external resources which could not be measured by a single
> > >>>> long
> > >>>>>>>> value,
> > >>>>>>>>>>> we might enrich this. But I'd like to keep it out of the
> > >>>> scope of
> > >>>>>>>> this
> > >>>>>>>>>>> FLIP.
> > >>>>>>>>>>>
> > >>>>>>>>>>> - Do we really need `ExternalResourceInfo#getInformation`?
> > >>> I
> > >>>>>> think it
> > >>>>>>>>>>> should be good enough to make `ExternalResourceInfo` an
> > >>> empty
> > >>>>>>>>> interface.
> > >>>>>>>>>>> User can define their own `ExternalResourceInfo`
> > >>>> implementation
> > >>>>>> and
> > >>>>>>>> how
> > >>>>>>>>>> it
> > >>>>>>>>>>> is used by the operator user codes.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Sounds good.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Best,
> > >>>>>>>>>>> Yangze Guo
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Fri, Apr 10, 2020 at 6:04 PM Xintong Song <
> > >>>>>> tonysong...@gmail.com>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Sorry to pull this back. I have some concerns about the
> > >>>> recent
> > >>>>>>>>> updated
> > >>>>>>>>>>>> interface details.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> - Should we have a factory interface for
> > >>>>>> `ExternalResourceDriver`,
> > >>>>>>>>> that
> > >>>>>>>>>>>> takes the configuration and returns a driver instance?
> > >>>>>> Otherwise,
> > >>>>>>>> if
> > >>>>>>>>>> we are
> > >>>>>>>>>>>> creating the driver instance with reflection, we kind of
> > >>>>>> implicitly
> > >>>>>>>>>>>> requires the driver to have a public non-argument
> > >>>> constructor.
> > >>>>>> If
> > >>>>>>>> we
> > >>>>>>>>>>>> decided to go with this approach, then we will not need
> > >>>>>>>>>>>> `ExternalResourceDriver#open`.
> > >>>>>>>>>>>> - Not sure about the necessity of
> > >>>>>> `ExternalResourceDriver#close`. I
> > >>>>>>>>>> would
> > >>>>>>>>>>>> suggest to avoid introduce more interfaces if not
> > >>>> absolutely
> > >>>>>>>>> necessary.
> > >>>>>>>>>>>> - `ExternalResourceDriver#retrieveResourceInfo` should
> > >>> not
> > >>>> take
> > >>>>>>>>>>>> `ResourceProfile` as argument. This exposes more
> > >>>> information
> > >>>>>> than
> > >>>>>>>> it
> > >>>>>>>>>> needs.
> > >>>>>>>>>>>> In addition, it requires the runtime/core to understand
> > >>>> how to
> > >>>>>>>>> properly
> > >>>>>>>>>>>> wrap the external resource into `ResourceProfile`. E.g.,
> > >>>>>>>>>>>> `ResourceProfile#extendedResources` takes `Resource`,
> > >>>> which is
> > >>>>>> an
> > >>>>>>>>>> abstract
> > >>>>>>>>>>>> class. Runtime/core has to known which implementation of
> > >>>>>> `Resource`
> > >>>>>>>>> to
> > >>>>>>>>>> use.
> > >>>>>>>>>>>> - Do we really need
> > >>> `ExternalResourceInfo#getInformation`?
> > >>>> I
> > >>>>>> think
> > >>>>>>>> it
> > >>>>>>>>>>>> should be good enough to make `ExternalResourceInfo` an
> > >>>> empty
> > >>>>>>>>>> interface.
> > >>>>>>>>>>>> User can define their own `ExternalResourceInfo`
> > >>>>>> implementation and
> > >>>>>>>>>> how it
> > >>>>>>>>>>>> is used by the operator user codes.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Thank you~
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Xintong Song
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Thu, Apr 9, 2020 at 2:25 PM Becket Qin <
> > >>>>>> becket....@gmail.com>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> +1
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thanks for driving this effort, Ynagze. The latest FLIP
> > >>>> wiki
> > >>>>>>>> looks
> > >>>>>>>>>> good to
> > >>>>>>>>>>>>> me.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Cheers,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Jiangjie (Becket) Qin
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Wed, Apr 8, 2020 at 4:10 PM Yangze Guo <
> > >>>>>> karma...@gmail.com>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Edit: RuntimeContext interface
> > >>>>>>>>>>>>>> From: Map<String, Set<ExternalResourceInfo>>
> > >>>>>>>>>>>>>> getExternalResourceInfo(ResourceSpec resourceSpec);
> > >>>>>>>>>>>>>> To: Map<String, Set<ExternalResourceInfo>>
> > >>>>>>>>>> getExternalResourceInfo();
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>>> Yangze Guo
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Wed, Apr 8, 2020 at 11:36 AM Yangze Guo <
> > >>>>>> karma...@gmail.com
> > >>>>>>>>>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Hi, there
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I have updated the FLIP, mainly target to make it
> > >>>> more
> > >>>>>>>> detailed
> > >>>>>>>>>> and
> > >>>>>>>>>>>>>>> clear. The general design is not changed, but there
> > >>>> are
> > >>>>>> still
> > >>>>>>>>>> some
> > >>>>>>>>>>>>>>> changes need to be notified here:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> - Change the `ExternalResourceDriver` from abstract
> > >>>>>> class to
> > >>>>>>>>>>>>>>> interface, since it does not have an abstract
> > >>>>>> implementation.
> > >>>>>>>>>> Add life
> > >>>>>>>>>>>>>>> cycle method `open` and `close`.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> - Specify the method added to the RuntimeContext
> > >>> from
> > >>>>>> which
> > >>>>>>>>> user
> > >>>>>>>>>> get
> > >>>>>>>>>>>>>>> the information of external resources.
> > >>>>>>>>>>>>>>> Map<String, Set<ExternalResourceInfo>>
> > >>>>>>>>>>>>>>> getExternalResourceInfo(ResourceSpec resourceSpec);
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> - Add "String getInformation()" method to
> > >>>>>>>>> `ExternalResourceInfo`
> > >>>>>>>>>>>>>> interface.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> - Treat adding external resource info to
> > >>>> RestAPI/WebUI
> > >>>>>> as a
> > >>>>>>>>>> future
> > >>>>>>>>>>>>> work.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> If you have any new concerns after that change,
> > >>>> please
> > >>>>>>>>> mentioned
> > >>>>>>>>>> here.
> > >>>>>>>>>>>>>>> Sorry for disturbing you.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>>>> Yangze Guo
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Wed, Apr 8, 2020 at 9:55 AM Yang Wang <
> > >>>>>>>>> danrtsey...@gmail.com>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Thanks Yangze for the efforts to support GPU
> > >>>> extended
> > >>>>>>>>>> resources.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> +1 for this FLIP
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>>>>> Yang
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Till Rohrmann <trohrm...@apache.org>
> > >>> 于2020年4月2日周四
> > >>>>>>>> 下午11:10写道：
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Thanks for driving this effort Yangze.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> +1
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Cheers,
> > >>>>>>>>>>>>>>>>> Till
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Wed, Apr 1, 2020 at 12:41 PM Canbin Zheng <
> > >>>>>>>>>>>>> felixzhen...@gmail.com
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Thanks Yangze for driving the initial CPU
> > >>>> support!
> > >>>>>>>>>>>>>>>>>> +1 (non-binding) from my side.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Xintong Song <tonysong...@gmail.com>
> > >>>> 于2020年4月1日周三
> > >>>>>>>>>> 下午6:36写道：
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Thanks Yangze, the FLIP looks good to me.
> > >>>>>>>>>>>>>>>>>>> +1 (non-binding) from my side.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Thank you~
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Xintong Song
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On Wed, Apr 1, 2020 at 5:22 PM Yangze Guo <
> > >>>>>>>>>> karma...@gmail.com>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Hi everyone,
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> I'd like to start the vote of FLIP-108
> > >>> [1],
> > >>>>>> which
> > >>>>>>>>> adds
> > >>>>>>>>>> GPU
> > >>>>>>>>>>>>>> support in
> > >>>>>>>>>>>>>>>>>>>> Flink. This FLIP is discussed in the
> > >>>> thread[2].
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> The vote will be open for at least 72
> > >>>> hours.
> > >>>>>> Unless
> > >>>>>>>>>> there is
> > >>>>>>>>>>>>> an
> > >>>>>>>>>>>>>>>>>>> objection,
> > >>>>>>>>>>>>>>>>>>>> I will try to close it by April 4, 2020
> > >>>> 10:00
> > >>>>>> UTC
> > >>>>>>>> if
> > >>>>>>>>>> we have
> > >>>>>>>>>>>>>> received
> > >>>>>>>>>>>>>>>>>>>> sufficient votes.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> [1]
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>>
> > https://cwiki.apache.org/confluence/display/FLINK/FLIP-108%3A+Add+GPU+support+in+Flink
> > >>>>>>>>>>>>>>>>>>>> [2]
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>>
> > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-108-Add-GPU-support-in-Flink-td38286.html
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>>>>>>>>> Yangze Guo
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>>
> >
> >
