text:
[FEATURE] Support for script operations in the update action of the client.helpers.bulk method

Signed-off-by: huuyafwww huuya1234fwww@gmail.com
Description
This is a modification to the client.helpers.bulk method to support script operations in the update action.
Issues Resolved
#209
Check List

[x] New functionality includes testing.

[x] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[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 Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Here is the bulkBody after and before modification.
This modification makes the bulkBody I wanted!
sample code here:
const body = [[
  { update: { _id: '1', _index: 'sample-index'} },
  { script: {
      source: "ctx._source.body = params.body;",
      lang: 'painless',
      params: {
        body: "sample body",
      }
    },
    scripted_upsert: true,
  },
]];

await client.helpers.bulk({
  datasource: body,
  onDocument (doc) {
    return doc;
  }
});

before bulkBody
{"update":{ "_id": "1", "_index": "sample-index"}},
{"doc":[{"update":{ "_id": "1", "_index": "sample-index"}},{"script":{"source":"ctx._source.body = params.body;","lang":"painless","params":{"body":"sample body"}},"scripted_upsert":true}

after bulkBody
{"update":{ "_id": "1", "_index": "sample-index"}},
{"script":{"source":"ctx._source.body = params.body;","lang":"painless","params":{"body":"sample body"}},"scripted_upsert":true}

Hello @huuyafwww, thanks for opening this! Since this changes a request, I would consider this a major version change which could impact other consumers of the package. To build this in a way that makes it possible to get your desired behavior by making it configurable with the default path being the current request.

@kavilla
Thanks for the check.

Since this changes a request, I would consider this a major version change which could impact other consumers of the package.

Indeed it is.
I agree with you.

To build this in a way that makes it possible to get your desired behavior by making it configurable with the default path being the current request.

Ok.
Am I correct in assuming that we build a "doc" or "script" depending on the contents of the chunk ?

@kavilla

Am I correct in assuming that we build a "doc" or "script" depending on the contents of the chunk or action?

This is fine, but if you can determine that the operation is a "doc" or "update" operation by the code below, for example, you know that the developer has entered "doc" or "update" as the return value of onDocument in the first place.
const document = Array.isArray(action)
  ? Object.keys(action[1])[0]
  : Object.keys(action)[0]

So we assigned action[1] as the completion of Object.keys(action[1])[0] and chunk as the completion of Object.keys(action)[0].
payloadBody = serializer.serialize(action[1] || chunk)

What do you think about my idea?

Hi, @kavilla!
What do you think of my opinion?
Thanks for taking the time to respond.

Hello @huuyafwww, will take a look next week if that is okay! Sorry about the delay.

Hello @kavilla, Thanks again for your thoughtful replies.
Understood!

Sorry for the delay, I was incapacitated for the past two weeks! I see what you are getting at and makes sense for me. But since having forked this repo I will need to derive the same level of insight as you. So what you are saying is that by the time the update operation is hit there was essentially no reason why it was checking if it was a doc or not since the value should be correct and that we were previously spreading the completion into the payload body which was the root case of script operations not being supported in update operations. Because basically it was getting incorrectly applied everytime?

Sorry for the delay, I was incapacitated for the past two weeks!

Don't worry about it.
Thank you for confirming my request in spite of all that.

But since having forked this repo I will need to derive the same level of insight as you.

Roger that!

So what you are saying is that by the time the update operation is hit there was essentially no reason why it was checking if it was a doc or not since the value should be correct and that we were previously spreading the completion into the payload body which was the root case of script operations not being supported in update operations. Because basically it was getting incorrectly applied everytime?

You're right!
There are doc and script for api batch update operations, but only doc was supported by this helpers.bulk in the first place.
The implementation was based on the doc premise and was designed to be complementary, so there was no way to request an update operation in the script.
Therefore, I am modifying the relevant section in this pull request to also support script updates in this helpers.bulk.
Also, as you can see, there was no need for a conventional complementary implementation in the first place.
This is because if this library can determine whether the update operation the developer is trying to perform is doc or update, there is no need for completion in the first place.
In addition, to explain, being able to determine whether the payload body of an update operation is doc or update is no different from receiving that information directly from the return value of onDocument.
Therefore, since it is no longer necessary to supplement the payload body as before, we have modified it in this way because we believe that the best implementation is to use the return value given by the developer using this library as-is as the payload body.

@kavilla
Hi kavilla.
How about what I am proposing in this pull request?
I have already patched this pull request change to the business system and am running it in the production environment.
If possible, I would like to see it taken in.

Since this pull request was created, the contents of the main branch had changed and was no longer working with the latest version, so the main branch was imported and modified.

Thanks. Needs tests for UpdateActionScriptOperation and a changelog entry.

@dblock

Thanks. Needs tests for UpdateActionScriptOperation and a changelog entry.

Sorry for the delay in responding.
I tested UpdateActionScriptOperation and added an entry to the changelog.
I also added a bulk update test for script operations.

@kavilla

lgtm. Any issues?

I can no longer bulk update doc operations in the conventional way,
It involves some disruptive changes.

@nhtruong would you be willing to take a look, especially with respect to backwards compatibility?

Looks like we failed to merge this after all. @nhtruong could you please take a look?
[Catch All Triage - Attendees 1, 2, 3, 4, 5]

Will add this to the 3.0.0 release and this introduces a breaking change.

authors: dblock huuyafwww kavilla nhtruong wbeckler

repo: opensearch-project/opensearch-js


text:
add flowFrameworkDashboards

Description
add https://github.com/opensearch-project/dashboards-flow-framework
Issues Resolved
Related to https://github.com/opensearch-project/opensearch-build/issues/4851
dashboards-flow-framework plugin is expected to release with OpenSearch 2.17.
Plugin is not yet stable.
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.

@dblock, @ohltyler Please take a look .
Following this guide https://github.com/opensearch-project/opensearch-build/blob/main/ONBOARDING.md#plugin-onboarding

source: gharchive/pull-request

repo: opensearch-project/opensearch-plugins

license_type: permissive

license_source: github-api


text:
[RELEASE] Release v2.2.0

Release the next version of the client v2.2.0 with new features and bug fixes.

Released here -- https://github.com/opensearch-project/opensearch-py/releases/tag/v2.2.0

source: gharchive/issue

authors: VachaShah harshavamsi

repo: opensearch-project/opensearch-py


text:
A comprehensive guide to setup and connect self-managed dashboards with Amazon OpenSearch domain

Describe the blog post your would like to write
In our service, Blue-Green deployment often results in downtime for managed service dashboards, impacting availability. Given the critical reliance of our customers on these dashboards for log analytics and other use cases, I've devised a workaround. By setting up self-managed dashboards and connecting them with the managed service domain, downtime issues during Blue-Green deployment are effectively mitigated. This guide walks through the setup process for self-managed dashboards, covering options such as no authentication, basic authentication, and SAML authentication. Customer to follow along with this blog to implement the solution at their end and ensure uninterrupted access to dashboards.
What is the title of the blog post?
A comprehensive guide to setup and connect self-managed dashboards with Amazon OpenSearch domain
Who are the authors?
@madhankb / @mkbn
What is the proposed posting date?
As early as possible.

The blog details are already published in my personal Github repos. PFB the links
https://github.com/madhankb/OSD-SM-Compatibility-Matrix
https://github.com/madhankb/OSD-SM-No-Authentication
https://github.com/madhankb/OSD-SM-SAML
https://github.com/madhankb/OSD-SM-HTTP-basic-authentication
It can be taken for technical review.

Hi @madhankb !
This doesn't quite read like a blog but rather a technical tutorial. Is there a way we could incorporate these into a longer narrative that has room for each section?
We can also reach out to @hdhalter to see if she could use a quick tutorial to post on some of these things in the documentation site.
Any particular preference?

I concur! It would be fantastic if we have the ability to post these on the OpenSearch documentation site.

I can also write up something like a blog along with the guide/steps to implement like this - https://quip-amazon.com/HtNeAnuOkSpT/Connecting-Standalone-Opensearch-Dashboards-with-Managed-Service-Opensearch-through-Basic-and-SAML-Authentication.
Let me know if you don't have access to the above link

Can we have an update in here please?

Is there any update? Can someone help?

@madhankb - Please go ahead an open a PR for your blog draft in the web repo using thus guide here: https://github.com/opensearch-project/project-website/blob/main/BLOG_GUIDE.md, and we'll get it pushed through the review process.

@pajuric - Opened a PR - https://github.com/opensearch-project/project-website/pull/2852. Kindly do the needful

@pajuric - The blog is approved and ready to be published. Whats the next steps?
https://app.asana.com/0/0/1207214431107391/f

authors: madhankb nateynateynate pajuric

repo: opensearch-project/project-website


text:
updated release date of 2.11 (Making it the last release of 2023).

Description
Updating 2.11 release to start Oct 4th.
Issues Resolved
https://github.com/opensearch-project/opensearch-build/issues/3955
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.

@krisfreedain when you do your review, can you doublecheck I haven't added any funky spaces/chars again?  Haven't had a moment to try and figure out what's adding them yet, so a cross check would be appreciated :/
Thanks!


text:
feat(certs): add basic MRC validation

Description:

adds BASIC validation of the MRC on add and update to the validating webhook

on add, checks for valid trust domain
on update, verifies trust domain and provider were not updated

moves Intent field to MRC spec
adds enum on the Intent field to limit possible values to active and passive

Part of #4723

Testing done:

[x] CI
[x] manual MRC creation and updates

Affected area:

Functional Area

New Functionality
[ ]

CI System
[ ]

CLI Tool
[ ]

Certificate Management
[x]

Control Plane
[ ]

Demo
[ ]

Documentation
[ ]

Egress
[ ]

Ingress
[ ]

Install
[ ]

Networking
[ ]

Observability
[ ]

Performance
[ ]

SMI Policy
[ ]

Security
[ ]

Sidecar Injection
[ ]

Tests
[ ]

Upgrade
[ ]

Other
[ ]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project? No

Did you notify the maintainers and provide attribution?

Is this a breaking change? No

Has documentation corresponding to this change been updated in the osm-docs repo (if applicable)? No

Codecov Report

Merging #5105 (819abc2) into main (926573b) will decrease coverage by 0.29%.
The diff coverage is 84.21%.

@@            Coverage Diff             @@
##             main    #5105      +/-   ##
==========================================
- Coverage   69.76%   69.47%   -0.30%
==========================================
  Files         199      197       -2
  Lines       15497    15493       -4
==========================================
- Hits        10812    10764      -48
- Misses       4629     4674      +45
+ Partials       56       55       -1

Flag
Coverage Δ

unittests
69.47% <84.21%> (-0.30%)
:arrow_down:

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

Impacted Files
Coverage Δ

pkg/validator/validators.go
79.69% <79.66%> (-0.02%)
:arrow_down:

pkg/certificate/providers/config.go
83.16% <100.00%> (ø)

pkg/validator/patch.go
85.95% <100.00%> (+1.98%)
:arrow_up:

pkg/validator/server.go
82.02% <100.00%> (+0.20%)
:arrow_up:

pkg/envoy/ads/server.go
10.00% <0.00%> (-56.67%)
:arrow_down:

pkg/envoy/ads/cache_stream.go
20.00% <0.00%> (-48.34%)
:arrow_down:

pkg/envoy/ads/profile.go
46.51% <0.00%> (-41.87%)
:arrow_down:

pkg/debugger/mock_debugger_generated.go
28.57% <0.00%> (-39.18%)
:arrow_down:

pkg/envoy/ads/cache_callbacks.go
0.00% <0.00%> (-5.95%)
:arrow_down:

pkg/envoy/sds/response.go
83.87% <0.00%> (-5.42%)
:arrow_down:

... and 25 more

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

authors: codecov-commenter jaellio

repo: openservicemesh/osm


text:
Fix problem with quoted kernel arguments

/cc @tsorya
/cc @donpenney

/lgtm

/approve

authors: browsell javipolo tsorya

repo: openshift-kni/lifecycle-agent


text:
e2etest: TopoManager scope=pod two containers not sched

Given topology-manager-scope=pod
When trying to schedule a pod with two containers and each of them fits on different numa zones
then pod is not scheduled.

rebase to solve conflicts

/lgtm
/approve
thanks for the quick updates!

authors: fromanirh jlojosnegros

repo: openshift-kni/numaresources-operator


text:
Handle Pull Request Close

Should we cancel the pipelinerun attached to a pull request when we get a pull request close event?

yeah may be
if user open the pull req again, it will trigger again
so we can cancel

I don't think that's what other CI does tho (ie: github action) i think we should follow what the others do and give the element of least surprise to the user.

repo: openshift-pipelines/pipelines-as-code


text:
ART-238 | Always continue on AMI fail

@tbielawa @jupierce

lgtm. @adammhaile Can you make sure mwoodson@redhat.com, brawilli@redhat.com are also directly emailed?

Will do the needful after those emails are added

@tbielawa already done

@adammhaile where? I dont' see brawilli or mwoodson on the diff view of this PR.

@Justin Pierce jupierce@redhat.com instead of adding mwoodson@redhat.com,
brawilli@redhat.com  directly do you have a mailing list I should include?
On Mon, Oct 22, 2018 at 11:19 AM Justin Pierce notifications@github.com
wrote:

lgtm. @adammhaile https://github.com/adammhaile Can you make sure
mwoodson@redhat.com, brawilli@redhat.com are also directly emailed?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/aos-cd-jobs/pull/1628#issuecomment-431866145,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6iHERjXt4SQOkiRRue0wuaSX67saks5uneIPgaJpZM4Xzkgy
.

per slack @jupierce, changed to openshift-cr@redhat.com
On Mon, Oct 22, 2018 at 11:21 AM Adam Haile ahaile@redhat.com wrote:

@Justin Pierce jupierce@redhat.com instead of adding mwoodson@redhat.com,
brawilli@redhat.com  directly do you have a mailing list I should include?
On Mon, Oct 22, 2018 at 11:19 AM Justin Pierce notifications@github.com
wrote:

lgtm. @adammhaile https://github.com/adammhaile Can you make sure
mwoodson@redhat.com, brawilli@redhat.com are also directly emailed?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/aos-cd-jobs/pull/1628#issuecomment-431866145,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6iHERjXt4SQOkiRRue0wuaSX67saks5uneIPgaJpZM4Xzkgy
.

@tbielawa tbielawa@redhat.com Ahh, further discussion happened on
slack. @jupierce wanted me to add a mailing list instead. Which I did.
On Mon, Oct 22, 2018 at 12:00 PM Tim Bielawa notifications@github.com
wrote:

@adammhaile https://github.com/adammhaile where? I dont' see brawilli
or mwoodson on the diff view of this PR.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/aos-cd-jobs/pull/1628#issuecomment-431878702,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6iwy8eS5Y5hmRn5qWRz9eQhbpnmZks5uneuhgaJpZM4Xzkgy
.

authors: adammhaile jupierce tbielawa

repo: openshift/aos-cd-jobs


text:
add a secret ref for webhook secrets

bug 1504819
https://bugzilla.redhat.com/show_bug.cgi?id=1504819

@deads2k ptal/merge.  needed for https://github.com/openshift/origin/pull/17314

Lifting my comments from the earlier thread:
General thoughts:

This prescribes the key, but doesn't add a type.  Adding types (but not requiring them) can help users categorize their secrets.  That could happen as a later step.
Being prescriptive to reduce choice simplifies the API, but as you noted it can make discoverability harder.  If you created a secretKey which defaulted to WebHookSecretKey would be a backwards compatible change that allows people to avoid specifying if they wish, but may help discoverability.  This could happen later if we actually do have problems.  I personally like being prescriptive.
It is now possible to have a webhook configuration which is invalid at runtime.  With other resources, we use controllers to reflect this in status.  A similar approach could be taken here or you could write-back status from the rest handler.

This looks like a good starting point to me.  We can grow on this in a few directions if we end up needing to.
@bparees any thoughts on how to manage the status aspect?  A small controller seems like an option.
@smarterclayton how do you generally feel about controllers watching the validity of references over time and updating status in general?  It seems consistent with other approaches and reasonably discoverable.  It would simplify status reporting the CLI and the webconsole too.

@deads2k ptal/merge. needed for openshift/origin#17314

Travis seems stuck.  I'll see if it unsticks or if we must summon @stevekuznetsov and get some real CI.

@bparees any thoughts on how to manage the status aspect? A small controller seems like an option.

we already have secret refs (And imagestream refs) elsewhere in the buildconfig that aren't validated.  A general buildconfig controller that validated all the refs in the buildconfig and provided status(or events?) isn't a bad idea, but won't be part of this specific refactor.

seems to have passed travis after my update.

@deads2k anything else?

/assign @deads2k

(I suppose expecting we have bots setup for this repo would be too much)

we already have secret refs (And imagestream refs) elsewhere in the buildconfig that aren't validated. A general buildconfig controller that validated all the refs in the buildconfig and provided status(or events?) isn't a bad idea, but won't be part of this specific refactor.

I agree.  Just wanted to know about general general concept.
/lgtm

(I suppose expecting we have bots setup for this repo would be too much)

Welcome to the wild west.  I'll fix that :)

Yeah there is no way to give the bots access to all repos, and they need write access to a repo to do anything meaningful to it, so just ask me or someone else who can edit those configs to add them.

authors: bparees deads2k stevekuznetsov

repo: openshift/api


text:
Add Kubevirt CSI Driver to ClusterCSIDriver's enum

This change is part of CNV-9798 - Update CSO to deploy Kubevirt CSI driver operator.
It is needed to enable tenant kubevirt clusters consume PVs from the infra OCP cluster

/lgtm

@ydayagi, Just to make sure I understand the goal here, there will be an OpenShift ( infra OCP ) that runs kubevirt that runs another OpenShift (how do you call it? nested OCP?).
Is kubevirt just another "cloud" provider to the nested OCP and you want to deploy the CSI driver into the nested OCP by default, no questions asked, just like we deploy oVirt CSI driver now?
No changes / kubevirt CSI driver running in the infra OCP, right?
If the answer to both question is yes, then /lgtm.

We call it 'tenant cluster' :-)
No changes to infra OCP
Thanks
On Thu, Feb 11, 2021 at 3:55 PM Jan Šafránek notifications@github.com
wrote:

@ydayagi https://github.com/ydayagi, Just to make sure I understand the
goal here, there will be an OpenShift ( infra OCP ) that runs kubevirt that
runs another OpenShift (how do you call it? nested OCP?).
Is kubevirt just another "cloud" provider to the nested OCP and you want
to deploy the CSI driver into the nested OCP by default, no questions
asked, just like we deploy oVirt CSI driver now?
No changes / kubevirt CSI driver running in the infra OCP, right?
If the answer to both question is yes, then /lgtm.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/api/pull/836#issuecomment-777474784, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AQS5Y2ZZEFYGCBQFJFOR733S6POTNANCNFSM4WUGSF5A
.

/lgtm

@jsafrane who approves this PR?

@jsafrane who approves this PR?
I'd start with @deads2k

/approve

authors: chenyosef deads2k jsafrane ydayagi


text:
[OSD-6207] Documentation Improvements

OSD-6207

Added Go Report Card Badge to README
Added Go Doc Badge to README
Added docs README, Glossary, Debugging pages
Updated Installation docs & moved prerequisites into their own file.
Grouped all CRs and Controllers by their type (AccountPool, Account etc) instead of their function (CR vs Controllers) as I felt it's easier to read this way

/label tide/merge-method-squash

Overall LGTM.  Can you rebase/squash to a single commit and then I'll give the :+1: and merge it in?

thanks for that @dkeohane overall it's looking good, left some minor comments.

/lgtm

authors: dkeohane iamkirkbater rogbas

repo: openshift/aws-account-operator


text:
OSD-14675: Initializing repository

This PR serves the purpose of initializing the repository , please note this is a part of initialization and hence more like a scaffolding. The following have been added.

main.go (with a sample function)
go.mod
go.sum
openapi
makefile
Readme
Unit test

Also, please add the Dockerfile as well.

@supreeth7 Thanks for the review, I have updated and incorporated changes, can you please take a look.

/lgtm

/hold
Can you add build-in-container build-static: clean, build: clean, build-image targets to the Makefile as well?

/unhold
/approve

/lgtm
/approve

/hold
Now that the CI is working, please fix the tests.

/remove lgtm ?

/retest

/retest

/retest

For cache error during lint: Add GOCACHE=/tmp/ to the Makefile perhaps.

/retest

/retest

/retest

/retest

/lgtm
/approve

/unhold

/lgtm
Testing for label to see if problem similar to cli repo suffices.

repo: openshift/backplane-api


text:
Fetch Backplane API URL via OCM environment

What type of PR is this?
feature
What this PR does / Why we need it?
This PR automatically detect the backplane URL via OCM env and users don't need set BP API URL in the config file
Which Jira/Github issue(s) does this PR fix?
https://issues.redhat.com/browse/OSD-19188
Resolves #
Special notes for your reviewer
How to test
step 1

delete the URL setting from config file
Login prod/stg/int env clusters and check other bp-cli commands ( eg cloud console)

step2

Keep URL setting in the config file
It will override via ocm env URL and warn users

step3

Set BP API URL via env vars ( for ISV's )
env BP API has high priority over OCM env

Pre-checks (if applicable)

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

Codecov Report

Merging #281 (6f5edc4) into main (52a842d) will decrease coverage by 0.01%.
The diff coverage is 50.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #281      +/-   ##
==========================================
- Coverage   46.83%   46.83%   -0.01%
==========================================
  Files          53       53
  Lines        3540     3566      +26
==========================================
+ Hits         1658     1670      +12
- Misses       1621     1634      +13
- Partials      261      262       +1

Files
Coverage Δ

pkg/cli/config/config.go
60.56% <71.42%> (-0.55%)
:arrow_down:

pkg/ocm/ocmWrapper.go
0.00% <0.00%> (ø)

... and 1 file with indirect coverage changes

authors: codecov-commenter samanthajayasinghe

repo: openshift/backplane-cli


text:
Clarify installation steps

What?
Default to putting backplane-tools ahead in path, as it is expected installing backplane-tools manages your binaries.

/lgtm

repo: openshift/backplane-tools


text:
BUILD-278: Check cgroup v1 and cgroup v2 Files for Quota

/assign @adambkaplan
/assign @nalind
there was no existing unit testing around GetCGroupLimits() or readIn64 that I saw
the simplicity of the fix did not motivate me to take that on, but of course am curious on your respective takes

I think that is all your comments @nalind thanks

updates pushed @kolyshkin @nalind ptal thanks

per @rphillips cgroupsv2 support is out wrt openshift and it is "too soon" to drop this in.... QE has now "user acceptable" form for installing openshift with cgroupsv2
I'm going to
/hold
this vs. closing for now to make it easier to find and resuscitate this when in fact cgroupsv2 gets officially into openshift plan pipeline
thanks again @kolyshkin for you assistance

/retitle BUILD-278: Check cgroup v1 and cgroup v2 Files for Quota

@vrutkovs mentioned in bz 1949438 that at the moment cgroupsv2 is tech preview for 4.9

CI is not ready for it yet

CI job to test this is added in https://github.com/openshift/release/pull/19115, I suppose this is good to go in 4.9 now?

/hold cancel
I imagine we need to merge this for the cgroupsv2 jobs to go green.

last I heard @adambkaplan about this was https://github.com/openshift/builder/pull/246#issuecomment-853860972 and a ping from @rphillips where he said CI was not ready for cgroupsv2
just double checking are you aware with master branch opening up for 4.9 where the install changes needed for CI (and test for that matter) to get this are in place?

just double checking are you aware with master branch opening up for 4.9 where the install changes needed for CI (and test for that matter) to get this are in place?

Yes - ack that we won't have CI running this end to end until we can install with cgroupsv2.

Hey @kolyshkin @nalind : so @vrutkovs is trying some cgroupv2 CI rehearsals over with PR
In that PR, where presumably cgroupv2 is set up correctly, I can confirm in the logs that our us our use of the openshicontainers/runc API is kicking in at
https://github.com/openshift/builder/blob/814bbb090228374742e31889c7fe3df0c3662c7a/pkg/build/builder/util_linux.go#L19-L21
because I see the code picking /sys/fs/cgroup/memory.max as the file to access.
However, we are ultimately getting error logs like
2021-07-12T09:05:29.940355077Z error: failed to retrieve cgroup limits: cannot determine cgroup limits: open /sys/fs/cgroup/memory.max: no such file or directory
Did we get the name of the file wrong?
We currently do not assume the file is there with https://github.com/openshift/builder/blob/814bbb090228374742e31889c7fe3df0c3662c7a/pkg/build/builder/util_linux.go#L26-L28 but perhaps seeing if /sys/fs/cgroup not existing is an insufficient check for ignoring the lack of /sys/fs/cgroup/memory.max ?
Or do you see something in the test setup @vrutkovs has ?
I could start adding (short term/temporary) debug in that path to display the full contents of /sys/fs.cgroup but I decided to pull you guys in first and get any possibly quick sanity checks from you all.
@adambkaplan fyi
thanks

edited my prior comment with the link to @vrutkovs 's test enablement PR

Here's what I see on the node:
$ oc debug node/ip-10-0-140-154.ec2.internal
Starting pod/ip-10-0-140-154ec2internal-debug ...
To use host binaries, run `chroot /host`
chroot /host
Pod IP: 10.0.140.154
If you don't see a command prompt, try pressing enter.
sh-4.4# chroot /host
sh-4.4# cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-20246fb86657495594dfd90b85bcfa58f8a400916e1580611a5b7ea95e77f783/vmlinuz-4.18.0-305.7.1.el8_4.x86_64 random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ostree=/ostree/boot.0/rhcos/20246fb86657495594dfd90b85bcfa58f8a400916e1580611a5b7ea95e77f783/0 ignition.platform.id=aws root=UUID=12afac90-6b11-458a-9f0b-1f5303f2b1f9 rw rootflags=prjquota systemd.unified_cgroup_hierarchy=1
sh-4.4# ls -la /sys/fs/cgroup/
total 0
dr-xr-xr-x.  6 root root 0 Jul 12 15:51 .
drwxr-xr-x.  9 root root 0 Jul 12 15:50 ..
-r--r--r--.  1 root root 0 Jul 12 15:50 cgroup.controllers
-rw-r--r--.  1 root root 0 Jul 12 15:51 cgroup.max.depth
-rw-r--r--.  1 root root 0 Jul 12 15:51 cgroup.max.descendants
-rw-r--r--.  1 root root 0 Jul 12 15:50 cgroup.procs
-r--r--r--.  1 root root 0 Jul 12 15:51 cgroup.stat
-rw-r--r--.  1 root root 0 Jul 12 16:12 cgroup.subtree_control
-rw-r--r--.  1 root root 0 Jul 12 15:51 cgroup.threads
-rw-r--r--.  1 root root 0 Jul 12 15:51 cpu.pressure
-r--r--r--.  1 root root 0 Jul 12 15:51 cpuset.cpus.effective
-r--r--r--.  1 root root 0 Jul 12 15:51 cpuset.mems.effective
drwxr-xr-x.  2 root root 0 Jul 12 15:50 init.scope
-rw-r--r--.  1 root root 0 Jul 12 15:51 io.pressure
-r--r--r--.  1 root root 0 Jul 12 15:51 io.stat
drwxr-xr-x.  4 root root 0 Jul 12 15:51 kubepods.slice
-rw-r--r--.  1 root root 0 Jul 12 15:51 memory.pressure
-r--r--r--.  1 root root 0 Jul 12 15:51 memory.stat
drwxr-xr-x. 77 root root 0 Jul 12 15:50 system.slice
drwxr-xr-x.  2 root root 0 Jul 12 15:51 user.slice

And in the container:
$ oc run fedora --image=quay.io/fedora/fedora:34 --command -- sleep infinity
pod/fedora created
$ oc exec -ti fedora -- sh
sh-5.0# ls -la /sys/fs/cgroup/
total 0
drwxr-xr-x.  2 root root 0 Jul 12 16:15 .
drwxr-xr-x. 10 root root 0 Jul 12 16:15 ..
-r--r--r--.  1 root root 0 Jul 12 16:15 cgroup.controllers
-r--r--r--.  1 root root 0 Jul 12 16:15 cgroup.events
-rw-r--r--.  1 root root 0 Jul 12 16:15 cgroup.freeze
-rw-r--r--.  1 root root 0 Jul 12 16:15 cgroup.max.depth
-rw-r--r--.  1 root root 0 Jul 12 16:15 cgroup.max.descendants
-rw-r--r--.  1 root root 0 Jul 12 16:15 cgroup.procs
-r--r--r--.  1 root root 0 Jul 12 16:15 cgroup.stat
-rw-r--r--.  1 root root 0 Jul 12 16:15 cgroup.subtree_control
-rw-r--r--.  1 root root 0 Jul 12 16:15 cgroup.threads
-rw-r--r--.  1 root root 0 Jul 12 16:15 cgroup.type
-rw-r--r--.  1 root root 0 Jul 12 16:15 cpu.max
-rw-r--r--.  1 root root 0 Jul 12 16:15 cpu.pressure
-r--r--r--.  1 root root 0 Jul 12 16:15 cpu.stat
-rw-r--r--.  1 root root 0 Jul 12 16:15 cpu.weight
-rw-r--r--.  1 root root 0 Jul 12 16:15 cpu.weight.nice
-rw-r--r--.  1 root root 0 Jul 12 16:15 cpuset.cpus
-r--r--r--.  1 root root 0 Jul 12 16:15 cpuset.cpus.effective
-rw-r--r--.  1 root root 0 Jul 12 16:15 cpuset.cpus.partition
-rw-r--r--.  1 root root 0 Jul 12 16:15 cpuset.mems
-r--r--r--.  1 root root 0 Jul 12 16:15 cpuset.mems.effective
-r--r--r--.  1 root root 0 Jul 12 16:15 hugetlb.1GB.current
-r--r--r--.  1 root root 0 Jul 12 16:15 hugetlb.1GB.events
-r--r--r--.  1 root root 0 Jul 12 16:15 hugetlb.1GB.events.local
-rw-r--r--.  1 root root 0 Jul 12 16:15 hugetlb.1GB.max
-r--r--r--.  1 root root 0 Jul 12 16:15 hugetlb.2MB.current
-r--r--r--.  1 root root 0 Jul 12 16:15 hugetlb.2MB.events
-r--r--r--.  1 root root 0 Jul 12 16:15 hugetlb.2MB.events.local
-rw-r--r--.  1 root root 0 Jul 12 16:15 hugetlb.2MB.max
-rw-r--r--.  1 root root 0 Jul 12 16:15 io.bfq.weight
-rw-r--r--.  1 root root 0 Jul 12 16:15 io.latency
-rw-r--r--.  1 root root 0 Jul 12 16:15 io.max
-rw-r--r--.  1 root root 0 Jul 12 16:15 io.pressure
-r--r--r--.  1 root root 0 Jul 12 16:15 io.stat
-r--r--r--.  1 root root 0 Jul 12 16:15 memory.current
-r--r--r--.  1 root root 0 Jul 12 16:15 memory.events
-rw-r--r--.  1 root root 0 Jul 12 16:15 memory.high
-rw-r--r--.  1 root root 0 Jul 12 16:15 memory.low
-rw-r--r--.  1 root root 0 Jul 12 16:15 memory.max
-rw-r--r--.  1 root root 0 Jul 12 16:15 memory.min
-rw-r--r--.  1 root root 0 Jul 12 16:15 memory.oom.group
-rw-r--r--.  1 root root 0 Jul 12 16:15 memory.pressure
-r--r--r--.  1 root root 0 Jul 12 16:15 memory.stat
-r--r--r--.  1 root root 0 Jul 12 16:15 memory.swap.current
-r--r--r--.  1 root root 0 Jul 12 16:15 memory.swap.events
-rw-r--r--.  1 root root 0 Jul 12 16:15 memory.swap.high
-rw-r--r--.  1 root root 0 Jul 12 16:15 memory.swap.max
-r--r--r--.  1 root root 0 Jul 12 16:15 pids.current
-r--r--r--.  1 root root 0 Jul 12 16:15 pids.events
-rw-r--r--.  1 root root 0 Jul 12 16:15 pids.max
-r--r--r--.  1 root root 0 Jul 12 16:15 rdma.current
-rw-r--r--.  1 root root 0 Jul 12 16:15 rdma.max

Thanks @vrutkovs - certainly helpful
So the current call for cgroup stuff is in the build pod, when it is prepping the build container, which is potentially different than both your node snapshot (where memory.max is missing) and your direct fedora container invocation snaphsot (where memory.max is present).
Certainly in both, /sys/fs/cgroup/ exists.
The reasonable assumption based on the behavior exhibited would be that the build pod looks like the node.  A dir structure like the node would result in the behavior exhibited.
My sense is that we should still verify the contents while in the build pod.  But assuming it is like the node, then get agreement when /sys/fs/cgroup exists, but memory.max does not, we assume that this the "default" case.
But I do not consider myself an SME here and would like some consensus / confirmation from @kolyshkin @nalind @adambkaplan

I've created https://github.com/openshift/builder/pull/252 to potentially address the results of @vrutkovs 's CI testing attempt and move the associated discussion to a open vs. merged PR

authors: adambkaplan gabemontero vrutkovs

repo: openshift/builder


text:
CFE-755: Support cluster-wide egress proxy injection

Description
This PR adds egress proxy injection support to the operator. Proxy environment variables will now be propagated to the operand from the operator deployment. This PR also provides an option to provide custom trusted CA certificates.

pkg/controller/deployment/cert_manager_cainjector_deployment.go, pkg/controller/deployment/cert_manager_controller_set.go, pkg/controller/deployment/cert_manager_controller_deployment.go and pkg/controller/deployment/cert_manager_webhook_deployment.go : Fix informers arg names and pass trusted CA configmap at runtime.
pkg/controller/deployment/deployment_overrides.go : Add 2 new deployment hooks to inject proxy env variables and inject trusted CA configmap as a volume.
pkg/controller/deployment/generic_deployment_controller.go : Add configmap informers to re-sync deployments (watch configmaps in the operand namespace).

/cc @xingxingxia

I'm executing below to try pre-merge testing:
launch openshift/cert-manager-operator#103 aws,proxy

If stuck due to whatever, will label directly to unblock merge, and test after merge.
But it is better to always have Dev peer's /lgtm label first, as openshift other components repos' PRs do, before qe test starts involved : )

launch openshift/cert-manager-operator#103 aws,proxy failed due to unknown readon.
Then used this approach to pre-merge test: executed launch openshift/cert-manager-operator#103, got the env, pulled down the catalog image, pushed to my quay.io repo, then used QE's Jenkins Flexy-install job to install a disconnected env with https_proxy,  and installed this catalog from my quay.io repo, then installed cert-manager-operator from it. Done pre-merge testing with this https_proxy env:
[xxia@2023-02-16 20:36:57 CST my]$ oc get po -n cert-manager-operator
NAME                                                        READY   STATUS    RESTARTS   AGE
cert-manager-operator-controller-manager-76cf859cb7-qwvr7   2/2     Running   0          111s
[xxia@2023-02-16 20:37:10 CST my]$ oc get po -n cert-manager-operator cert-manager-operator-controller-manager-76cf859cb7-qwvr7 -o yaml
...
    env:
    - name: HTTP_PROXY
      value: http://<user>:<password>@10.0.152.122:3128
    - name: HTTPS_PROXY
      value: https://<user>:<password>@10.0.152.122:3130
    - name: NO_PROXY
      value: .cluster.local,.svc,10.0.0.0/16,10.128.0.0/14,127.0.0.1,172.30.0.0/16,api-int.<cluster-domain>,localhost,test.no-proxy.com

They are same as oc get proxy -o yaml.
[xxia@2023-02-16 20:35:04 CST my]$ oc get po -n cert-manager
NAME                                      READY   STATUS    RESTARTS   AGE
cert-manager-6f96c79f9b-mzn4v             1/1     Running   0          31s
cert-manager-cainjector-674cfc967-8qwdw   1/1     Running   0          67s
cert-manager-webhook-5fd545966f-2q6f6     1/1     Running   0          69s

[xxia@2023-02-16 20:40:35 CST my]$ for i in cert-manager-6f96c79f9b-mzn4v cert-manager-cainjector-674cfc967-8qwdw cert-manager-webhook-5fd545966f-2q6f6 ; do oc get po $i -n cert-manager -o yaml > pod-cluster-bot-pr103-$i.yaml ; done
[xxia@2023-02-16 20:40:43 CST my]$ vi -p pod-cluster-bot-pr103-cert-manager-*.yaml
...
    env:
    - name: HTTPS_PROXY
      value: https://<user>:<password>@10.0.152.122:3130
    - name: HTTP_PROXY
      value: http://<user>:<password>@10.0.152.122:3128
    - name: NO_PROXY
      value: .cluster.local,.svc,10.0.0.0/16,10.128.0.0/14,127.0.0.1,172.30.0.0/16,api-int.<cluster-domain>,localhost,test.no-proxy.com
...
    - name: http_proxy
      value: http://<user>:<password>@10.0.152.122:3128
    - name: https_proxy
      value: https://<user>:<password>@10.0.152.122:3130
    - name: no_proxy
      value: .cluster.local,.svc,10.0.0.0/16,10.128.0.0/14,127.0.0.1,172.30.0.0/16,api-int.<cluster-domain>,localhost,test.no-proxy.com

In all 3 pods, there are both upper case and lower case proxy env vars ^^
[xxia@2023-02-16 20:42:15 CST my]$ oc -n cert-manager-operator patch subscription cert-manager-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}}'
[xxia@2023-02-16 20:42:58 CST my]$ oc get po -n cert-manager-operator
NAME                                                       READY   STATUS    RESTARTS   AGE
cert-manager-operator-controller-manager-7b4bc96d9-wmtft   2/2     Running   0          68s
[xxia@2023-02-16 20:44:19 CST my]$ oc get po -n cert-manager
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-85b7988d98-8mqpx              1/1     Running   0          30s
cert-manager-cainjector-744c47c447-fhntr   1/1     Running   0          30s
cert-manager-webhook-54bbfd9797-z8k29      1/1     Running   0          30s
[xxia@2023-02-16 20:44:33 CST my]$ for i in cert-manager-85b7988d98-8mqpx cert-manager-cainjector-744c47c447-fhntr cert-manager-webhook-54bbfd9797-z8k29 ; do oc get po $i -n cert-manager -o yaml > pod-cluster-bot-pr103-after-ce-injection-$i.yaml ; done
[xxia@2023-02-16 20:45:22 CST my]$ vi -p pod-cluster-bot-pr103-after-ce-injection-cert-manager-*
  volumes:
  - configMap:
      defaultMode: 420
      name: trusted-ca
    name: trusted-ca
