[ 
https://issues.apache.org/jira/browse/BEAM-8402?focusedWorklogId=332177&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-332177
 ]

ASF GitHub Bot logged work on BEAM-8402:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 22/Oct/19 20:05
            Start Date: 22/Oct/19 20:05
    Worklog Time Spent: 10m 
      Work Description: mxm commented on issue #9811: [BEAM-8402] Create a 
class hierarchy to represent environments
URL: https://github.com/apache/beam/pull/9811#issuecomment-545130446
 
 
   I think Robert's idea is to specify a set of required runtime dependencies, 
in the form of "Java with Beam 2.16.0 with libraries XY"; and then let Beam 
create an environment that fits these requirements. The question is whether we 
should really "bake in" the existing environments into the model itself. It 
does not have to be a contradiction because we could support "legacy" 
environments  (like the existing) and eventually replace them by the "smart" 
dynamic environments.
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 332177)
    Time Spent: 1h  (was: 50m)

> Create a class hierarchy to represent environments
> --------------------------------------------------
>
>                 Key: BEAM-8402
>                 URL: https://issues.apache.org/jira/browse/BEAM-8402
>             Project: Beam
>          Issue Type: New Feature
>          Components: sdk-py-core
>            Reporter: Chad Dombrova
>            Assignee: Chad Dombrova
>            Priority: Major
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> As a first step towards making it possible to assign different environments 
> to sections of a pipeline, we first need to expose environment classes to the 
> pipeline API.  Unlike PTransforms, PCollections, Coders, and Windowings,  
> environments exists solely in the portability framework as protobuf objects.  
>  By creating a hierarchy of "native" classes that represent the various 
> environment types -- external, docker, process, etc -- users will be able to 
> instantiate these and assign them to parts of the pipeline.  The assignment 
> portion will be covered in a follow-up issue/PR.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to