profile
viewpoint
Yulia Gaponenko barthy1 IBM - Red Hat Böblingen, Germany

barthy1/archive-resource 0

downloads and extracts an archive (currently tgz) from a uri

barthy1/baggageclaim 0

loses your luggage

barthy1/bin 0

Concourse in a single binary

barthy1/binary-builder 0

Builds binaries against the rootfs of your choice.

barthy1/binary-buildpack 0

Deploy binaries to Cloud Foundry

barthy1/bosh 0

Cloud Foundry BOSH is an open source tool chain for release engineering, deployment and lifecycle management of large scale distributed services.

barthy1/bosh-acceptance-tests 0

BATs: BOSH Acceptance Tests

barthy1/bosh-agent 0

BOSH Agent runs on each BOSH deployed VM

PR opened linkedin/cruise-control

Run cruise-control tests for s390x architecture

This PR resolves #1736.

The extension to the current Circle CI setup allows to run the cruise-control tests for non-Intel architectures. As first step linux/s390x platform is used. New platforms can be added to the existing matrix, once there is interest for it. The tests for non-Intel architecture are executed in parallel with the standard build/test job, so no extra time is used for the whole test pipeline.

The idea is to run docker container on standard Intel host via standard Circle CI setup in hardware emulation mode via docker --platform parameter and do the tests inside the container, similar to how it can be executed on real ARM, Power or Z hardware. To make sure which architecture is emulated inside the container - uname -a command is executed before the actual test.

The proposed patch was tested with Circle CI - https://app.circleci.com/pipelines/github/barthy1/cruise-control/47/workflows/5f97d894-d3ae-4009-bd95-3b5861f05426

+41 -2

0 comment

1 changed file

pr created time in 11 days

issue openedlinkedin/cruise-control

Run current cruise-control tests for Z (linux/s390x) architecture

My team is working now on Strimzi enablement for Z(linux/s390x) architecture. Cruise-control project is used in strimzi and it's already practically verified that it works perfectly well for Z. However we would like to extend current testing setup of cruise-control to run the tests on Z for each PR. Following https://github.com/linkedin/cruise-control/issues/1486 the cruise-control team is positive to extend current CI/CD to run tests on non-Intel architectures. Our suggestion is to continue using Circle CI and just add new job to run the cruise-control tests inside the Docker container in hardware emulation mode in parallel with standard test/build job. This approach allows to run the tests on emulated Z hardware, using as host standard Circle Ci workers.

created time in 11 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 79898e81f5e12d4d075a1ec0065ce1d9c4bf52ae

Run cruise-control tests for s390x architecture The extenstion to the current CircleCI setup allows to run the cruise-control tests for non-Intel architectures. As first step linux/s390x platform is used. New platforms can be added to the existing matrix, once there is interest for it. The idea is to run docker container on standard Intel host via standard CirclCI setup in hardware emulation mode via dockere --platform parameter and do the tests inside the container, similar to how it can be executed on real ARM, Power or Z hardware. To make sure which architecture is emulated inside the container - `uname -a` command is executed before the actual test. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>

view details

push time in 12 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 1834ce91c028002e9468937828d0254b2668a093

Run cruise-control tests for s390x architecture The extenstion to the current CircleCI setup allows to run the cruise-control tests for non-Intel architectures. As first step linux/s390x platform is used. New platforms can be added to the existing matrix, once there is interest for it. The idea is to run docker container on standard Intel host via standard CirclCI setup in hardware emulation mode via dockere --platform parameter and do the tests inside the container, similar to how it can be executed on real ARM, Power or Z hardware. To make sure which architecture is emulated inside the container - `uname -a` command is executed before the actual test. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>

view details

push time in 12 days

push eventbarthy1/cruise-control

Adem Efe Gencer

commit sha 1f6214203076b97ed788ccef7815a6184a3d9438