...
    volumeMounts:
    - mountPath: /etc/pki/tls/certs/cert-manager-tls-ca-bundle.crt
      name: trusted-ca
      subPath: ca-bundle.crt

In all 3 pods, there are both upper case and lower case proxy env vars ^^
Then test functions, self-signed issuer, CA issuer, ACME http01 solver issuer with external server https://acme-v02.api.letsencrypt.org/directory outside of the proxy and certificates, they work well.
So adding qe label:
/label qe-approved

/lgtm

Fixes CM-37

/cc @davemulford

/label px-approved

authors: TrilokGeer davemulford thejasn xingxingxia

repo: openshift/cert-manager-operator


text:
Limited CHGM alert resolve investigations to clusters that have the CHGM LS reason

What?

Limited CAD CHGM resolve investigation to clusters that CAD put into LS itself, as we everything else is a NOOP for CAD.
Renamed LimitedSupportReasonExists to IsInLimitedSupport to make the function names less confusing

Why?
This change allows us to use less resources for CAD pipelines and removes unnecessary long pipeline runs.
https://redhat-internal.slack.com/archives/C04PN0YCWGL/p1676498065888859?thread_ts=1676463360.065339&cid=C04PN0YCWGL

/retest


text:
Device plugin

This PR is a WIP, and is based on top of @bn222 2 PR's, which should be merged prior to this.

