text:
Creating a fileshare status is error, but looking at the database doesn't have such a fileshare

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:
/kind bug
/kind feature

What happened:
I created a fileshare and the staus is error. but looking at the database doesn't hvae such a fileshare.

What you expected to happen:
When the status of the fileshare created is error or the creation failed, the API needs to return the specific reason
How to reproduce it (as minimally and precisely as possible):
Create as many fileshare as possible, and it is easy to have error fileshare
Anything else we need to know?:
Environment:

Hotpot(release/branch) version:development branch
OS (e.g. from /etc/os-release): Ubuntu 16.04.2 LTS
Kernel (e.g. uname -a): Linux ubuntu 4.4.0-62-generic
Install tools:manually
Others: dashboard: development branch

as per @PravinRanjan10 , the db shows the error entry also currently.
(actually, this should be removed in case of error!;)
@jimccfun , please check this. Then close the issue!

authors: PravinRanjan10 jimccfun skdwriting

repo: opensds/opensds


text:
Create volume from snapshot

What this PR does / why we need it:
**BP Create_Volume_From_Snapshot.
Special notes for your reviewer:
This is to implement volume creation from snapshots.
Release note:

Users can create volumes from snapshots.

@leonwanghui Rebased on development branch.

It seems that the unit test is not right, please take a look

Hi @lixiaoy1  The API document should be updated which is located in opensds/openapi-spec/swagger.yaml.

Coverage increased (+0.06%) to 43.71% when pulling c15f09b73da56f0412fb7ea6a12143102a042621 on lixiaoy1:snapshot into c524172e8ca036bd948ba1b0a126126bc741db44 on opensds:development.

source: gharchive/pull-request

authors: coveralls leonwanghui lixiaoy1 wisererik

license_type: permissive

license_source: github-api


text:
Interactive change opacity of tilesource

I've positioned two tilesources on top of each other and can set variables for opacity of each.
I want to change the opacity of a tilesource via click on a button id, or even add a transition upon the click to fade the object in or out.
Code below and page here:  http://deepzoomchattanooga.com/theboulevard.php
In this case, when the button is clicked I want the tilesource's opacity set by the value of op2 to change from 1.0 to 0.2.
What am I missing?  Thank you.
<button id="pg01">Change Opacity</button></div>

var op1 = 0.6;
var op2 = 1.0;

$("#pg01").click(function (){
var op1 = 0.1;
});

var viewer = new OpenSeadragon.Viewer({
    id: "openseadragon-canvas",
    prefixUrl: "/openseadragon/images_TEST/",
    navigationControlAnchor: OpenSeadragon.ControlAnchor.TOP_RIGHT,
    showHomeControl: false,
    showZoomControl: false,

    tileSources: [{
            x: 0.883,
            y: 1,
            width: 1,
            opacity: op2,
            tileSource: "/zoom/boulevard1/dzc_output.xml",
        },

        {
            x: 1,
            y: 1,
            width: 0.61,
            opacity: op1,
            tileSource: "/zoom/boulevard4/dzc_output.xml"

        }
   ]

});

There are multiple issues with your code:

In the click handler, you are defining a new variable op1 which is local to that function.
To avoid that you should remove var and just have op1 = 0.1.

Even with the above fix, this code wouldn't work for 2 reasons:

javascript passes variables by value which means that even if you update op1, the opacity property in the tileSources array won't be updated
even if that value was updated by calling something like tileSources[1].opacity = op1;, OSD does not support updating the opacity this way.

So, what you should do is change your click handler like this:
$("#pg01").click(function (){
   viewer.world.getItemAt(1).setOpacity(0.1);
});

The viewer.world.getItemAt(1) call retrieves the tiledImage on top and setOpacity changes the opacity.
See the world and tiledImage documentations.

Antoine - Thank you for the solution and the details.
JavaScript is obviously not my strong point.  I tried many different attempts, and had actually at one time fixed issue #1 (the variable would show changed in the console) and narrowed the next part down to something that began with viewer.xxxx.
But alas, the API is a sea of possibilities and I look for / learn by examples vs. the API.
Your info will no doubt get me past the temporary block.
Thanks again,
Sam

Can you suggest a way to apply CSS transitions to the opacity change or does it all have to occur within the js?

It has to be in JS. You will need to look into requestAnimationFrame (you can use OpenSeadragon.requestAnimationFrame to handle the browser compatibility for you)

That's what I suspected.  Thanks again!

@SamHall Here is an example of some code for doing an opacity fade with OSD:
http://codepen.io/iangilman/pen/YXRLea

Fantastic! That's a great working example.
Question -
for setOpacity can the value be a variable set external to the script on the same page?
I'm thinking of using a data slider to allow interactive opacity.
Such as:  https://github.com/loopj/jquery-simple-slider
viewer.world.getItemAt(1).setOpacity('variable and or ID');
I'll experiment...
Thanks again.
Sam

You can and we have an example for using the jQuery UI slider to set the rotation here: http://openseadragon.github.io/examples/ui-rotation/
For opacity it would be:
$("#slider").slider({
    min: 0,
    max: 100,
    slide: function(event, ui) {
        viewer.world.getItemAt(1).setOpacity(ui.value / 100);
    }
});

Opacity slider works!
Now to finish the content.
Thanks again for the fast responses.
http://deepzoomchattanooga.com/theboulevard.php

@SamHall Beautiful page! I love this idea of fading into the future/past. Really cool.

source: gharchive/issue

authors: SamHall avandecreme iangilman

repo: openseadragon/openseadragon

license_source: bigquery


text:
Metricbeat is unable to connect to AWS OpenSearch service. ERROR 401 Unauthorized

Describe the bug
Metricbeat running on EC2 is failing with error: unable to connect to AWS OpenSearch service. ERROR 401 Unauthorized
My openSearch domain enabled fine-grain access control(FGAC) with IAM role as master user.
I have the access policy attached to EC2 IAM role already and mapped the opensearch role "all_access"  so it should reach the domain endpoint. However, this is not working.
Related component
Other
To Reproduce

Create AWS OpenSearch domain and enable FGAC.
Create an EC2 instance and attach the IAM policy to allow access to opensearch domain created above.

"Effect": "Allow",
"Action": [
    "es:*"
 ],
 "Resource": [
     "<domainarn>"
]

Update opensearch domain access policy as below.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "es:*"
      ],
      "Resource": "<domain_arn>"
    }
  ]
}

Install metricbeat-oss7.12.1 on EC2 instance and configure to push metrics to opensearch domain endpoint.

You'll receive error as stated above when running metricbeat.
Expected behavior
Metricbeat should be able to push metrics to opensearch endpoint.
Additional Details
Host/Environment (please complete the following information):

OS: Windows

Metricbeat is maintained by Elastic. It looks like someone raised a similar issue for filebeat here: https://github.com/elastic/beats/issues/31613. Maybe you could raise a similar issue?

[Triage - attendees 1 2 3 4 5]
@nagachinni Thanks for creating this issue; however, it isn't being accepted due to being out of scope for this project, please reach out through support channels with your hosting provider to troubleshoot.

authors: nagachinni peternied wbeckler

repo: opensearch-project/OpenSearch


text:
[BUG] Unable to apply search_backpressure cluster settings

Describe the bug
Attempting to apply search_backpressure.search_shard_task.cancellation_burst or search_backpressure.search_task.cancellation_burst settings results in the cluster manager getting stuck in a loop emitting an error that says "java.lang.IllegalArgumentException: rate must be greater than zero".
Related component
Search
To Reproduce
Download the OpenSearch 2.17 min distribution tarball, extract it, then launch the process with ./bin/opensearch. Send the following command:
PUT {{endpoint}}/_cluster/settings
{
    "persistent" :{
        "search_backpressure.search_shard_task.cancellation_burst": 5.0,
        "search_backpressure.search_task.cancellation_burst": 5.0
    },
    "transient" :{
        "search_backpressure.search_shard_task.cancellation_burst": 5.0,
        "search_backpressure.search_task.cancellation_burst": 5.0
    }
}