Adopt admin client-based replica reassignment API for Kafka 2.4+ (#1196)

view details

Adem Efe Gencer

commit sha 2a0b83741b539a45c707274104a7d4047cabc365

Eliminate repetitive random cluster tests. (#1201)

view details

Adem Efe Gencer

commit sha 57fadb8a88110a881a5e9649d3f45ded55f120d6

Add rack information to load response. (#1199)

view details

Adem Efe Gencer

commit sha 86ce1cf9d12e412b8998d43674a77a4ef689ccfe

Add missing sanity check for goals. (#1203)

view details

Adem Efe Gencer

commit sha 6a252039957d47f8b5b88460ffba328b0ed45419

Update the interested metrics used by the metric anomaly analyzer and the anomaly notifier section in README. (#1206)

view details

Adem Efe Gencer

commit sha 3ff14a70f3be24a3972276b63010d177fc6bcc26

Fix NPE if task execution takes longer than executionProgressCheckIntervalMs(). (#1209)

view details

Adem Efe Gencer

commit sha d6d10fdf5c6f25c125a437b898034388586a2878

Make CPU capacity threshold stricter. (#1212)

view details

Adem Efe Gencer

commit sha e355506b66af8891fc2c2bd167b17c90270e481f

Update the Balancedness Score under Unhealthy Cluster State (#1214)

view details

Adrian Muraru

commit sha 221fcae75716af01b75bc2eaa6cde18462f34c2c

Fix Java11 JavaDoc errors (#1215)

view details

Adem Efe Gencer

commit sha b70a9d8c99a06dc1a447b5ce721e587573bf6d04

Fix flaky test ExecutorTest#testTimeoutAndForceExecutionStop() (#1219)

view details

Adem Efe Gencer

commit sha f6f0d61a6e795e6565f5937d30dfcecee5251d46

Ensure that requests to update replication factor cannot cause a deadlock. (#1223)

view details

Adem Efe Gencer

commit sha 595ad7dfbac800d0df3a977b5e4bf909dfffbe54

Allow customization of CruiseControlMetricsReporterSampler (#1225)

view details

Adrian Muraru

commit sha 77f5e283b4dbd69a7bd731fab5591b41687a679d

Compile using Java 11 (#1217) * Migrate from findbugs to spotbugs (findbugs won't work with java 11). This required separation of spotBugs gradle task in a separate run in CircleCI to avoid out of memory issues * Fix checkstyle config files discovery * Fix on prio 1 bug VO_VOLATILE_INCREMENT reported in AnomalyDetector.java * Upgrade org.eclipse.jetty.security and fixed tests to provide a non-null Credential

view details

Paolo Patierno

commit sha b6a51b09f584b1eb9f08ea0cd808cd13b4ca0d8b

Enable configurable backoff on metrics topic creation (#1220)

view details

Adem Efe Gencer

commit sha 7a6cfc7b545f7b1e047989fbf3efb88bd64772f8

Fix reported balancedness when there are offline brokers. (#1231)

view details

Adem Efe Gencer

commit sha 571cdf72ecdd4bc82fb0bcb38123a8b85e269c4d

Ensure consistent rackID during topic_configuration operations to avoid NPE. (#1234)

view details

Adem Efe Gencer

commit sha 6925a7ea5027c6929b111b475ddc1607ef6e3ffd

Update Github PR template and bump up stale dependencies. (#1236)

view details

Thomas Cooper

commit sha 0cb505970d4bc9e68668e1efaaf9df368cf2e5c6

Fix returns for completed_with_error tasks on user_tasks endpoint when json=false (#1232)

view details

Adem Efe Gencer

commit sha 9b109eafc3fc30e37e95c30052aea9b84d434b79

Enable compiling Metrics Reporter with pre-Kafka 2.4 versions (#1240) Contrary to Kafka 2.3, AdminClient in Kafka 2.4 implements an Admin interface. The close() method of AdminClient lives in this Admin interface. Hence, method references to this method are tied to the close method of Admin in the generated bytecode. This patch enables compiling Cruise Control (CC) with different flavors / versions of Kafka in projects that depend on CC.

view details

Adem Efe Gencer

commit sha 5f8a0ab73e7ec09a51079a0b1295ee2460e67f23

Fix inconsistent/bad response in monitor substate. (#1238) * Ensure consistent response between load monitor sensors and load monitor state. * Eliminate the need for the costly on-demand aggregation of partition metric samples upon state requests. Instead, it relies on precomputed monitor state response, which enables faster response time (i.e. an order of magnitude faster in large clusters) for state requests. Tradeoff: the load monitor state might be up to MonitorConfig.MONITOR_STATE_UPDATE_INTERVAL_MS_CONFIG ms stale, which is acceptable as this response is not expected to be updated very frequently and the response is used just for informative purposes. * Drop sampleExtrapolations from superVerbose plaintext response of monitor substate. This response is not exposed in JSON response (hence dropping it is backwards compatible). * Refactor premature filtering of excluded brokers during replication factor changes.

view details

push time in 12 days

PullRequestReviewEvent

Pull request review commenttektoncd/catalog

Extend catalog test script to run tests for different platforms

 function test_yaml_can_install() {         for ignore in ${TEST_YAML_IGNORES};do             [[ ${ignore} == "${testname}" ]] && skipit=True         done++        # In case if PLATFORM env variable is specified, do the tests only for matching tasks+        [[ -n ${PLATFORM} ]] && [[ $(grep "tekton.dev/platforms" ${runtest}) != *"${PLATFORM}"* ]]  && skipit=True

@chmouel done

barthy1

comment created time in 18 days

push eventbarthy1/catalog

Yulia Gaponenko

commit sha c6482817f91b4ee0fca4739a0d86327ea9c6ee79

Extend catalog test script to run test for different platforms PLATFORM env variable is introduced. This variable allows to run tests for specific platform (for insance, "linux/s390x" or "linux/ppc64le"). If the environment variable is specified - some tests are updated with different image values/other parameter values, required for specific platform, using yq tool. Custom values should be specified in the script file, separate for each platform. In the current code script file for linux/s390x is proposed. - only tasks, which have mention about corresponding platform support in the annotation, will be tested. If PLATFORM env variale is no specified, the behaviour of test scripts will be similar to the one before the PR. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>

view details

push time in 18 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha dc7eb01bae3dbe6812a853aab5d650932a404c1f

Run cruise-control tests for s390x architecture The extenstion to the current CircleCI setup allows to run the cruise-control tests for non-Intel architectures. As first step linux/s390x platform is used. The idea is to run docker container on standard Intel host in hardware emulation mode via --platform parameter and do the tests inside the container, similar to how it can be executed on real ARM, Power or Z hardware. To make sure which architecture is emulatede inside the container - `uname -a` command is executeede before the actual test. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>

view details

push time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha e612655b75249697e4ded34993c6e6ea10223f49

Run cruise-control tests for s390x architecture The extenstion to the current CircleCI setup allows to run the cruise-control tests for non-Intel architectures. As first step linux/s390x platform is used. The idea is to run docker container on standard Intel host in hardware emulation mode via --platform parameter and do the tests inside the container, similar to how it can be executed on real ARM, Power or Z hardware. To make sure which architecture is emulatede inside the container - `uname -a` command is executeede before the actual test. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>

view details

push time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 6711e9b70bd0a1c532b64bb6d87184ec840d9e85

Run cruise-control tests for s390x architecture The extenstion to the current CircleCI setup allows to run the cruise-control tests for non-Intel architectures. As first step linux/s390x platform is used. The idea is to run docker container on standard Intel host in hardware emulation mode via --platform parameter and do the tests inside the container, similar to how it can be executed on real ARM, Power or Z hardware. To make sure which architecture is emulatede inside the container - `uname -a` command is executeede before the actual test. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>

view details

push time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha fbf94552bc5e7e68a28f73c553abf6c8e870243f

Run cruise-control tests for s390x architecture The extenstion to the current CircleCI setup allows to run the cruise-control tests for non-Intel architectures. As first step linux/s390x platform is used. The idea is to run docker container on standard Intel host in hardware emulation mode via --platform parameter and do the tests inside the container, similar to how it can be executed on real ARM, Power or Z hardware. To make sure which architecture is emulatede inside the container - `uname -a` command is executeede before the actual test. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>

view details

push time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 051d200863f5055e034fd83a0115ff5b6017e193

Run cruise-control tests for s390x architecture The extenstion to the current CircleCI setup allows to run the cruise-control tests for non-Intel architectures. As first step linux/s390x platform is used. The idea is to run docker container on standard Intel host in hardware emulation mode via --platform parameter and do the tests inside the container, similar to how it can be executed on real ARM, Power or Z hardware. To make sure which architecture is emulatede inside the container - `uname -a` command is executeede before the actual test. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>

view details

push time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 83cdb83a0c125b26af3dd116a9d1fbf89268c245

Run cruise-control tests for s390x architecture The extenstion to the current CircleCI setup allows to run the cruise-control tests for non-Intel architectures. As first step linux/s390x platform is used. The idea is to run docker container on standard Intel host in hardware emulation mode via --platform parameter and do the tests inside the container, similar to how it can be executed on real ARM, Power or Z hardware. To make sure which architecture is emulatede inside the container - `uname -a` command is executeede before the actual test. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>

view details

push time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha b3ee22f6720de0786e76b46bd69a31103905211e

Run cruise-control tests for s390x architecture The extenstion to the current CircleCI setup allows to run the cruise-control tests for non-Intel architectures. As first step linux/s390x platform is used. The idea is to run docker container on standard Intel host in hardware emulation mode via --platform parameter and do the tests inside the container, similar to how it can be executed on real ARM, Power or Z hardware. To make sure which architecture is emulatede inside the container - `uname -a` command is executeede before the actual test. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>

view details

push time in 19 days

create barnchbarthy1/cruise-control

branch : multi_arch_test

created branch time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 0af9e4674b522d39e8060f04316341d3524e86fa

test circleci

view details

push time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha ed4876c165f818dd6635178687c3ac33ce13753f

test circleci

view details

push time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 9d4eed15a7459114bc34087c294d203f88dccda8

test circleci

view details

push time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha c822e2371a1819d9ac4f337072f2fe37bca3679c

test circleci

view details

push time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha ca016069f0b59ea0b9dee43612d3c45108b67bb3

test circleci

view details

push time in 19 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 561a80900c6c1b22fdafe117f0e8cbbecf382ed6

test circleci

view details

push time in 19 days

push eventbarthy1/catalog

Yulia Gaponenko

commit sha b6617eb6b912a2913df9f9c5e70a867dda519fb8

Extend catalog test script to run test for different platforms PLATFORM env variable is introduced. This variable allows to run tests for specific platform (for insance, "linux/s390x" or "linux/ppc64le"). If the environment variable is specified - some tests are updated with different image values/other parameter values, required for specific platform, using yq tool. Custom values should be specified in the script file, separate for each platform. In the current code script file for linux/s390x is proposed. - only tasks, which have mention about corresponding platform support in the annotation, will be tested. If PLATFORM env variale is no specified, the behaviour of test scripts will be similar to the one before the PR. Signed-off-by: Yulia Gaponenko <yulia.gaponenko1@de.ibm.com>

view details

push time in 19 days

PR opened tektoncd/catalog

Add platforms annotation to pylint 0.1 task

Changes

Annotation about linux/amd64, linux/s390x, linux/arm64 and linux/ppc64le platforms is added to the 0.1 version of the pylint task.

The task was tested for linux/amd64, linux/s390x, linux/ppc64le platforms. linux/arm64 platform was added to the list, because task image has linux/arm64 support.

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you review them:

  • [x] Follows the authoring recommendations
  • [x] Includes docs (if user facing)
  • [ ] Includes tests (if functionality of task changed or new task added)
  • [x] Commit messages follow commit message best practices
  • [ ] Complies with Catalog Organization TEP, see example. Note An issue has been filed to automate this validation
    • [ ] File path follows <kind>/<name>/<version>/name.yaml

    • [ ] Has README.md at <kind>/<name>/<version>/README.md

    • [ ] Has mandatory metadata.labels - app.kubernetes.io/version the same as the <version> of the resource

    • [ ] Has mandatory metadata.annotations tekton.dev/pipelines.minVersion

    • [ ] mandatory spec.description follows the convention

        ```
      
        spec:
          description: >-
            one line summary of the resource
      
            Paragraph(s) to describe the resource.
        ```
      

See the contribution guide for more details.


+5 -0

0 comment

2 changed files

pr created time in 20 days

create barnchbarthy1/catalog

branch : pylint_platforms

created branch time in 20 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 0bd7a308f8ac9a57fce58f90bd79acc2121f93e8

test circleci

view details

push time in 21 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha dc83de074bab0ace57b76ac4bdb9b30ada2f3cfc

test circleci

view details

push time in 21 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 75f9cf09e665f9ae10f5edd02e208f3cec82719c

test circleci

view details

push time in 21 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 86ebfd692cd5ec53b77dbd9b6d630a2211b2c77c

test circleci

view details

push time in 21 days

push eventbarthy1/cruise-control

Yulia Gaponenko

commit sha 113d8903d0730715c36b8c59325d0d7595cfdc08

test circleci

view details

push time in 21 days

more