@bn222 please review as well.
Please only look at latest commit, I kept all changes in one for you.

/ok-to-test

/close

repo: openshift/dpu-operator


text:
Support patching installer manifests

With this change, you can use new API field
ClusterDeployment.Spec.Provisioning.CustomizationRef to point to a ClusterDeploymentCustomization (hereinafter "CDC") object in the same namespace as the ClusterDeployment (CD).
CDC accepts a new subfield, Spec.InstallerManifestPatches, which consists of:

Glob: a string representing a file glob, relative to the installer working directory, matching one or more manifest files.
Patches: a list of PatchEntity representing RFC6902 JSON patches to apply to the matched manifest(s)

Note that CDC was already being used by ClusterPool-owned CDs to allow patching the install-config generated from the template referred to by ClusterPool.Spec.InstallConfigSecretTemplateRef. With this change, ClusterPool-owned CDs using Inventory can start to include manifest patches by simply including the new InstallerManifestPatches field.
TODO: Above is only useful when a) using Inventory; and b) different patches need to be made to each CD. Add the ability to specify a ClusterPool-wide CDC (in addition).
HIVE-1793

/test e2e

This is going well:
efried@efried-thinkpadp16vgen1:~/go/src/github.com/openshift/hive$ oc get cd efried416 -o yaml | yq r - spec.provisioning.customizationRef
name: mycdc