The cluster manager gets stuck in a loop continually printing the following error:
[2024-10-22T17:04:48,028][WARN ][o.o.c.s.ClusterApplierService] [ip-172-31-30-74] failed to apply updated cluster state in [0s]:
version [12], uuid [Ijs3Brl0S-iEtMlifjtcmA], source [becoming candidate: clusterApplier#onNewClusterState]
org.opensearch.OpenSearchException: java.lang.IllegalArgumentException: rate must be greater than zero
        at org.opensearch.ExceptionsHelper.maybeThrowRuntimeAndSuppress(ExceptionsHelper.java:209) ~[opensearch-core-2.17.0.jar:2.17.0]                                                                                at org.opensearch.search.backpressure.settings.SearchShardTaskSettings.notifyListeners(SearchShardTaskSettings.java:270) ~[opensearch-2.17.0.jar:2.17.0]                                                              at org.opensearch.search.backpressure.settings.SearchShardTaskSettings.setCancellationBurst(SearchShardTaskSettings.java:252) ~[opensearch-2.17.0.jar:2.17.0]                                                         at org.opensearch.common.settings.Setting$Updater.apply(Setting.java:1257) ~[opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.common.settings.AbstractScopedSettings$SettingUpdater.lambda$updater$0(AbstractScopedSettings.java:696) ~[opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.common.settings.AbstractScopedSettings.applySettings(AbstractScopedSettings.java:232) ~[opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.cluster.service.ClusterApplierService.applyChanges(ClusterApplierService.java:575) ~[opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.cluster.service.ClusterApplierService.runTask(ClusterApplierService.java:503) [opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.cluster.service.ClusterApplierService$UpdateTask.run(ClusterApplierService.java:205) [opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:946) [opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.common.util.concurrent.PrioritizedOpenSearchThreadPoolExecutor$TieBreakingPrioritizedRunnable.runAndClean(PrioritizedOpenSearchThreadPoolExecutor.java:283) [opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.common.util.concurrent.PrioritizedOpenSearchThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedOpenSearchThreadPoolExecutor.java:246) [opensearch-2.17.0.jar:2.17.0]
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) [?:?]
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) [?:?]                                                                                at java.base/java.lang.Thread.run(Thread.java:1583) [?:?]                                                                                Caused by: java.lang.IllegalArgumentException: rate must be greater than zero                                                                                at org.opensearch.common.util.TokenBucket.<init>(TokenBucket.java:52) ~[opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.common.util.TokenBucket.<init>(TokenBucket.java:47) ~[opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.search.backpressure.SearchBackpressureState.onRateChanged(SearchBackpressureState.java:95) ~[opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.search.backpressure.SearchBackpressureState.onBurstChanged(SearchBackpressureState.java:101) ~[opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.search.backpressure.settings.SearchShardTaskSettings.lambda$setCancellationBurst$2(SearchShardTaskSettings.java:252) ~[opensearch-2.17.0.jar:2.17.0]
        at org.opensearch.search.backpressure.settings.SearchShardTaskSettings.notifyListeners(SearchShardTaskSettings.java:264) ~[opensearch-2.17.0.jar:2.17.0]
        ... 13 more

Expected behavior
Settings are applied without error.
Additional Details
No response

When attempting to reproduce this in a dev environment using ./gradlew run, it succeeds on the main branch. However, it fails on the 2.x branch:
» [2024-10-22T17:46:55,088][INFO ][o.o.c.s.ClusterSettings  ] [runTask-0] updating [search_backpressure.search_shard_task.cancellation_burst] from [10.0] to [5.0]
» [2024-10-22T17:46:55.523192795Z] [BUILD] Stopping node

=== Standard error of node `node{::runTask-0}` ===
»   ↓ last 40 non error or warning messages from /home/ubuntu/OpenSearch-2.x/build/testclusters/runTask-0/logs/opensearch.stderr.log ↓
» WARNING: Using incubator modules: jdk.incubator.vector
»  WARNING: A terminally deprecated method in java.lang.System has been called
»  WARNING: System::setSecurityManager has been called by org.opensearch.bootstrap.OpenSearch (file:/home/ubuntu/OpenSearch-2.x/distribution/archives/linux-arm64-tar/build/install/opensearch-2.18.0-SNAPSHOT/lib/opensearch-2.18.0-SNAPSHOT.jar)
»  WARNING: Please consider reporting this to the maintainers of org.opensearch.bootstrap.OpenSearch
»  WARNING: System::setSecurityManager will be removed in a future release
»  Oct 22, 2024 5:46:43 PM sun.util.locale.provider.LocaleProviderAdapter <clinit>
»  WARNING: COMPAT locale provider will be removed in a future release
»  WARNING: A terminally deprecated method in java.lang.System has been called
»  WARNING: System::setSecurityManager has been called by org.opensearch.bootstrap.Security (file:/home/ubuntu/OpenSearch-2.x/distribution/archives/linux-arm64-tar/build/install/opensearch-2.18.0-SNAPSHOT/lib/opensearch-2.18.0-SNAPSHOT.jar)
»  WARNING: Please consider reporting this to the maintainers of org.opensearch.bootstrap.Security
»  WARNING: System::setSecurityManager will be removed in a future release
»  fatal error in thread [opensearch[runTask-0][clusterApplierService#updateTask][T#1]], exiting
»  java.lang.AssertionError
»       at org.opensearch.cluster.service.ClusterApplierService.runTask(ClusterApplierService.java:542)
»       at org.opensearch.cluster.service.ClusterApplierService$UpdateTask.run(ClusterApplierService.java:205)
»       at org.opensearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:946)
»       at org.opensearch.common.util.concurrent.PrioritizedOpenSearchThreadPoolExecutor$TieBreakingPrioritizedRunnable.runAndClean(PrioritizedOpenSearchThreadPoolExecutor.java:283)
»       at org.opensearch.common.util.concurrent.PrioritizedOpenSearchThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedOpenSearchThreadPoolExecutor.java:246)
»       at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
»       at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
»       at java.base/java.lang.Thread.run(Thread.java:1583)

I think this issue was fixed by #15501
It looks like it has been backported but I think I was able to reproduce the problem on the 2.x branch as of today.

I had a stale commit on the 2.x branch I was testing against. Confirmed #15501 does in fact fix this issue. Resolving.


text:
[BUG] OpenID certificate improperly validated causing 401 Unauthorized due to openjdk bug

Describe the bug
If you have an OpenID provider that is using a certificate which contains at least one nameConstraint with a leading . (likely in the issuer chain rather than the leaf certificate), then java will fail to validate the certificate and OpenID authorization in OpenSearch will fail, returning 401 Unauthorized.
I have been troubleshooting this issue for more than a week and read through dozens of conversations where people report OpenID authorization issues with OpenSearch, many of which were never fully resolved. In some cases, the same configuration appears to work for some users but not others. With sufficient logging enabled (see replication below) there are two stack traces that appeared for me. Most conversations report similar certificate path validation exceptions, but that is the second stack trace in this case. The earlier exception that gives this case away is: CertPathValidatorException: name constraints check failed.
In my case I have an internal certificate authority for the internal domain, and have cert-manager configured as an intermediate authority for the app.internal domain with a nameConstraint of DNS:.app.internal. That then gets issued to the ingress/gateway/proxy that sits in front of a KeyCloak instance at sso.app.internal. Setting the openid_connect_url value to https://sso.app.internal/realms/internal/.well-known/openid-configuration and configuring opensearch-dashboards to use the same provider results in the dashboards correctly redirecting, but receiving a 401 Unauthorized after being redirected back from the OpenID login.
I verified that the internal users, roles, and role mappings were all configured correctly, that the certificate authority certificates were provided correctly in the configuration, and dozens of other suggestions. The single change that enabled OpenID to work correctly was to reissue the intermediate authority certificate without the nameConstraint and then reissue the KeyCloak certificate. SSO started working without needing any changes to OpenSearch once the certificate was deployed to KeyCloak.
Related component
Build
To Reproduce

Configure an OIDC provider with a HTTPS certificate that contains at least one nameConstraints with a leading . such as DNS:.example.com in the issuer chain (detailed instructions in the upstream fix)
Configure OpenSearch to use the provider with openid_connect_url
Attempt to log in using OpenID
Receive 401 Unauthorized

Additionally, you can configure log4j2.properties to see more details from the cluster:
status = error
appender.console.type = Console
appender.console.name = console
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = [%d{ISO8601}][%-5p][%-25c{1.}] [%node_name]%marker %m%n
rootLogger.level = info
rootLogger.appenderRef.console.ref = console
logger.securityjwt.name = com.amazon.dlic.auth.http.jwt
logger.securityjwt.level = trace

And you should see at least one stack trace (I usually see 2 for each failed log in), the first includes the error CertPathValidatorException: name constraints check failed. I unfortunately don't have a full copy of this any more.
Expected behavior
Users from OpenID providers hosted with certificates containing nameConstraints in any part of the issuer chain should be able to authenticate with OpenSearch.
Additional Details
Additional context
This is an issue with upstream openjdk that has been fixed and backported to to 22+. The container images for OpenSearch 2.17.1 indicate the openjdk 21.0.4 is bundled, which does not contain the fix.
What needs to happen now?
This will continue to be an issue until a patched openjdk is bundled with OpenSearch. In the meantime, hopefully this bug appears in search results for others hitting the same issue so they don't have to spend days troubleshooting it.

[Catch All Triage - 1, 2, 3, 4, 5]

authors: cyanidium dblock


text:
[BUG] Upgrading from OpenSearch 1.3 to 2.5 causes monitor names to disappear from UI

What is the bug?
Upgrading from OpenSearch 1.3 to 2.5 causes monitor names to disappear from UI(or show as null).
How can one reproduce the bug?
Steps to reproduce the behavior:

Go to 'List monitors'
See error - name is null or not shown
Select the monitor & click on Edit
Name shows correctly

What is the expected behavior?
the Monitor list should show names of all monitors correctly.
What is your host/environment?

OS: [e.g. iOS]
Version 2.5
Plugins

Closing in favor of https://github.com/opensearch-project/alerting/issues/1030

repo: opensearch-project/alerting


text:
[BUG] UI Bug on Actions input under a Trigger

What is the bug?
When typing in the actions message box on Microsoft Edge on a monitor, after typing a letter the cursor moves to the message subject field label and you can no longer type without clicking on the message box again.
How can one reproduce the bug?
Steps to reproduce the behavior:

Create a new monitor or edit an existing monitor
Fill out all options, and create a new action
With the action open, type into the message textbox
after typing a letter the cursor will bounce to the message subject label.

What is the expected behavior?
You should be able to type in the message box continuously without the cursor leaving the box.
What is your host/environment?

OS: AWS Opensearch Service / OpenSearch_2_11_R20231113-P2 (latest)
Version: v2.11.0
Plugins:  Alerting plugin in this case
Since it seems like a UI issue, I've seen the behavior on Microsoft Edge version 120.0.2210.167 and Google Chrome version 119.0.6045.160

Do you have any screenshots?
See before screenshot

After typing a letter:

This may be related to this issue: https://github.com/opensearch-project/alerting-dashboards-plugin/issues/785

Closing as issue was fixed with https://github.com/opensearch-project/alerting-dashboards-plugin/issues/785

authors: AWSHurneyt kgcreative melegar


text:
Added layer for creating and updating the workflow

Issue #, if available:
Description of changes:
Added transport layer for creating/updating of the workflows and appropriate integration tests
CheckList:
[ ] Commits are signed per the DCO using --signoff
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Can you share the integ test runs in here to add confidence on things working?

Can you share the integ test runs in here to add confidence on things working?

I think I added. Here is the integ-test file

Can you share the integ test runs in here to add confidence on things working?

Sorry didn't understood you correctly :) will attach the test results

TEST-org.opensearch.alerting.WorkflowMonitorIT.txt

did you add integ tests to verify  user permissions on workflow creation?

did you add integ tests to verify user permissions on workflow creation?

No i didn't. I checked a code (how we are doing the Secure*** tests in SecureMonitorRestApiIT -> we are dependent on the restClient while we have only transportLayer for the time being (when we are talking about the Workflows).
Do you know if we have some base test class or some class in alerting that enables us to add a roles to a client() object used in OpenSearchSingleNodeTestCase? Something like we have SecureRestClientBuilder? If we have that I can see how to add a roles and do a proper security check. I didn't manage to find it in a code.

https://github.com/opensearch-project/alerting/issues/834

authors: eirsep lezzago stevanbz


text:
Fix spelling or word in warning

Description
[Describe what this change achieves]
A very small change to fix the spelling of the word "not" in the following warning. I noticed this while attempting to train a detector.

There is not enough data to train model

Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@danotorrey thanks for the fix! This repository enforces a DCO check, can you re-commit with the -s flag to sign off on your commit? More details in the contributing guide here

Codecov Report

Merging #407 (a7243de) into main (3c6ffa2) will decrease coverage by 0.17%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##               main     #407      +/-   ##
============================================
- Coverage     77.79%   77.62%   -0.18%
+ Complexity     4114     4106       -8
============================================
  Files           296      296
  Lines         17644    17644
  Branches       1876     1876
============================================
- Hits          13726    13696      -30
- Misses         3019     3045      +26
- Partials        899      903       +4

Flag
Coverage Δ

plugin
77.62% <100.00%> (-0.18%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...java/org/opensearch/ad/task/ADBatchTaskRunner.java
81.76% <100.00%> (ø)

...port/SearchAnomalyDetectorInfoTransportAction.java
64.44% <0.00%> (-4.45%)
:arrow_down:

...g/opensearch/ad/model/DetectorValidationIssue.java
64.91% <0.00%> (-3.51%)
:arrow_down:

...rch/ad/transport/ForwardADTaskTransportAction.java
94.06% <0.00%> (-3.39%)
:arrow_down:

...ain/java/org/opensearch/ad/model/ModelProfile.java
70.90% <0.00%> (-1.82%)
:arrow_down:

...ain/java/org/opensearch/ad/task/ADTaskManager.java
75.69% <0.00%> (-1.21%)
:arrow_down:

...rch/ad/transport/AnomalyResultTransportAction.java
80.18% <0.00%> (-0.69%)
:arrow_down:

.../main/java/org/opensearch/ad/ml/CheckpointDao.java
69.55% <0.00%> (-0.65%)
:arrow_down:

@ohltyler Done.

authors: codecov-commenter danotorrey ohltyler

repo: opensearch-project/anomaly-detection


text:
[BUG] Adding unicode or emoji to header or footer doesn't render.

Describe the bug
Unicode entered as markdown content is rendered as empty rectangles in resulting PDF.
To Reproduce
Steps to reproduce the behavior:

Create a report
Add visualization, etc.
Click "add header"
In the header add some emoji or high unicode (I used "🤷♂ m̩ n̩ l̩ 🤦♂") - they show up properly in the "preview"
Download the report and see the empty rectangles (see screen shot)

Expected behavior
Character render properly as in preview
Plugins
All OpenSearch plugins
Screenshots

Host/Environment (please complete the following information):

OS: MacOs
Version Chrome / 90.0.4430.212 (Official Build) (x86_64)
OpenSearch 1.0-RC1

Added workaround with font package installation recommendations- will also track effort to auto-install popular font dependencies

repo: opensearch-project/dashboards-reports


text:
[BUG][OpenSearch] Cluster-Manager discovery not working

Describe the bug
I tried to deploy a simple OpenSearch cluster with the provided helm charts in our k8s (1.26) with helm (3.13.1). As soon as I increase the number of replicas for a cluster-manager/master from 1 to 2 or 3 the cluster does not start successfully.
I had to make a few adjustments in the values.yaml (i.e. providing the url of our private imageregistry and a corresponding imagepullsecret). For all other values default values are used.
To Reproduce
Steps to reproduce the behavior:

clone this repository
open values.yaml from charts/opensearch
change global.registry to private registry
add image pull secret to imagePullSecrets
deploy via helm upgrade opensearch ./charts/opensearch --install

Expected behavior
OpenSearch is starting without errors and the request to verify OpenSearch installation as described here is successful.
Chart Name
Specify the Chart which is affected?
OpenSearch
Screenshots
If applicable, add screenshots to help explain your problem.
Host/Environment (please complete the following information):

Helm Version: 3.13.1
Kubernetes Version: 1.26.7

Additional context
Add any other context about the problem here.
If I try to run the helm chart with replicas set to 1, everything is setup as I would expect. But as soon as I increase number of replicas to 2 or 3 (3 is default from initial clone) I am getting the following exception:
org.opensearch.discovery.ClusterManagerNotDiscoveredException: null
	at org.opensearch.action.support.clustermanager.TransportClusterManagerNodeAction$AsyncSingleAction$2.onTimeout(TransportClusterManagerNodeAction.java:350) [opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.cluster.ClusterStateObserver$ContextPreservingListener.onTimeout(ClusterStateObserver.java:394) [opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.cluster.ClusterStateObserver$ObserverClusterStateListener.onTimeout(ClusterStateObserver.java:294) [opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.cluster.service.ClusterApplierService$NotifyTimeout.run(ClusterApplierService.java:707) [opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:849) [opensearch-2.11.0.jar:2.11.0]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
	at java.lang.Thread.run(Thread.java:833) [?:?]
[2023-11-23T13:39:57,962][ERROR][o.o.b.OpenSearchUncaughtExceptionHandler] [opensearch-cluster-master-0] uncaught exception in thread [main]
org.opensearch.bootstrap.StartupException: ClusterManagerNotDiscoveredException[null]
	at org.opensearch.bootstrap.OpenSearch.init(OpenSearch.java:184) ~[opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.bootstrap.OpenSearch.execute(OpenSearch.java:171) ~[opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:104) ~[opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.cli.Command.mainWithoutErrorHandling(Command.java:138) ~[opensearch-cli-2.11.0.jar:2.11.0]
	at org.opensearch.cli.Command.main(Command.java:101) ~[opensearch-cli-2.11.0.jar:2.11.0]
	at org.opensearch.bootstrap.OpenSearch.main(OpenSearch.java:137) ~[opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.bootstrap.OpenSearch.main(OpenSearch.java:103) ~[opensearch-2.11.0.jar:2.11.0]
Caused by: org.opensearch.discovery.ClusterManagerNotDiscoveredException
	at org.opensearch.action.support.clustermanager.TransportClusterManagerNodeAction$AsyncSingleAction$2.onTimeout(TransportClusterManagerNodeAction.java:350) ~[opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.cluster.ClusterStateObserver$ContextPreservingListener.onTimeout(ClusterStateObserver.java:394) ~[opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.cluster.ClusterStateObserver$ObserverClusterStateListener.onTimeout(ClusterStateObserver.java:294) ~[opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.cluster.service.ClusterApplierService$NotifyTimeout.run(ClusterApplierService.java:707) ~[opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:849) ~[opensearch-2.11.0.jar:2.11.0]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
	at java.lang.Thread.run(Thread.java:833) [?:?]
uncaught exception in thread [main]
ClusterManagerNotDiscoveredException[null]
	at org.opensearch.action.support.clustermanager.TransportClusterManagerNodeAction$AsyncSingleAction$2.onTimeout(TransportClusterManagerNodeAction.java:350)
	at org.opensearch.cluster.ClusterStateObserver$ContextPreservingListener.onTimeout(ClusterStateObserver.java:394)
	at org.opensearch.cluster.ClusterStateObserver$ObserverClusterStateListener.onTimeout(ClusterStateObserver.java:294)
	at org.opensearch.cluster.service.ClusterApplierService$NotifyTimeout.run(ClusterApplierService.java:707)
	at org.opensearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:849)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)

When turning on trace logs I'm also facing the following:
[2023-11-24T08:11:40,318][TRACE][o.o.d.PeerFinder         ] [opensearch-cluster-master-0] startProbe(192.168.128.139:9300) not probing local node
[2023-11-24T08:11:40,319][TRACE][o.o.d.SeedHostsResolver  ] [opensearch-cluster-master-0] resolved host [opensearch-cluster-master-headless] to [192.168.128.139:9300, 192.168.129.236:9300]
[2023-11-24T08:11:40,319][TRACE][o.o.d.PeerFinder         ] [opensearch-cluster-master-0] probing resolved transport addresses [192.168.129.236:9300]
[2023-11-24T08:11:40,350][DEBUG][o.o.d.PeerFinder         ] [opensearch-cluster-master-0] Peer{transportAddress=192.168.129.236:9300, discoveryNode=null, peersRequestInFlight=false} connection failed
org.opensearch.transport.ConnectTransportException: [][192.168.129.236:9300] connect_timeout[3s]
	at org.opensearch.transport.TcpTransport$ChannelsConnectedListener.onTimeout(TcpTransport.java:1083) ~[opensearch-2.11.0.jar:2.11.0]
	at org.opensearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:849) ~[opensearch-2.11.0.jar:2.11.0]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
	at java.lang.Thread.run(Thread.java:833) [?:?]
[2023-11-24T08:11:41,319][TRACE][o.o.d.PeerFinder         ] [opensearch-cluster-master-0] probing cluster-manager nodes from cluster state: nodes:
   {opensearch-cluster-master-0}{6ln17rDKRuS80Z40Rmt8Og}{ibQZHrlmQ_SFaIIVNythJQ}{192.168.128.139}{192.168.128.139:9300}{dimr}{shard_indexing_pressure_enabled=true}, local

It seems like the pods can find themselves as cluster-manager, but as soon as they have to peer with/discover the other cluster-manager pods, they cannot find them. If I exec into a pod and try to call the IP of one of the other pods with curl, there is also a timeout.
I'm working on a clean namespace, so there is no networkpolicy deployed. The only thing deployed apart from the helm charts is the secret to pull the images from the private registry.

closing this issue as this has nothing to do with helm charts, but with the network configurations of the managed k8s cluster. sorry for any inconvenience caused.

repo: opensearch-project/helm-charts


text:
[BUG] Policy Managed Indices Table Overflow

What is the bug?
A clear and concise description of the bug.
How can one reproduce the bug?
Steps to reproduce the behavior:

Go to to the hamburger menu on the left side
Click on Index Management underneath Management
Click on Policy Managed Indices and inspect page
Shrink page to <1270px x 1000px (the length of the page doesnt really matter too much)
If you have no policies, the table overflows the div

What is the expected behavior?
It should be confined within the element
What is your host/environment?

OS: Chrome
Version 121.0.6167.139
Plugins

Do you have any screenshots?

Do you have any additional context?
Editing the Table-Layout or Width also effects Indices
This does not effect State Management Policies or other tables, just Policy Managed Indicies

Catch All Triage - 1 2 3 4 5

repo: opensearch-project/index-management


text:
[release]: Data Prepper 2.3.0

Did you read the on-boarding document
Yes.
What is the name of your component?
Data Prepper
What is the link to your GitHub repo?
https://github.com/opensearch-project/data-prepper
Targeted release date
May 31, 2023
Where should we publish this component?
This is already scripted
What type of artifact(s) will be generated for this component?

Docker/ECR image
tar.gz archive
Maven artifacts

Have you completed the required reviews including security reviews, UX reviews?
Some are still in progress.
Have you on-boarded automated security scanning for the GitHub repo associated with this component?
Yes.
Additional context
Data Prepper builds artifacts using GitHub Actions. This will publish to staging repositories. Our team is responsible for this portion. We will need the opensearch-build team to run the Jenkins job which promotes these to production.
A Data Prepper maintainer will supply the DATA_PREPPER_BUILD_NUMBER parameter when it is time to release.
Parameters:
VERSION: 2.3.0
RELEASE_MAJOR_TAG: true
RELEASE_LATEST_TAG: true
DATA_PREPPER_BUILD_NUMBER - To be supplied later

@dlvenable Its high time we automate the release process for Data prepper to avoid any delay in releasing the artifacts due to resourcing bottlenecks. Can we work together and see if we can automate it for this release?

[Triage] @dlvenable @bbarani Can you update the current status for this?

@zelinh , We are planning to release this on Jun 06, 2023. We will still need support from the this project to manually kick off the Jenkins job.

VERSION: 2.3.0
RELEASE_MAJOR_TAG: true
RELEASE_LATEST_TAG: true
DATA_PREPPER_BUILD_NUMBER - 57

Jenkins build to trigger the release:
https://build.ci.opensearch.org/job/release-data-prepper-all-artifacts/
Docker:
2.3.0, 2
ECR:
2.3.0, 2
Sonatype Release Repo
2.3.0

Closing this issue as 2.3.0 is out.

authors: asifsmohammed bbarani dlvenable gaiksaya prudhvigodithi zelinh

repo: opensearch-project/opensearch-build


text:
Create github issue on distribution build job failure

Signed-off-by: Rishabh Singh sngri@amazon.com
Description
This PR adds capability to add github issue to component repository in case of distribution build job failure for each failing coponent. A new issue is added for each component version failure and in case an issue already exists for a particular component version then issue creation is skipped to avoid creating duplicate issues.
Issues Resolved
#1899
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #2448 (6c3a206) into main (856b691) will increase coverage by 5.36%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##               main     #2448      +/-   ##
=============================================
+ Coverage     94.63%   100.00%   +5.36%
=============================================
  Files           211         6     -205
  Lines          4322       105    -4217
  Branches         29        19      -10
=============================================
- Hits           4090       105    -3985
+ Misses          226         0     -226
+ Partials          6         0       -6

Impacted Files
Coverage Δ

src/build_workflow/builder_from_source.py

src/ci_workflow/ci_check_list_dist.py

...workflow/ci_check_gradle_publish_to_maven_local.py

...w/bwc_test/bwc_test_start_properties_opensearch.py

...rc/test_workflow/test_result/test_suite_results.py

...enkins/jobs/BuildDockerImage_Qualifier_Jenkinsfile

tests/jenkins/jobs/Hello_Jenkinsfile

src/test_workflow/integ_test/local_test_cluster.py

src/ci_workflow/ci_check_list_source.py

src/test_workflow/perf_test/perf_test_runner.py

... and 195 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


text:
Update devtoolset to v8 for CentOS7/Node16 upgrade

Description
Update devtoolset to v8 for CentOS7/Node16 upgrade
Issues Resolved
#3434
https://github.com/opensearch-project/opensearch-build/issues/1563#issuecomment-1570602985
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Also improved the python make process and reduced compile time.

https://build.ci.opensearch.org/job/docker-build/3445/console

https://build.ci.opensearch.org/job/docker-copy/507/console


text:
Add missing items to the response body in guides/bulk.md

Description
Describe what this change achieves.
Issues Resolved
List any issues this PR will resolve, e.g. Closes [...].
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] Linter check was successfull - yarn run lint doesn't show any errors
[ ] Commits are signed per the DCO using --signoff
[ ] Changelog was updated.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

We had similar problems in guides, so we started adding working samples into https://github.com/opensearch-project/opensearch-js/tree/main/samples. Do you want to extract this code into a working sample and reference it? This way we know the code works 100%.

Thanks for the review, yep I think I can do this over the weekend, do you know any example how samples added to the guides? Just for wordings

We had similar problems in guides, so we started adding working samples into https://github.com/opensearch-project/opensearch-js/tree/main/samples. Do you want to extract this code into a working sample and reference it? This way we know the code works 100%.

Thanks for the review, yep I think I can do this over the weekend, do you know any example how samples added to the guides? Just for wordings

It's all over the place, e.g. https://github.com/opensearch-project/opensearch-js/blob/4e615f3d38bfc149fd94d3009ca824b4f6a3b862/guides/search.md#search references a sample file. I am happy with anything that links to it.
Someone will go edit all the docs, write all the samples, and make it awesome. Wink wink :)

The guide has been reworked. Please check if this change is still needed anymore or if you wanna make other updates to it :)

Thanks @nhtruong, I don't think this is needed anymore.

authors: ap-h dblock nhtruong

repo: opensearch-project/opensearch-js


text:
Test and publish compatibility matrix with various OpenSearch versions

Add support to run integration tests across various versions of OpenSearch and publish a compatibility matrix for the client version vs OpenSearch version.
PR Reference: https://github.com/opensearch-project/opensearch-java/pull/122
Compatibility: https://github.com/opensearch-project/opensearch-java/blob/main/COMPATIBILITY.md

Done in #146

repo: opensearch-project/opensearch-py


text:
Add override for code generator to change indices.put_alias argument order

Description
This solves an issue introduced in v2.7.0 where the argument order of the indices.put_alias() method were altered, resulting in a breaking change for any user that called the function without naming the arguments provided.
Issues Resolved
Closes #803.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@Tenzer did you happen to go through a diff of other APIs that might have this problem? Maybe there's a way to do this systematically 🤔  I want to double check before cutting a newer release.

@dblock this is interesting, post is exposed but doesn't really consume any body for the request.
https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/rest/DashboardsInfoAction.java#L94
We only seem to be using get request:
https://github.com/opensearch-project/security-dashboards-plugin/blob/main/server/routes/index.ts#L584
https://github.com/opensearch-project/security-dashboards-plugin/blob/main/public/utils/dashboards-info-utils.tsx#L21-L34
Also, could you point the exact line change for post_dashboards_info that might be causing this. https://github.com/opensearch-project/opensearch-py/compare/v2.6.0...v2.7.0#diff-d373e8c1b532ced908538444607c89e5a80cfe7a24ef5c81a3708e0fb2cf48fdL2173 doesn't seem to match any text when searching for "dashboards_info". Maybe I missed something?

@DarshitChanpura Thanks. I think we're all good, since this method doesn't take a body it was a bug fix.
I am sure where this is evaluated in the client code generator, but you can dig through https://github.com/opensearch-project/opensearch-py/blob/main/utils/generate_api.py.

authors: DarshitChanpura Tenzer dblock


text:
[FEATURE] Modify integration tests to run with OpenSearch Serverless

Is your feature request related to a problem?
Currently, integration tests are implemented to run with OpenSearch server running in docker.
As we want to make Flint compatible with OpenSearch Serverless, we should make integration tests be able to run against Serverless so that we can verify its functionality easily.
What solution would you like?
We need following changes

Mock metadata storage since we don't store them to serverless (otherwise, we need to come up a way to avoid issues caused due to WAIT_FOR refresh policy not supported)
Modify FlintSparkSuite and OpenSearchSuite to switch the OpenSearch to serverless collectio (Since we cannot run serverless within docker, we might not be able to run tests in Github workflow)
Fix verification method to not depend on queryIndex

OpenSearch Serverless does not provide stats API, and usage of DataFrame causes issue due to it. (Another approach is eliminating the usage of stats API)

What alternatives have you considered?
n/a
Do you have any additional context?
n/a

Looks like you want to run open source tests against a vendor-specific distribution.
We definitely want to continue running tests here against dockerized open-source OpenSearch.
For vendor-specific features we do have some precedent. There's an issue for running tests against vendor-specific distributions or instances in https://github.com/opensearch-project/opensearch-clients/issues/47 for SigV4.
One thing to be mindful of is that blocking PRs because of a vendor-specific solution being broken doesn't seem right.
[Catch All Triage - 1, 2, 3, 4]

@ykmr1224 thanks for the Feature request!
I am alarmed at the possibility that the vendor-neutral project will be tied down in any way by a vendor-specific one.
The following scenario is what i am afraid of -

Contributor wishes to make changes to opensearch-spark
Works on code and submits a PR
PR fails tests. Changes are required in OpenSearch Core (open source) and OpenSearch Serverless (closed source)
Changes are made to Core (now the feature is compatible with the open-source project)
PR still fails tests because the change breaks when running on OpenSearch Serverless
Contributor must ask folks maintaining OpenSearch Serverless to make changes in their code
Feature is stuck until vendor makes changes (IF they agree to the changes)

This enables the vendor to take control of large portions of open-source code de facto. @ykmr1224 @dblock I am curious if there are positive precedents for this type of dependency out there.
This may not be 100% true for this feature, but could be the case for other vendor-owned integrations, or might start to happen once we open the possibility and push a gray line further and further.

Opened up https://github.com/opensearch-project/.github/issues/229 to discuss the issue at large

As mentioned above, this issue opensearch-project/.github#229 discusses a better structure. Until that is achieved, there may still be desire to run tests against Spark EMR. This should be a stop gap measure until the OpenSearch Serverless release is better aligned with the OSS release.
With some initial testing, I was able to run SQL queries against the Spark EMR docker image.
https://gallery.ecr.aws/emr-serverless/spark/emr-7.2.0
Here is what I needed to do:

Create a directory to hold logging configuration. This really just needs two specific shell scripts. In my testing, these were empty shell scripts.

run-adot-collector.sh
run-fluentd-spark.sh

Create a directory that holds the Spark app
Get a local copy of the /etc/spark/conf directory from the Spark EMR Docker image.
Add this line to the end of the file spark-defaults.confspark.sql.legacy.createHiveTableByDefault false

Finally run the docker imagedocker run \
    --name emr \
    -v ./spark-logging:/var/loggingConfiguration/spark \
    -v ./app:/app \
    -v ./conf:/etc/spark/conf \
    public.ecr.aws/emr-serverless/spark/emr-7.2.0:20241022 \
    driver \
    --class MyApp \
    /app/myapp_2.12-1.0.jar

This is a serverless image, so it will quickly run and then exit. I tested with a Scala app for Spark.
There is still a step missing for including the OpenSearch PPL extension.

Another consideration is how to actually run tests on the docker image. I have a proposal:
Structure the tests with several files:

Data files
Setup queries
PPL query
Expected results

Create a Spark app. It can do some initial setup, such as creating tables. For each test:

Run the setup queries for the test
Run the PPL query
Write the results to a JSON file that is on a mounted volume of the docker image

After the Spark app finishes, go over each test and verify that the expected results match the actual results.
This means that there will be two components for running the tests:

A test running that is running on the host machine and can be started from the SBT build
A Spark app that runs the queries and captures the results for each of the tests

Create a Spark app. It can do some initial setup, such as creating tables. For each test:

@normanj-bitquill thanks for the suggestions
I agree we need a dedicated spark job to run the test and create a report regarding the success and performance of the tests being executed.
In addition I was hoping for using OpenSearch's Dashboard workbench PPL via a Spark data-source to access a local docker spark cluster which is running the Flint job - can you experiment if this is achievable ? and what are the prerequisites for this ?

As mentioned above, this issue opensearch-project/.github#229 discusses a better structure. Until that is achieved, there may still be desire to run tests against Spark EMR. This should be a stop gap measure until the OpenSearch Serverless release is better aligned with the OSS release.
With some initial testing, I was able to run SQL queries against the Spark EMR docker image. https://gallery.ecr.aws/emr-serverless/spark/emr-7.2.0
Here is what I needed to do:

Create a directory to hold logging configuration. This really just needs two specific shell scripts. In my testing, these were empty shell scripts.

run-adot-collector.sh
run-fluentd-spark.sh

Create a directory that holds the Spark app

Get a local copy of the /etc/spark/conf directory from the Spark EMR Docker image.

Add this line to the end of the file spark-defaults.conf
spark.sql.legacy.createHiveTableByDefault false

Finally run the docker image
docker run \
    --name emr \
    -v ./spark-logging:/var/loggingConfiguration/spark \
    -v ./app:/app \
    -v ./conf:/etc/spark/conf \
    public.ecr.aws/emr-serverless/spark/emr-7.2.0:20241022 \
    driver \
    --class MyApp \
    /app/myapp_2.12-1.0.jar

This is a serverless image, so it will quickly run and then exit. I tested with a Scala app for Spark.
There is still a step missing for including the OpenSearch PPL extension.

@normanj-bitquill this look good - lets create a tutorial page with all the needed scripts for anyone to experiment with

@ykmr1224 thanks for the Feature request!
I am alarmed at the possibility that the vendor-neutral project will be tied down in any way by a vendor-specific one. The following scenario is what i am afraid of -

Contributor wishes to make changes to opensearch-spark
Works on code and submits a PR
PR fails tests. Changes are required in OpenSearch Core (open source) and OpenSearch Serverless (closed source)
Changes are made to Core (now the feature is compatible with the open-source project)
PR still fails tests because the change breaks when running on OpenSearch Serverless
Contributor must ask folks maintaining OpenSearch Serverless to make changes in their code
Feature is stuck until vendor makes changes (IF they agree to the changes)

This enables the vendor to take control of large portions of open-source code de facto. @ykmr1224 @dblock I am curious if there are positive precedents for this type of dependency out there.
This may not be 100% true for this feature, but could be the case for other vendor-owned integrations, or might start to happen once we open the possibility and push a gray line further and further.

@AmiStrn thanks for the feedback
I do believe that opening our code for multi-vendors contribution in a well managed way would actually benefit the Community - there are some open source projects that utilize this approach allowing vendor specific code contributions in their own rep (similar to OpenTelemetry - contrib repository)
We do need to avoid any direct build or runtime dependencies in these contrib components
We need an additional abstract layer to allow the specific vendor implementation without explicitly depending on it (the next example is NOT a good separations of concerns IMO )

authors: AmiStrn YANG-DB dblock normanj-bitquill reta ykmr1224

repo: opensearch-project/opensearch-spark


text:
Remove query log from job executor

Description
Remove query log from job executor.
Logging it would require sensitive info anonymized like: https://github.com/opensearch-project/sql/blob/2649200e065dff48282dce438ceb0ee5ac39054e/sql/src/main/java/org/opensearch/sql/sql/antlr/AnonymizerListener.java#L34.
Issues Resolved
List any issues this PR will resolve, e.g. Closes [...].
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

There's another place log the query https://github.com/opensearch-project/opensearch-spark/blob/main/spark-sql-application/src/main/scala/org/apache/spark/sql/FlintREPL.scala#L95.

authors: noCharger seankao-az


text:
Changes to build for Spark 3.5.1.

Description
These changes fix compile and unit test issues for Spark 3.5
Issues Resolved
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Thanks for drafting the PR. I'm raising a new PR to fix the IT.

Thank you!


text:
Meetup API Integration

Test and integrate previous submission for API integration with meetup. This should keep us from having to visit the Meetup website and creating markdown for events that appear on both our events page and the meetup page.

#2542

Very excited for this long-needed enhancement @nateynateynate 😃

I've made a number of fixes to this, and the only thing that remains to be decided/fixed is what 'category' these events fall under so that we can filter them appropriately.
Meetup doesn't provide a category for them on its own, so it's something we'll have to determine on our end based on maybe the title of the event and/or the group that it's in.
Will collab with @krisfreedain

The three choices we have are community, development, and events - let's just apply a series of regexp patterns to the meeting title to determine its category.

authors: krisfreedain nateynateynate

repo: opensearch-project/project-website


text:
Publish blog for Anomaly Detection 1.1 Unified Flow feature

Describe the blog post your would like to write
A detailed description of the unified flow feature / enhancement in the Anomaly Detection plugin as part of the 1.1 release. Using an example, the blog will walk through how to set up and run real-time and historical anomaly detection using the unified workflow.
What is the title of the blog post?
[PENDING] "Simplifying real-time and historical anomaly detection in OpenSearch"
Who are the authors?
@ohltyler, Pavani Baddepudi
What is the proposed posting date?
On or before November 16, 2021

Thanks @ohltyler! This all looks good. Looking forward to a PR.

authors: ohltyler stockholmux


text:
Adding blog post for performance improvements in hybrid query in 2.15

Description
Blog post regarding Boosting Hybrid Query Performance in OpenSearch 2.15
Issues Resolved
https://github.com/opensearch-project/project-website/issues/3001
Check List

[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

@martin-gaievski - Update meta has been provided. Once the blog has been reviewed by @natebower and changes have been implemented, please @ me and include @nateynateynate and @krisfreedain so they can get this out on July 2 (I am out of the office that day).

@pajuric @krisfreedain @nateynateynate This should be ready for the publishing process. Thanks!

@nateynateynate @krisfreedain - Blog is ready to publish.

authors: martin-gaievski natebower pajuric


text:
Update setup.py

Currently won't install via setup or pip since the README had the wrong extension

Closing due to duplication of #2.

authors: achokey-crp kgrandis

repo: opensecrets/python-crpapi


text:
enable serviceCertValidityMinutes in the configmap to make it dynamic

As of today the serviceCertValidityMinutes is configurable only at the time of install, we want to make this configurable at any time. Hence this needs to be added to the configmap for osm
Scope (please mark with X where applicable)

New Functionality          [X]
Install                    [ ]
SMI Traffic Access Policy  [ ]
SMI Traffic Specs Policy   [ ]
SMI Traffic Split Policy   [ ]
Permissive Traffic Policy  [ ]
Ingress                    [ ]
Egress                     [ ]
Envoy Control Plane        [ ]
CLI Tool                   [ ]
Metrics                    [ ]
Certificate Management     [ ]
Sidecar Injection          [ ]
Logging                    [ ]
Debugging                  [ ]
Tests                      [ ]
CI System                  [ ]
Project Release            [ ]

Assign this to me?

Why is this a P1 @snehachhabria. What is the use case for users to start tweaking cert validity period at run time?

By default we will install OSM with a validity of 1 day but if users  want a different validity for their version of osm we want it configurable

By default we will install OSM with a validity of 1 day but if users want a different validity for their version of osm we want it configurable

Question was more regarding what is the use case to change the validity period? Should this be a P1?

We need to validate input and ensure that the value is within some reasonable ranges. (For example a fraction of a minute may not be reasonable as it would cause too frequent of a cert renewal.)

authors: draychev shashankram snehachhabria wenxinnnnn

repo: openservicemesh/osm


text:
Update logo in Header

Depends on #47

needs a rebase

authors: belwell jtomasek

repo: openshift-metalkube/facet


text:
[WIP] Replaces Pipelinerun with taskrun in pac namespace

As in pac namespace, we used to create pr with only
one task, instead of that we are switching to Taskrun
now. this would save us a reconcile loop of pipelines
controller as pipelinerun takes 2 reconcile loop and
taskrun takes one.
Closes #387
Signed-off-by: Shivam Mukhade smukhade@redhat.com

Changes

Submitter Checklist

[ ] ♽  Run make test lint before submitting a PR (ie: via pre-push github hook no need to waste CPU cycle on CI
[ ] 📖 If you are adding a user facing feature or make a change of the behaviour, please make sure to document it
[ ] 🧪 100% coverage is not a target but most of the time we would rather have a unit test if you make a code change.
[ ] 🎁 If that's something that is possible to do please make sure to check if we can add a e2e test.
[ ] 🔎 If there is a flakyness in the CI tests then make sure to get the flakyness fixed before merging or if that's not possible there is a good reason to bypass it.

See the developer guide for a bit more details.

Codecov Report

Merging #390 (d8618dc) into main (d11c8f9) will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #390      +/-   ##
==========================================
+ Coverage   70.56%   70.58%   +0.02%
==========================================
  Files          50       50
  Lines        2585     2584       -1
==========================================
  Hits         1824     1824
+ Misses        582      581       -1
  Partials      179      179

Impacted Files
Coverage Δ

pkg/resolve/resolve.go
88.88% <0.00%> (+0.22%)
:arrow_up:

pkg/consoleui/tektondashboard.go
80.00% <0.00%> (+5.00%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d11c8f9...d8618dc. Read the comment docs.

loooks like the e2e is passing 🥳

let's see how it behave when the cluster reinstalls

authors: chmouel codecov-commenter sm43

repo: openshift-pipelines/pipelines-as-code


text:
Limits number of events in describe command

if there are lot of events for a repository now
repository show only the latest 50.
https://issues.redhat.com/browse/SRVKP-2601
Signed-off-by: Shivam Mukhade smukhade@redhat.com

Changes

Submitter Checklist

[x] ♽  Run make test lint before submitting a PR (ie: with pre-commit, no need to waste CPU cycle on CI
[ ] 📖 If you are adding a user facing feature or make a change of the behavior, please verify that you have documented it
[ ] 🧪 100% coverage is not a target but most of the time we would rather have a unit test if you make a code change.
[ ] 🎁 If that's something that is possible to do please ensure to check if we can add a e2e test.
[ ] 🔎 If there is a flakiness in the CI tests then don't necessary ignore it, better get the flakyness fixed before merging or if that's not possible there is a good reason to bypass it. (token rate limitation may be a good reason to skip).

💯 🎯
feel free to merge it when CI is green.

/retest

Codecov Report

Merging #978 (8091c80) into main (aa20f22) will increase coverage by 0.04%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #978      +/-   ##
==========================================
+ Coverage   61.05%   61.10%   +0.04%
==========================================
  Files          89       89
  Lines        5873     5887      +14
==========================================
+ Hits         3586     3597      +11
- Misses       1945     1947       +2
- Partials      342      343       +1

Impacted Files
Coverage Δ

pkg/cmd/tknpac/describe/describe.go
47.65% <0.00%> (-0.65%)
:arrow_down:

pkg/reconciler/reconciler.go
22.87% <0.00%> (-0.16%)
:arrow_down:

pkg/acl/acl.go
100.00% <0.00%> (ø)

pkg/formatting/repository.go
100.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


text:
Add v1 service-ca operator config

/cc @openshift/sig-auth @openshift/api-reviewers

/lgtm

Do we need this configuration? There's one set of keys used in the three controllers.  Why do they need to be configurable separately? If the CA injected into configmaps and apiservices doesn't match the signing key used to supply certs to services, things will break.
Then I'm not sure we need to let where the certs are mounted into the service-ca pods, or which secret/configmaps, be configurable (beyond configuring it on the deployment itself).
I'm not sure what we're gaining with the extra complexity that can't handled by the CVO or controllers themselves. @smarterclayton am I missing something that makes this bundling layer necessary?

@ericavonb The service-ca operator will be the only thing managing these individual controllers configs and deployments, we won't be exposing this in a top level config (trying to change the values would get stomped on). They are uniform but separate basically because of the current structure of the operator, and this does not add any additional complexity as the operator already expects this layout (compare with servicecertsigner/v1alpha1). I agree there is redundant information but for the purpose of renaming the operator this is all we need.

Note that only the ServiceCA struct is an actual CR.  The others are the CLI configs of the controllers (otherwise the operator has no way to configure the controllers).  I suppose those could could be in a different group.  @deads2k what is the expectation on the location of the CLI configs?
The operator CR is required to control the standard functionality of the operator.  The 3 overrides allow the user to mess with the CLI configs of the controllers in the same manner as the unsupported config overrides code.  All of this is existing API with a simple rename.

@enj we don't need to worry about CLI config in the same way anymore. Those can be defined and managed within the operator repo, since it's the only place that deals with it directly.

Just as the kube API server CLI config lives in this repo, I expect these and our other CLI configs to live here.  We are allowed great flexibly in changing them, but that does not mean we can skip the API review process.

I would suggest serviceca.authentication.openshift.io. Since no user would be supported in directly changing these, I don't see a need for them to be in openshift/api.
/close

I would suggest serviceca.authentication.openshift.io. Since no user would be supported in directly changing these, I don't see a need for them to be in openshift/api.

The binary config types.  Your operator config type that is served can live here.

repo: openshift/api


text:
Reorder clusterrole and clusterrolebinding

The template will create resources in order so the role needs to be created before the binding can use it

/hold
Putting a hold as the user that applies this role doesn't have the correct permissions

repo: openshift/aws-account-operator


text:
Detect assume-initial-arn from OCM URL

What type of PR is this?
feature
What this PR does / Why we need it?
It can still be supplied in the config file as an override, but with this change it is now optional for individuals interacting with standard OCM URLs.
Which Jira/Github issue(s) does this PR fix?
OSD-20606
Pre-checks (if applicable)

[x] Ran unit tests locally
[x] Validated the changes in a cluster
[ ] Included documentation changes with PR

Codecov Report
Attention: 11 lines in your changes are missing coverage. Please review.

Comparison is base (8f6281c) 45.97% compared to head (43ed1d0) 45.97%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #325      +/-   ##
==========================================
- Coverage   45.97%   45.97%   -0.01%
==========================================
  Files          53       53
  Lines        3754     3772      +18
==========================================
+ Hits         1726     1734       +8
- Misses       1754     1764      +10
  Partials      274      274

Files
Coverage Δ

cmd/ocm-backplane/cloud/common.go
20.11% <42.10%> (+2.72%)
:arrow_up:

authors: codecov-commenter mjlshen

repo: openshift/backplane-cli


text:
updating readme with project alignment changes

We changed the name of the operator docs should align

/lgtm

/lgtm cancel

@sferich888 this is a cluster-scoped resource today, can you remove -n openshift-image-registry?

@sferich888 bump
Please see the comment from @dmage above.

Merged, https://github.com/openshift/cluster-image-registry-operator/pull/289/commits/01b984f2bcb932114abda1a631a4f8ac993dd848

authors: coreydaley dmage sferich888


text:
Lower lease duration, renew deadline and retry period to double the d…

…efault value.

/lgtm

/retest

authors: abutcher dgoodwin

repo: openshift/hive


text:
HOSTEDCP-1121: Ensure SG reconciliation for aws endpoint

What this PR does / why we need it:
This ensures that clusters running before we enforced the hypershift security group on the endpoint creation get that SG as well.
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/cherry-pick release-4.13

cc @mjlshen

/test e2e-aws

HCs are failing to delete because the CPO can't delete the SG
{"level":"error","ts":"2023-08-03T17:53:12Z","msg":"Reconciler error","controller":"hostedcontrolplane","controllerGroup":"hypershift.openshift.io","controllerKind":"HostedControlPlane","HostedControlPlane":{"name":"example-twnql","namespace":"e2e-clusters-8c99h-example-twnql"},"namespace":"e2e-clusters-8c99h-example-twnql","name":"example-twnql","reconcileID":"1a8f55f8-267a-421c-b7ec-f21349a8e797","error":"failed to delete AWS default security group: failed to delete security group sg-0e617478f69845895: DependencyViolation: resource sg-0e617478f69845895 has a dependent object\n\tstatus code: 400, request id: 6d530e23-db27-45a7-805a-9cdbce8860fe","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/hypershift/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:326\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/hypershift/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:273\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/hypershift/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:234"}

It can't delete the SG because the awsendpointservice is still using it, as it is not being deleted
The awsendpointservice is not being deleted because the capi Cluster resource hasn't finished deletion yet
{"level":"info","ts":"2023-08-03T17:55:13Z","msg":"Waiting for cluster deletion","controller":"hostedcluster","controllerGroup":"hypershift.openshift.io","controllerKind":"HostedCluster","HostedCluster":{"name":"example-n679l","namespace":"e2e-clusters-jxt9t"},"namespace":"e2e-clusters-jxt9t","name":"example-n679l","reconcileID":"343d2ffb-83d1-43ef-a057-f5d1d4d3e81d","clusterName":"example-n679l","controlPlaneNamespace":"e2e-clusters-jxt9t-example-n679l"}

The capi Cluster resource hasn't finished deletion yet because there's a leaked awsMachine
Why there's a leaked awsMachine?

See if this makes a difference https://github.com/openshift/hypershift/pull/2872/files#diff-b5cde720842b19b53da3f454d827e27327c4559b2e4849906dac728586f51eb3R3272-R3274

/hold cancel

/lgtm

last run passed, but hit flake
{Failed  === RUN   TestCreateClusterCustomConfig/EnsureNetworkPolicies/EnsureComponentsHaveNeedManagementKASAccessLabel
    util.go:796:
        Unexpected error:
            <*errors.errorString | 0xc003e7d6e0>:
            not all expected components have NeedManagementKASAccessLabel:   []string(Inverse(Sort, []string{
              	... // 10 identical elements
              	"ignition-server",
              	"machine-approver",
            + 	"olm-collect-profiles-28185803-xzl2b",
              	"private-router",
              }))

need https://github.com/openshift/hypershift/pull/2874

/retest-required

/unhold

/retest-required

authors: enxebre muraee

repo: openshift/hypershift


text:
OCPBUGS-43746: add ValidIDPConfiguration condition to report IDP config issues

Combine clean picks of https://github.com/openshift/hypershift/pull/4852 and https://github.com/openshift/hypershift/pull/4955
The changes to API and HO are not required but don't hurt and make the picks clean

/jira cherry-pick OCPBUGS-38132

/jira refresh

/area control-plane-operator

/retest

/test e2e-kubevirt-aws-ovn-reduced

/lgtm

/cherry-pick release-4.16

authors: Patryk-Stefanski sjenning


text:
docs: Minor update to in-cluster development registry login steps

Before this commit, the in-cluster development docs used an oc registry login
command which could sometimes log the user in to the cluster's internal instead
of external registry if the prior steps to enable the external registry hadn't
yet completed.
This commit updates the login command to make sure the registry login always
targets the external registry route.

/lgtm

authors: ironcladlou sjenning


text:
[head] Support cgroups v2 (Podman on Fedora 31+)

In code there are embedded paths that are valid only for cgroups v1. This PR creates functions that calculate memory in container either for v1 or v2 of cgroups.

/assign @akashshinde

/unassign akashshinde

/assign

@cardil Thank you for the contribution. As you have mentioned that we support cgroupsv1 only, based on the same I will review this for v2 support.
cc @akram

@waveywaves, just to clarify I understand, do you mean this will be postponed and addressed as a part of some larger effort later? I am asking to set some expectation on when this can get integrated. Thanks!

thanks @cardil for this contribution. We need more time to test it ; as it seem non-intrusive for OpenShift, it could be merged hopefully.
Please not that for now we don't support cgroups v2 in OpenShift.

/retitle [main] Support cgroups v2 (Podman on Fedora 31)

/retitle [head] Support cgroups v2 (Podman on Fedora 31)

/remove-lifecycle stale

/lgtm

/retitle Bug 1971537: Support cgroups v2

/bugzilla refresh

/test images
/retest

authors: akram cardil olivergondza waveywaves

repo: openshift/jenkins


text:
add workflow / fabric related plugins

@bparees PTAL (though given your PTO certainly wait until next week if you like ;-) )
Note:  technically, I only need the # Pipeline plugin - https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin list of plugins for the new DSL for OpenShift Pipeline Plugin, but I went ahead and added the complete list from https://github.com/fabric8io/openshift-jenkins-s2i-config/blob/master/plugins.txt, except for the fact that our image was already pulling in credentials:1.24 (where the plugins.txt from the fabric folks was pulling in credentials:1.22).
@jimmidyson @rawlingsj - FYI

[test]

Sorry, also minimally need these:
seem to be missing from the Jenkins docs but required to run these plugins..
structs:1.1
git-client:1.19.0
git-server:1.5
plain-credentials:1.1
ace-editor:1.0.1
But per the PR, including the complete fabric list seems appropriate, but advise if you think otherwise @bparees

had a yum hiccup ... issuing a re [test]

lgtm

authors: bparees gabemontero


text:
wait for certs to be present before installing

for https://bugzilla.redhat.com/show_bug.cgi?id=1702104
This waits for unrevisioned certs to be present before continuing.
/hold
hold for proof and unit tests

proof pull https://github.com/openshift/cluster-kube-apiserver-operator/pull/431

/lgtm

repo: openshift/library-go


text:
OLS-721: ability to create list of build packages

Description
Ability to create list of build packages
Type of change

[ ] Refactor
[x] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library
[ ] Bump-up library or tool used for development (does not change the final image)

Related Tickets & Documents

Related Issue #OLS-721

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Please upload report for BASE (main@5b1ea99). Learn more about missing BASE report.
Report is 27 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1125   +/-   ##
=======================================
  Coverage        ?   95.44%
=======================================
  Files           ?       56
  Lines           ?     2371
  Branches        ?        0
=======================================
  Hits            ?     2263
  Misses          ?      108
  Partials        ?        0

/retest

/lgtm

/approve

authors: codecov-commenter onmete tisnik

repo: openshift/lightspeed-service


text:
Add script to get rag chunks for spot verification

Description
Sometime it is essential to verify retrieved RAG chunks.

to analyze any change in response during evaluation due to RAG content
to check what exactly we are sending to LLM.
to check order and score for the chunks.

We can run this script on adhoc basis to do above analysis.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 95.61%. Comparing base (9ebbaea) to head (55ea72a).
Report is 11 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1227      +/-   ##
==========================================
- Coverage   95.64%   95.61%   -0.03%
==========================================
  Files          56       56
  Lines        2410     2394      -16
==========================================
- Hits         2305     2289      -16
  Misses        105      105

/lgtm

/approve

authors: asamal4 codecov-commenter tisnik


text:
OLS-833: Update package references for Cachi2 + fix vuln. in requirements.txt

Description
Update package references for Cachi2 + fix vuln. in requirements.txt (detected by dependabot and sec. scans)
Type of change

[ ] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[x] Configuration Update
[ ] Bump-up dependent library
[ ] Bump-up library or tool used for development (does not change the final image)

Related Tickets & Documents

Related Issue #OLS-833

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Please upload report for BASE (main@3338891). Learn more about missing BASE report.
Report is 16 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1258   +/-   ##
=======================================
  Coverage        ?   94.66%
=======================================
  Files           ?       57
  Lines           ?     2455
  Branches        ?        0
=======================================
  Hits            ?     2324
  Misses          ?      131
  Partials        ?        0

/approve

/lgtm


text:
Disable WatsonX e2e tests temporarily

Description
Disable WatsonX e2e tests temporarily
Type of change

[ ] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library
[ ] Bump-up library or tool used for development (does not change the final image)
[x] CI configuration change
[ ] Konflux configuration change

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.40%. Comparing base (b3b5488) to head (d0c64b8).
Report is 6 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #1947       +/-   ##
===========================================
+ Coverage   73.05%   93.40%   +20.35%
===========================================
  Files          67       69        +2
  Lines        2872     2881        +9
===========================================
+ Hits         2098     2691      +593
+ Misses        774      190      -584

see 40 files with indirect coverage changes

----
🚨 Try these New Features:

Flaky Tests Detection - Detect and resolve failed and flaky tests

/test verify

/test verify

/test 4.16-e2e-ols-cluster
/test 4.17-e2e-ols-cluster

authors: codecov-commenter tisnik


text:
Fix clustersync-breaking bug in delete-olm-operator

This corrects a bug in the delete-olm-operator managed script.
Currently this script does not remove the last-applied-configuration annotation from the subscription, catalogsource and operatorgroup resources that it saves, deletes and recreates.
This means that when the script recreates the resources, the Hive clustersync will no longer be able to successfully clustersync them. In the case of a catalogsource this is quite bad as it means the cluster will no longer be receiving operator updates.
The fix ensures that the last-applied-configuration annotation is removed.
I have tested it in a staging cluster to ensure it still works.

/lgtm

/lgtm

/approve

authors: cblecker feichashao mrbarge

repo: openshift/managed-scripts


text:
Support projects with dockerfile

[kind/Feature]
Which functionality do you think we should add?
Allow projects that has a dockerfile to be taken into the inner-loop mode. User should be able to run a command such as odo create --image=<path/to/my/dockerfile. This is a different mode than our current s2i based mode.  As a consequence we need a way to capture the commands to modify the contents of the image.
Why is this needed?
There are many container based applications that has a dockerfile and do not use s2i as their build. This will allow them to use odo to do their inner-loop without making major changes to do s2i based builds.

when using this feature, as we cannot know the variables like DEPLOYMENT_DIR etc that are present when s2i builder images are used and also we dont control the startup commands - Features like smarter push wouldn't work and debug wouldn't work.
Instead of smarter push either odo push --config could happen when only the config is changed or a rebuild with a full source code copy ( if source changes ) could happen.
correct me if I am wrong @kadel

is this something we are still interested in @kadel @gorkem ?

is this something we are still interested in @kadel @gorkem ?

It might take a different form, but yes. This is something that we are still interested in

/remove-lifecycle rotten
/lifecycle frozen

authors: girishramnani gorkem kadel

repo: openshift/odo


text:
Adds sleep before running 'odo unlink' to avoid race condition

What type of PR is this?
/kind failing-test
What does this PR do / why we need it:
$subject
We need this since it's become an annoyance in getting CI to pass for PRs.
Which issue(s) this PR fixes:
Fixes #4301
PR acceptance criteria:

[ ] Unit test

[x] Integration test

[ ] Documentation

[x] I have read the test guidelines

How to test changes / Special notes to the reviewer:
CI should be green. Especially CI shouldn't fail due to #4301.

[ssh:Fedora 32] • Failure [301.546 seconds]
[ssh:Fedora 32] odo devfile supported tests
[ssh:Fedora 32] /home/fedora/amqp_ci_rcv_odo-pr-build_PR_4428/repo/tests/e2escenarios/e2e_devfile_test.go:23
[ssh:Fedora 32]   odo debug support for devfile components
[ssh:Fedora 32]   /home/fedora/amqp_ci_rcv_odo-pr-build_PR_4428/repo/tests/e2escenarios/e2e_devfile_test.go:65
[ssh:Fedora 32]     Verify output debug information for java-openliberty debug works [It]
[ssh:Fedora 32]
[ssh:Fedora 32] [Fail] odo devfile supported tests odo debug support for devfile components [It] Verify output debug information for java-openliberty debug works
[ssh:Fedora 32] /home/fedora/amqp_ci_rcv_odo-pr-build_PR_4428/repo/tests/helper/helper_run.go:34
[ssh:Fedora 32]
[ssh:Fedora 32] Ran 30 of 30 Specs in 836.482 seconds
[ssh:Fedora 32] FAIL! -- 29 Passed | 1 Failed | 0 Pending | 0 Skipped

/retest

[ssh:Fedora 32] • Failure [301.783 seconds]
[ssh:Fedora 32] odo devfile supported tests
[ssh:Fedora 32] /home/fedora/amqp_ci_rcv_odo-pr-build_PR_4428/repo/tests/e2escenarios/e2e_devfile_test.go:23
[ssh:Fedora 32]   odo debug support for devfile components
[ssh:Fedora 32]   /home/fedora/amqp_ci_rcv_odo-pr-build_PR_4428/repo/tests/e2escenarios/e2e_devfile_test.go:65
[ssh:Fedora 32] [Fail] odo devfile supported tests odo debug support for devfile components [It] Verify output debug information for java-openliberty debug works
[ssh:Fedora 32] /home/fedora/amqp_ci_rcv_odo-pr-build_PR_4428/repo/tests/helper/helper_run.go:34
[ssh:Fedora 32]
[ssh:Fedora 32] Ran 30 of 30 Specs in 918.405 seconds
[ssh:Fedora 32] FAIL! -- 29 Passed | 1 Failed | 0 Pending | 0 Skipped

Same error as previous CI run
/retest

The irony. Below failure is the exact thing this PR is trying to fix (https://github.com/openshift/odo/pull/4428#discussion_r578989948):
 [odo]
 ✗  Waiting for component to start [5m] [WARNING x7: Failed]
[odo]  ✗  Failed to start component with name eyvodd. Error: Failed to create the component: error while waiting for deployment rollout: timeout while waiting for eyvodd deployment roll out\nFor more information to help determine the cause of the error, re-run with '-v'.
[odo] See below for a list of failed events that occured more than 5 times during deployment:
[odo]
[odo]  NAME                                      COUNT  REASON  MESSAGE
[odo]
[odo]  eyvodd-7cbd48b669-7zpxw.16651d420a71b7c8  7      Failed  Error: secret
[odo]                                                           "eyvodd-etcdcluster-example"
[odo]                                                           not found
[odo]
[odo]
Deleting project: peswyzkths
Running odo with args [odo project delete peswyzkths -f]

/lgtm

/lgtm cancel

@dharmit: The following test failed, say /retest to rerun all failed tests:
Test name	Commit	Details	Rerun command
ci/prow/v4.6-e2e-4x-psi	416bc6f link /test v4.6-e2e-4x-psi
Full PR test history. Your PR dashboard.

It looks like the problem is still present :-(
I0219 13:45:59.806280 2675524 events.go:52] Warning Event: Count: 6, Reason: Failed, Message: Error: secret "jxqesj-etcdcluster-example" not found
[ssh:Fedora 32] [odo]
I0219 13:46:13.595252 2675524 events.go:52] Warning Event: Count: 7, Reason: Failed, Message: Error: secret "jxqesj-etcdcluster-example" not found
[ssh:Fedora 32] [odo]  ✗  Waiting for component to start [5m] [WARNING x7: Failed]
[ssh:Fedora 32] [odo]  ✗  Failed to start component with name jxqesj. Error: Failed to create the component: error while waiting for deployment rollout: timeout while waiting for jxqesj deployment roll out\nFor more information to help determine the cause of the error, re-run with '-v'.
[ssh:Fedora 32] [odo] See below for a list of failed events that occured more than 5 times during deployment:
[ssh:Fedora 32] [odo]
[ssh:Fedora 32] [odo]  NAME                                     COUNT  REASON  MESSAGE
[ssh:Fedora 32] [odo]
[ssh:Fedora 32] [odo]  jxqesj-c8df4fd78-42k4r.16652a06959602c9  7      Failed  Error: secret
[ssh:Fedora 32] [odo]                                                          "jxqesj-etcdcluster-example"
[ssh:Fedora 32] [odo]                                                          not found
[ssh:Fedora 32] [odo]
[ssh:Fedora 32] [odo]
[ssh:Fedora 32] Deleting project: kmsirtuuwn
[ssh:Fedora 32] Running odo with args [odo project delete kmsirtuuwn -f]

/refresh

/lgtm

authors: dharmit girishramnani kadel


text:
Adds dev.odo.push.path attribute support for pushing only mentioned files

What type of PR is this?
/kind feature
What does does this PR do / why we need it:
It uses the dev.odo.push.path attribute to push only the mentioned files.
Which issue(s) this PR fixes:
Fixes https://github.com/openshift/odo/issues/3132
PR acceptance criteria:

[X] Unit test

[X] Integration test

[ ] Documentation : https://github.com/openshift/odo/pull/4681/

[ ] I have read the test guidelines

How to test changes / Special notes to the reviewer:

Use the attribute dev.odo.push.path:<local-path>:<remote-path> in the run command to mark the files/folders which should be pushed inside the container.
Execute odo push
Use to kubectl exec to check if the required file/folders are present inside the container and their location.

/test psi-kubernetes-integration-e2e

I have done some testing with quarkus and it works great.
I just noticed that if the local directory or file specified in annotation doesn't exist odo doesn't error out.
It should probably do that. I made this mistake, and it took me a while to until I figured out what was happening.

I just noticed that if the local directory or file specified in annotation doesn't exist odo doesn't error out.

I have changed the code to return an error in such an scenario.

ERRO[2021-05-05T14:44:24Z]   * could not run steps: step integration-e2e failed: "integration-e2e" post steps failed: "integration-e2e" pod "integration-e2e-ipi-deprovision-deprovision" failed: the pod ci-op-yhxhtbdc/integration-e2e-ipi-deprovision-deprovision failed after 31m33s (failed containers: test): ContainerFailed one or more containers exited
ERRO[2021-05-05T14:44:24Z] Container test exited with code 1, reason Error

/retest

/hold
need to get this comment addressed https://github.com/openshift/odo/pull/4588#discussion_r627251416

authors: girishramnani kadel mik-dass prietyc123