[DISCUSS] Separating Cloud Environment(s) - Separate Dev/Test from Production 'Testing' environment(s)

[Austin Bennett]

Howdy!

I'm increasingly concerned by our Cloud 'Testing' environment ( resources
associated with the 'apache-beam-testing' GCP project ).

The following might sound a little strange, given repetition of words [ and
many meanings of 'testing']:

* There is a 'production' need for ongoing testing infrastructure, tests,
pipelines, builds.
and
* There are also a 'development' and/or 'test' needs for extending the
functionality, tests, and exploring new things, before definitely adopting
and making production [ ex: getting onto master ].
and
* There is a very real possibility that someone 'testing' or 'developing'
new features/functionality, could accidentally delete/change/modify
critical resources in the solo environment -AND- We do not have super
quick/easy restore paths in the event of serious trouble - ex: if things
deleted.  [ I assume, as I don't see terraform/other code that seems
definitely easy to re-create resources ...  BUT, I could be missing and not
understanding this point ].


There could be benefits [ also costs/burdens, or pros/cons to consider ]
from separating functions/environments to minimize when/how people are
manually using resources/roles with permissions to modify the critical
infrastructure.

I have some ideas for steps to address [ and where I could step in to help
implement ], but before starting to formalize ideas and strategies [ longer
write-ups, etc ], wanted to open for discussion to ensure whether this is
thinking that makes sense, that the community believes would be valuable.
If done well, longer-term I imagine most of the to-be-solution would have
little effect on actual users of environments [ including
developers/committers/etc ] and mostly would be around better separation
and more attention paid to controls/branches/roles/permissions.

*Can people share thoughts around potentially having at least one more
environment to add additional safety around our critical code testing
infrastructure, to keep that further distinct from workflows/process/code
that is still being developed?*

Do advise,
Cheers,
Austin

Beam Dependency Check Report (2022-10-06)

[Apache Jenkins Server]

<<< text/html; charset=UTF-8: Unrecognized >>>

Re: [VOTE] Release 2.42.0, release candidate #1

[Alexey Romanenko]

Is it a regression or just recently discovered?

—
Alexey

> On 6 Oct 2022, at 01:13, Eike Falkenberg via dev  wrote:
> 
> Hey everyone,
> 
> We have gotten customer feedback about by this issue 
>  and provided a PR that is in 
> review .
> Because of the significance of the user/customer impact, I would like to get 
> this cherry picked into the 2.42.0 release, is that still possible?
> 
> Thanks!
> 
> Eike
> 
> 
> 
> 
> 
> On 2022/09/30 01:12:11 Robert Burke via dev wrote:
> > Hi everyone,
> > Please review and vote on the release candidate #1 for the version 2.42.0,
> > as follows:
> > [ ] +1, Approve the release
> > [ ] -1, Do not approve the release (please provide specific comments)
> > 
> > Reviewers are encouraged to test their own use cases with the release
> > candidate, and vote +1 if no issues are found.
> > 
> > The complete staging area is available for your review, which includes:
> > * GitHub Release notes [1],
> > * the official Apache source release to be deployed to dist.apache.org 
> >  [2],
> > which is signed with the key with fingerprint
> > A52F5C83BAE26160120EC25F3D56ACFBFB2975E1 [3],
> > * all artifacts to be deployed to the Maven Central Repository [4],
> > * source code tag "v2.42.0-RC1" [5],
> > * website pull request listing the release [6], the blog post [6], and
> > publishing the API reference manual [7].
> > * Java artifacts were built with Gradle GRADLE_VERSION and OpenJDK/Oracle
> > JDK JDK_VERSION.
> > * Python artifacts are deployed along with the source release to the
> > dist.apache.org  [2] and PyPI [8]
> > * Go Package information and SDK RC  [9]
> > * Validation sheet with a tab for 2.42.0 release to help with validation
> > [10].
> > * Docker images published to Docker Hub [11].
> > 
> > The vote will be open for at least 72 hours. It is adopted by majority
> > approval, with at least 3 PMC affirmative votes.
> > 
> > For guidelines on how to try the release in your projects, check out our
> > blog post at https://beam.apache.org/blog/validate-beam-release/ 
> > .
> > 
> > Thanks,
> > Robert Burke
> > 2.42.0 Release Manager
> > 
> > [1] https://github.com/apache/beam/milestone/4 
> > 
> > [2] https://dist.apache.org/repos/dist/dev/beam/2.42.0/ 
> > 
> > [3] https://dist.apache.org/repos/dist/release/beam/KEYS 
> > 
> > [4] https://repository.apache.org/content/repositories/orgapachebeam-1285/ 
> > 
> > [5] https://github.com/apache/beam/tree/v2.42.0-RC1 
> > 
> > [6] https://github.com/apache/beam/pull/23406 
> > 
> > [7] https://github.com/apache/beam-site/pull/634 
> > 
> > [8] https://pypi.org/project/apache-beam/2.42.0rc1/ 
> > 
> > [9]
> > https://pkg.go.dev/github.com/apache/beam/sdks/v2@v2.42.0-RC1/go/pkg/beam 
> > 
> > [10]
> > https://docs.google.com/spreadsheets/d/1qk-N5vjXvbcEk68GjbkSZTR8AGqyNUM-oLFo_ZXBpJw/edit#gid=265602293
> >  
> > 
> > [11] https://hub.docker.com/search?q=apache%2Fbeam=image 
> > 
> >