mycdc looks like:
apiVersion: hive.openshift.io/v1
kind: ClusterDeploymentCustomization
metadata:
  name: mycdc
  namespace: efried
spec:
  installerManifestPatches:
  - manifestSelector:
      glob: cluster-api/*/*machine*.yaml
    patches:
    - op: add
      path: /metadata/labels
      valueJSON: |
        {"efried.openshift.io/foo": "bar"}

The installmanager logs include:
time="2024-11-09T23:44:50Z" level=info msg="Found 1 InstallerManifestPatch entries from ClusterDeployment.Spec.CustomizationRef mycdc" installID=qgwtrjmj
time="2024-11-09T23:44:50Z" level=info msg="manifest patch glob 0 (cluster-api/*/*machine*.yaml) matched 8 files" installID=qgwtrjmj
time="2024-11-09T23:44:50Z" level=info msg="patching manifest /output/cluster-api/machines/10_inframachine_efried416-ttb8s-bootstrap.yaml" installID=qgwtrjmj
time="2024-11-09T23:44:50Z" level=info msg="patching manifest /output/cluster-api/machines/10_inframachine_efried416-ttb8s-master-0.yaml" installID=qgwtrjmj
time="2024-11-09T23:44:50Z" level=info msg="patching manifest /output/cluster-api/machines/10_inframachine_efried416-ttb8s-master-1.yaml" installID=qgwtrjmj
time="2024-11-09T23:44:50Z" level=info msg="patching manifest /output/cluster-api/machines/10_inframachine_efried416-ttb8s-master-2.yaml" installID=qgwtrjmj
time="2024-11-09T23:44:50Z" level=info msg="patching manifest /output/cluster-api/machines/10_machine_efried416-ttb8s-bootstrap.yaml" installID=qgwtrjmj
time="2024-11-09T23:44:50Z" level=info msg="patching manifest /output/cluster-api/machines/10_machine_efried416-ttb8s-master-0.yaml" installID=qgwtrjmj
time="2024-11-09T23:44:50Z" level=info msg="patching manifest /output/cluster-api/machines/10_machine_efried416-ttb8s-master-1.yaml" installID=qgwtrjmj
time="2024-11-09T23:44:50Z" level=info msg="patching manifest /output/cluster-api/machines/10_machine_efried416-ttb8s-master-2.yaml" installID=qgwtrjmj

and a sample manifest in the in-progress provision pod was correctly patched:
apiVersion: cluster.x-k8s.io/v1beta1
kind: Machine
metadata:
  creationTimestamp: null
  labels:
    efried.openshift.io/foo: bar    # <=== L@@K
  name: efried416-ttb8s-master-0
spec:
  bootstrap:
    dataSecretName: efried416-ttb8s-master
  clusterName: efried416-ttb8s
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
    kind: AWSMachine
    name: efried416-ttb8s-master-0
status:
  bootstrapReady: false
  infrastructureReady: false

I just need to test the clusterpool path (and maybe noodle how the error conditions manifest) and we'll be good to land this.

/cc @abraverm

In Clusterpool we do reservation of the CDC, should this mechanism somewhat migrate/copied to CD controller?

In Clusterpool we do reservation of the CDC, should this mechanism somewhat migrate/copied to CD controller?

For pool inventory, reserving CDCs makes sense because they're intended to enable exclusive/unique settings such as reserved IP addresses. And manifest-patching CDCs used for inventory will still be subject to reservation as usual. But for this use case -- CDs' CustomizationRef-named CDCs -- I think we explicitly want manifest patching to be usable by multiple CDs without restriction. Does that make sense?

repo: openshift/hive


text:
HOSTEDCP-1200: remove catalog exception from EnsureNoCrashingPods

What this PR does / why we need it:
remove the catalog exception from EnsureNoCrashingPods

unable to reproduce the issue so removing the exception for now

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 # HOSTEDCP-1200
Checklist

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

/retest-required

/retest-require

/retest-required

repo: openshift/hypershift


text:
"Trigger OpenShift Deployment" should accept an image tag

As documented:
"Trigger OpenShift Deployment": performs the equivalent of an oc deploy --latest command invocation; it will monitor the resulting ReplicationController's "openshift.io/deployment.phase" annotation to confirm success
Defaulting the oc deploy command to use --latest seems a bit limiting. What i'd like to be able to do is build an image, perform a successful deployment to a development environment, tag the image, then make sure this tag of the image is progressed through subsequent environments. How would one deploy an older version of an image? At the moment it wouldn't be possible without modifying the deployment config. What if a new latest image makes it's way into the registry while a deployment is awaiting approval to deploy to an environment?
Please forgive me if i've missed something here.
Thanks

you would tag an older version of the image into the imagestream that the deployment is based on, and trigger a deployment to deploy it.
i don't know what else you'd expect triggering a deployment to do, oc deploy does not offer a "deploy this image" option.  deployments deploy the thing they are pointing at, if you want to deploy something else, you have to change either what they are pointing at, or the thing they point to.

okay so if i'm understanding correctly, to achieve what i'm after, once i verify a deployment to a DEV environment is successful i should tag the image into a new imagestream and have (for example) the 'SIT' DeploymentConfig with a Trigger listening to image changes on the new imagestream? So we have separate ImageStreams for each target deployment environment/namespace?
I'm trying to wrap my head around how to progress an image through a deployment lifecycle, i.e. from build through various environments and gates then through to production. Having a separate image stream for each is a new concept, pre-openshift you would handle this with image tags.
I realise this is largely a deployment architecture question and i'm likely asking this in the wrong place.

once i verify a deployment to a DEV environment is successful i should tag the image into a new imagestream and have (for example) the 'SIT' DeploymentConfig with a Trigger listening to image changes on the new imagestream?

that would be a very typical way to set things up, yes.

So we have separate ImageStreams for each target deployment environment/namespace?

or at least separate ImageStreamTags within the ImageStream
you may find this doc of interest (still a work in progress):  https://github.com/gabemontero/openshift-docs/blob/6a77acd34de23a9164b9940c83089d85a3502b31/dev_guide/application_lifecycle/application_promotion.adoc

you can also take a look at our sample jenkins job which does promotion from dev to prod:
https://github.com/openshift/jenkins/blob/master/2/contrib/openshift/configuration/jobs/OpenShift Sample/config.xml
there is a tutorial associated w/ that job here:
https://github.com/openshift/origin/tree/master/examples/jenkins
and the summary of what the job does when run:
It will trigger an OpenShift build of the application, wait for the build to result in a deployment, confirm the new deployment works, and then tag the image for production. This tagging will trigger another deployment, this time creating/updating the production service.

Thanks a lot for your help Ben.I suppose wrapping your head around the reliance on image streams to trigger deployments m is one of the fundamental things here. We ended up following a similar approach to the one you describe. Build and deploy an image to a development environment, execute sufficient tests and verifications, tag the image with the Jenkins build number,m. When we want to promote to any other environment we just again tag that image with 'environment name' (I.e. sit). We then have a deployment config listening for new instance of this image.Working well so far. Again many thanks for your help.
_____________________________
From: Ben Parees notifications@github.com
Sent: Thursday, November 17, 2016 9:23 am
Subject: Re: [openshift/jenkins-plugin] "Trigger OpenShift Deployment" should accept an image tag (#114)
To: openshift/jenkins-plugin jenkins-plugin@noreply.github.com
Cc: Author author@noreply.github.com, Andy Evans andyevans85@gmail.com
you can also take a look at our sample jenkins job which does promotion from dev to prod:
https://github.com/openshift/jenkins/blob/master/2/contrib/openshift/configuration/jobs/OpenShift Sample/config.xml
there is a tutorial associated w/ that job here:
https://github.com/openshift/origin/tree/master/examples/jenkins
and the summary of what the job does when run:It will trigger an OpenShift build of the application, wait for the build to result in a deployment, confirm the new deployment works, and then tag the image for production. This tagging will trigger another deployment, this time creating/updating the production service.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

yup, imagestreams and deployments and the relationship between them are fundamental building blocks for the platform.  Glad to help!

authors: andyevans bparees

repo: openshift/jenkins-plugin

license_source: bigquery


text:
Is there an easy way to upgrade the Maven version for the maven slave?

In the Docker file for the maven slave image it has
ENV MAVEN_VERSION=3.0.5
The maven version required by the fabric8 goals I think needs to be higher than this
https://github.com/fabric8io/fabric8-maven-plugin/issues/556
It seems a bit onerous to go the s2i route to create a new Jenkins Maven Slave image with an updated ENV variable? Is there an easier way?
I tried setting an environment variable on the jenkins deployment config but it isn't picked up by the slave (which didn't suprise me!).
Peter.

the environment variable doesn't control the maven version, it's informational about what maven version was installed when the image was built:
https://github.com/openshift/jenkins/blob/master/slave-maven/Dockerfile#L12
I don't actually remember if there's a good reason we even define it (though as you can see for the centos image, we use it to drive which version we download.  for the rhel image, we don't).
So you are indeed going to have to create a new image if you want a different maven version, not to set the env variable, but to actually install the different package.  (and for rhel, we're installing the most current version provided as an rpm, as far as i know).

authors: bparees petenorth

repo: openshift/jenkins


text:
Add MapToEnvVars helper function

/assign @mfojtik
since you asked for it in https://github.com/openshift/cluster-kube-controller-manager-operator/pull/285#discussion_r328058781 and on top of that we use it in 3 operators: kcm-o, kas-o and oas-o.
/assign @deads2k

@mfojtik updated, ptal

/lgtm

authors: mfojtik soltysh

repo: openshift/library-go


text:
OLS-244: Allow model options (fully optional)

Description
Allow model options (fully optional)
It will be passed to prompt generator (TBD)
Type of change

[ ] Refactor
[x] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[x] Configuration Update
[ ] Bump-up dependent library

Related Tickets & Documents

Related Issue #OLS-244

/retest

/retest

/approve

repo: openshift/lightspeed-service


text:
USHIFT-315: Add swap space to the development environment setup

Add swap space to the development environment setup
Closes: USHIFT-315

/assign @dhellmann

/lgtm

authors: dhellmann ggiguash

repo: openshift/microshift


text:
[release-4.14] OCPBUGS-28871: Capability to override default channel …

This fix address the issues found here .
The TL;DR is that dev teams can change the default channel from one release to the next, this causes customers who have set CICD pipelines to have to change their ImageSetConfig each time a version changes.
This fix allow the use of a field in the ImageSetConfig to override the default channel and specify any channel and use the HEAD (latest version of that channel).
It means that the customer needs to be aware of the caveats not using the default channel when mirroring. This will mean we need to update our documents accordingly. We will work with the docs team as to find the appropriate wording and track (link) the docs issue to this.
Fixes # OCPBUGS-385
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
This has been tested locally and seems to working as expected.
We will need thorough testing from QE to ensure this fix works.
Expected Outcome
The ImageSetConfig used is as follows
apiVersion: mirror.openshift.io/v1alpha2
mirror:
operators:

catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12
packages:

name: elasticsearch-operator
overrideDefaultChannel: true
channels:

name: stable

NB the overrideDefaultChannel flag is at the package level , also there can only be one channel specified.
Use the following cli to execute
bin/oc-mirror --config test-isc.yml file://
The head of the current channel "stable" is version "elasticsearch-operator.v5.8.0"
To verify this
execute the command as shown above
update the ImageSetConfig to use the defaultChannel (HEAD is the same elasticsearch-operator.v5.8.0)
execute the oc command but ensure the contents are save in a different folder
compare folders
The elasticsearch-operator was the operator of interest in the listed JIRA, I also tested using the cluster-logging operator and also got the expected results (also expecting v5.8.0 version).
Maybe QE could look at a random set of operators to verify this on

/label qe-approved

/lgtm

/lgtm

/label backport-risk-assessed

/label backport-risk-assessed

/label cherry-pick-approved

authors: aguidirh lmzuccarelli sherine-k zhouying7780

repo: openshift/oc-mirror


text:
Adding e2e-harness-generate update

What type of PR is this?
(maintenance)
What this PR does / why we need it?
This PR is about updating the e2e requirements as well regarding Go 1.22 such that the image build passes. Right now, it's failing as per https://ci.int.devshift.net/job/openshift-ocm-agent-operator-gh-build-master/222/console and this PR is intended to fix it.
Which Jira/Github issue(s) this PR fixes?
Fixes # OSD-25349

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

Project coverage is 64.22%. Comparing base (742e13a) to head (5cba20a).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #148   +/-   ##
=======================================
  Coverage   64.22%   64.22%
=======================================
  Files          22       22
  Lines        1504     1504
=======================================
  Hits          966      966
  Misses        459      459
  Partials       79       79

/lgtm

authors: a7vicky codecov-commenter ravitri

repo: openshift/ocm-agent-operator


text:
Fixed unit-tests

The global mock variables were being reused in may tests, due to which some tests were
failing to run individually, this commit reuses mock variables by creating a DeepCopy of global mock variables to prevent
modification of global mock variables.
There were multiple duplicate functions to create Fake Scheme for the tests,
this commit keeps only one createFakeScheme function for testing StorageCluster controller.
Above two changes are dependent on each other to make tests run individually and as a whole by make unit-test .
Signed off by: Priyanka Jiandani pjiandan@redhat.com

/retest

/retest

/override ci/prow/ocs-operator-bundle-e2e-aws

repo: openshift/ocs-operator


text:
AWS - S3 task cannot be run more than once

Hi
Im having an issue I dont know how to solve. Basically you cannot run the s3 user tasks more than once and retrieve the required data structure.
If a user exists and this task runs, you do not get the s3user.user_meta data needed to run the subsequent tasks. ie
TASK [s3-registry-user : debug s3] *********************************************
task path: playbooks/roles/s3-registry-user/tasks/main.yaml:9
ok: [localhost] => {
    "s3user": {
        "changed": false,
        "created_keys": [],
        "groups": null,
        "keys": {
            "CHANGED": "Active"
        },
        "user_name": "apim"
    }
}

Which results in
TASK [s3-registry-user : Set fact] *********************************************
task path: playbooks/roles/s3-registry-user/tasks/main.yaml:11
fatal: [localhost]: FAILED! => {
    "failed": true,
    "msg": "the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: 'dict object' has no attribute 'user_meta'\n\nThe error appears to have been in 'playbooks/roles/s3-registry-user/tasks/main.yaml': line 11, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n  debug: var=s3user\n- name: Set fact\n  ^ here\n"
}

This means that any method to add an infra node will fail and any run further run of ose-on-aws.py will not complete due to missing data structures. To get round this could mean pre-creating the s3 user and storing the aws secret and passing in as a param but that seems clunky.

I wonder if we can go the route of  when: s3_user_access is defined and same for the secret

I was just looking at moving this to the cfn template http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-iam-accesskey.html
Generate a secret key in code thats consistent, hash a known value so it doesnt change between runs and doesnt need to be stored. It would simplify playbooks a little by having less to do. Also the user would be removed at stack deletion time.
Im currently trying
---
- name: Create S3 OpenShift registry user
  iam:
    iam_type: user
    name: "{{ s3_username }}"
    state: present
    access_key_state: create
  register: s3user
- name: debug s3
  debug: var=s3user
- name: Set fact
  set_fact: s3user_id="{{ s3user.user_meta.access_keys.0.access_key_id }}"
  when: s3user.changed == 'true'
- name: Set fact
  set_fact: s3user_secret="{{ s3user.user_meta.access_keys.0.secret_access_key }}"
  when: s3user.changed == 'true'
- name: Apply Full S3 privileges to s3 account
  iam_policy:
    iam_name: "{{ s3user.user_meta.access_keys.0.user_name }}"
    iam_type: "user"
    policy_name: S3FullAccess
    policy_json: '{"Version":"2012-10-17","Statement":[{"Action":["s3:*"],"Effect":"Allow","Resource":"*"}]}'
    state: present
  when: s3user.changed == 'true'

and
- name: Generate docker registry config
  template: src="s3_registry.j2" dest="/root/config.yml" owner=root mode=0600
  when: s3user.changed == 'true'

I'll let you know

https://github.com/satterly/AWSCloudFormation-samples/blob/master/IAM_Users_Groups_and_Policies.template

My worry about placing the account in cloudformation that we will lose the variable between the infrastructure hand off and the openshift-install handoff. We could do a meta inventory refresh but just haven't had to cross that road yet.  If we did the S3 user as part of the openshift-install it would create a new stack potentially

According to the template example, we could retrieve the access_key_is and secret_key as an output. If thats true, query the stack outputs and register the facts in the s3user variable. All speculation at this point tho :)

Hmm standby for 1 day. I'm currently testing some code from @abutcher similar to this that might move around some ordering so ill check in tomorrow.

Ack that

@stuartbfox this doesn't resolve the S3 name issue but I wanted to keep you aware. https://github.com/openshift/openshift-ansible/pull/2624
As for requesting the information from cloudformations. The only part I worry about is if someone has cloudformation access then they can click the outputs tab and see the id and secret. Although it probably doesn't matter that much as its just an S3 account.
I wonder if using something to your variable of vars/main.yaml  in the other PR if we could have the S3 access and secret defined in the vars/file if not defined then one will be created at run time

I have a rough prototype of using cfn to create the user/policy/bucket. You are correct on someone having output views on the stack would have the access keys. My preference would be for cfn to handle as much as possible and less "do before" steps

I'm wondering if the cfn template will also suffer from the same issue with accessing the keys, since I think they are only reference-able on creation. If it doesn't, then I think that would be the preferable approach, with the limitation that the policy is limited to a specific bucket that is configurable.

No, the stack output is available even if the stack is already created and unchanged. I followed this
https://github.com/ansible/ansible-examples/blob/master/language_features/cloudformation.yaml
and reference stack.stack_outputs in the docker playbooks

POC in this branch here https://github.com/stuartbfox/openshift-ansible-contrib/pull/3/files

@stuartbfox the S3 work is really solid from testing today. I stood up two stacks at once and was installing.  We would need to catch up #39 and potentially add in the fixes I suggested + i'd have to turn some documentation around but with the cloudformation lookup work you have done its some pretty awesome work.

Good to know, thanks :)
I think some of the jinja templating in #39 should probably be ditched in favour of the ASG work @detiber is doing. The multi-stack, configurable vars_file and custom_template stuff is very useful in my use cases tho

Awesome. Ill probably run through this Sunday/monday. Does this require
boto3 or was that another thing you were working on?
On Oct 21, 2016 5:51 PM, "Stuart Fox" notifications@github.com wrote:

POC in this branch here https://github.com/stuartbfox/
openshift-ansible-contrib/pull/3/files
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/openshift-ansible-contrib/issues/43#issuecomment-255474145,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADoslCGqppLRYbF-SJY7l1Y9i0X-siOXks5q2TPlgaJpZM4KaNNg
.

Boto3 was only required by cloudformation_facts

authors: cooktheryan detiber stuartbfox

repo: openshift/openshift-ansible-contrib


text:
Bump Prometheus to v2.24.0

Bumping to v2.24.0 fixes the following unit test failure:
--- FAIL: TestHandleMultipleQuitRequests (5.00s)
    web_test.go:492:
        	Error Trace:	web_test.go:492
        	            				asm_amd64.s:1374
        	Error:      	Received unexpected error:
        	            	Post "http://localhost:9090/-/quit": EOF
        	Test:       	TestHandleMultipleQuitRequests
    web_test.go:492:
        	Error Trace:	web_test.go:492
        	            				asm_amd64.s:1374
        	Error:      	Received unexpected error:
        	            	Post "http://localhost:9090/-/quit": EOF
        	Test:       	TestHandleMultipleQuitRequests
FAIL
FAIL	github.com/prometheus/prometheus/web	15.159s

while we are not bound to feature freeze i'd say we wait until master for 4.8 opens, wdyt @simonpasquier ?

while we are not bound to feature freeze i'd say we wait until master for 4.8 opens, wdyt @simonpasquier ?

@s-urbaniak sgtm

@s-urbaniak sgtm

:+1: holding until 4.8 opens
/hold

:+1: holding until 4.8 opens
/hold

@s-urbaniak @simonpasquier, should we reconsider the hold on this bump since code-freeze was delayed?

@s-urbaniak @simonpasquier, should we reconsider the hold on this bump since code-freeze was delayed?

I think the hold is still valid.

I think the hold is still valid.

Unholding since 4.8 is now open.
/unhold

/lgtm

authors: dgrisonnet s-urbaniak simonpasquier

repo: openshift/prometheus


text:
OCPQE-24207 don't specify env var RELEASE_IMAGE_LATEST for arm nightly

if payload is nightly build, don't add amd64 build as RELEASE_IMAGE_LATEST
e.g. https://qe-private-deck-ci.apps.ci.l2s4.p1.openshiftapps.com/view/gs/qe-private-deck/logs/periodic-ci-openshift-openshift-tests-private-release-4.16-arm64-nightly-aws-ipi-private-f28-disasterrecovery/1816453416201752576

/cc @jianzhangbjz

/cc @wangke19

/approve
/lgtm

authors: jianzhangbjz rioliu-rh

repo: openshift/release-tests


text:
Update Minishift install guide to match the latest Minishift version released

$ minishift version
minishift v1.4.1+0f658ea

resolved in PR #450

repo: openshiftio/appdev-documentation


text:
Issue #425: Fix runtime guide links in additional resources sections

Fixed the Github repo links. The conditional links now point to their corresponding runtime guide sections.
NOTE: I ended up doing a couple consistency fixes, too:

Changed the guide names in the links in the CRUD resources topic to variables
Created a variable for the circuit breaker guide link in document-attributes.adoc
included the conditional links in the Circuit Breaker resources topic

Resolves #425

LGTM, merging.

merged: 252984e77e1ad693621401d9655e5403a3fcee30


text:
Tools > Forward Dynamics... > Save... saves an empty ("default") setup file

Steps to reproduce

Open Tools > Forward Dynamics...
Set the "Initial State field to "blah".
Click Save... and save the setup file somewhere.
Open the saved setup file in a text editor.

Expected result

Setup file contains the text "blah" somewhere.

Actual result

Setup file is "empty"

<?xml version="1.0" encoding="UTF-8" ?>
<OpenSimDocument Version="30517">
	<ForwardTool name="Control Set">
		<!--All properties of this object have their default values.-->
	</ForwardTool>
</OpenSimDocument>

Environment and GUI version
Mac 4.0-2018-11-06-f854814

Weird...I cannot reproduce this.

repo: opensim-org/opensim-gui


text:
Spanish Translation

Hello, I'm interested in contributing for this repo with spanish translations. How can I start?

Hello, @vacilagodzila thank you a lot for being interested in making Spanish translations.
This repo contains the translations for a Cards Corp. marketing web site (translations are located in folders with a cards-marketing- prefix) and the andCards app, which you can access once you logging in.
I just added a short description how to add a new language, in your case - Spanish. It is located here.
We would be very happy and thankful for this help.

Great! I'll get to work on it later in the evening.

Hey, @rtkhanas , should "Republic of Korea" in "3F, 109 Cheongpa-ro,\n Yongsan-gu,\n Seoul 04370,\n Republic of Korea" remain untranslated?

Oh, I see. It's an address. Then "republic of korea" shall be translated. Got it.

Hey, @rtkhanas , is the cards-page- prefix also up for translation?

Hey, @vacilagodzila , yes, basically all the folders here are up for the translation. The ‘cards-page-‘ prefix is used for pages in the andCards application.

authors: rtkhanas vacilagodzila

repo: opensource-cards/translations

license: mit


text:
Making the Website more user friendly for newbies and better expanse.

I just came to know about open source design while exploring how can I contribute to the world of open source as a UI/UX Designer. To be honest, I am still not sure how the website works. There are just too many nav bar menus. I reviewed the issue created for landing page redesign and even that does not address this specific problem. It was more like enhancing and incorporating more features, instead of simplifying things. Also, is the community not as active as it used to be? Do we have newletters? why only 2 meetings a month? do we have communities all around the world? like google cloud has so many communities, for each region. I am from India, and its so hard to find a proper community for designers in the whole India, let alone my city or state.

Hi @MonjimaLahiri, thanks for sharing this! I think you are right – the website has a lot of different sections and it not as user friendly as it could be. Some of this is (in my personal view) the effect of a volunteer organization without a lot of formal hierarchies: Removing things is harder than adding them and over time we might have lost track of what is needed and what WAS needed but is not anymore.
How you could help:

If there is something that seems to be outdated or not useful for readers like you: Please point it out there
If you find text that is hard to understand (jargon, sentence structure), please point it out here or even rewrite and submit a pull request.
Restructuring suggestions are also welcome but as mentioned in the intro not as easy to make.

I would like to work on this issue,  can you please assign it to me?

authors: MonjimaLahiri jdittrich sumitshinde-84