Bump actions/checkout from 4 to 5 - #2
Closed
dependabot[bot] wants to merge 2 commits into
Closed
dependabot[bot] wants to merge 2 commits into
dependabot[bot] wants to merge 2 commits into
Conversation
Bumps [actions/checkout](https://github.com/actions/checkout) from 4 to 5. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v4...v5) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
Bot
deleted the
dependabot/github_actions/actions/checkout-5
branch
September 8, 2025 14:41
akshaynadkarni
added a commit
to akshaynadkarni/enhancement-proposals
that referenced
this pull request
Apr 20, 2026
Clarify in API Extensions and Design Decision osac-project#2 that freeform tier names are the current approach for this proposal. A future proposal addressing tier discovery and StorageClass lifecycle management may introduce validation against the external system that owns the source of truth for valid tier names. Assisted-by: Cursor/Claude
akshaynadkarni
added a commit
to akshaynadkarni/enhancement-proposals
that referenced
this pull request
Apr 22, 2026
Clarify in API Extensions and Design Decision osac-project#2 that freeform tier names are the current approach for this proposal. A future proposal addressing tier discovery and StorageClass lifecycle management may introduce validation against the external system that owns the source of truth for valid tier names. Assisted-by: Cursor/Claude
akshaynadkarni
added a commit
to akshaynadkarni/enhancement-proposals
that referenced
this pull request
Apr 24, 2026
Remove statements that "no tier name is special" since OSAC-shipped templates depend on the tier name "default". Update the Proposal intro, API Extensions, and Design Decisions osac-project#1 and osac-project#2 to consistently reflect this. Add Design Decision osac-project#6 documenting the requirement for a shared StorageClass with tenant: Default, storage-tier: default on every VMaaS cluster, with rationale distinguishing the operational convention from controller-level enforcement. Assisted-by: Cursor/Claude
akshaynadkarni
added a commit
that referenced
this pull request
Apr 24, 2026
#32) * MGMT-23404: add enhancement proposal for tenant storage tiers Proposes extending the tenant-specific StorageClass mechanism to support multiple storage tiers per tenant. Adds an optional osac.openshift.io/storage-tier label to StorageClasses and evolves tenant.status.storageClass (string) to tenant.status.storageClasses (list) so the Tenant controller can resolve all available tiers per tenant. The proposal focuses on the infrastructure layer (labeling, resolution, selection) and describes three consumption strategies (template-driven, user-facing DiskSpec, hybrid) without prescribing one. The initial implementation targets Strategy A (template-driven). Assisted-by: Cursor/Claude Made-with: Cursor * MGMT-23404: trim graduation criteria to N/A OSAC has not been released; graduation milestones are not applicable yet. Assisted-by: Cursor/Claude Made-with: Cursor * MGMT-23404: address CodeRabbit review feedback - Fix contradictory wording: status.storageClass is "retained for backward compatibility" (not "replaced") with the new storageClasses list as the additive canonical representation. - Unify storage-tier value constraint: use "lowercase Kubernetes label value" consistently instead of "lowercase alphanumeric" (which conflicts with the later paragraph allowing dashes/dots/underscores). - Expand "no Default tier" condition to cover both explicitly labeled storage-tier: Default and unlabeled StorageClasses. Assisted-by: Cursor/Claude Made-with: Cursor * MGMT-23404: incorporate review feedback on storage tiers proposal - Make osac.openshift.io/storage-tier label required on all StorageClasses. Controller ignores StorageClasses missing the label. - Remove the capitalized "Default" sentinel for tiers. Tier names are freeform lowercase values; CSPs use "default" by convention. - Remove status.storageClass (singular) entirely instead of deprecating it. status.storageClasses (list) is the only field. - Require tenant_storage_class_storage_tier parameter in Ansible role with no default. Role fails with descriptive error listing available tiers. - Clarify resolution algorithm scoping: only tenant-specific and tenant=Default StorageClasses are considered (no tier leakage). - Add explicit behavior for all-tiers-fail case: Tenant stays Progressing, StorageClassReady=False with failure details. - Resolve all open questions: no required default tier (at least one tier sufficient), freeform tier names, Strategy A (template-driven) only. - Add Design Decisions section capturing resolved questions with rationale. - Add Migration Path section with step-by-step upgrade guidance. - Add upgrade scenario to test plan. - Document rejected alternatives (optional label, deprecated field). Assisted-by: Cursor/Claude * MGMT-23404: make lowercase constraint explicit in tier validation prose The label table already stated tier values must be lowercase, but the detailed validation paragraph omitted that constraint. This adds "lowercase" to the prose so both descriptions are consistent. Assisted-by: Cursor/Claude * MGMT-23404: address CodeRabbit documentation nitpicks Clarify that tenant-axis fallback applies independently per tier while storage-tier axis has no inter-tier fallback. Update the label table header to "Behavior when absent" with "StorageClass ignored" values. Add kubebuilder validation markers to the ResolvedStorageClass struct. Harden the migration script to skip already-labeled StorageClasses and echo progress. Assisted-by: Cursor/Claude * MGMT-23404: add assumptions and tenant readiness criteria Add Assumptions section documenting that external systems maintain the source of truth for valid storage tier names and are responsible for creating and maintaining Tenant StorageClasses. Automation for tier discovery and StorageClass lifecycle will be addressed in a subsequent proposal. Expand StorageClassReady condition to explicitly state that a Tenant cannot reach Ready without at least one StorageClass carrying both required labels. Document the decision to use status reflection rather than admission webhooks for validation, since StorageClass is not an OSAC-owned resource type. Assisted-by: Cursor/Claude * MGMT-23404: note freeform tier names are temporary Clarify in API Extensions and Design Decision #2 that freeform tier names are the current approach for this proposal. A future proposal addressing tier discovery and StorageClass lifecycle management may introduce validation against the external system that owns the source of truth for valid tier names. Assisted-by: Cursor/Claude * MGMT-23404: address Michael's review comments (1, 3, 4) Update tracking-link to MGMT-23669 and last-updated date to 2026-04-20. Rename ResolvedStorageClass fields from storageClassName/storageTier to name/tier per K8s API conventions for named subobjects. The parent storageClasses list already provides the "storage class" context, making the prefixes redundant. Replace "downstream consumers" with "consumers" to avoid directional ambiguity. Assisted-by: Cursor/Claude * MGMT-23404: clarify StorageClass resolution goal Reword the goal to explain why resolution is centralized: so that osac-operator and osac-aap do not each implement the same fallback, duplicate detection, and per-tier grouping logic. Consumers use status.storageClasses to determine which StorageClass to use. Assisted-by: Cursor/Claude * MGMT-23404: inject resolved storageClasses via extra_vars Update the proposal so that the CI controller injects the resolved storageClasses list into the Ansible job extra_vars at trigger time, instead of having the Ansible role query the K8s API for the Tenant CR. The CI controller already fetches the Tenant to verify readiness before triggering. Reading status.storageClasses at that point and passing it through eliminates an uncached K8s API call from Ansible while keeping the resolution logic centralized in the Tenant controller. Assisted-by: Cursor/Claude * MGMT-23404: correct template persona model and add default tier convention Templates are Ansible roles written by OSAC contributors and customized by CSPs, not created by Tenant Admins. Update user stories, personas, and workflows to reflect this. OSAC-shipped templates use the conventional tier name "default" so they work out of the box on any deployment. Every VMaaS cluster must have a shared StorageClass with tenant: Default, storage-tier: default as the baseline. CSPs can override per-tenant and customize templates for specialized tiers like "fast". Remove Strategy A/B/C labels in favor of direct descriptions. Assisted-by: Cursor/Claude * MGMT-23404: update last-updated date to 2026-04-22 Assisted-by: Cursor/Claude * MGMT-23404: surface default tier convention in assumptions and API sections Mention the default tier requirement for OSAC-shipped templates in the Assumptions section, Proposal intro, and API Extensions section so readers encounter it early rather than only in the template convention subsection. Assisted-by: Cursor/Claude * MGMT-23404: make default tier convention consistent throughout proposal Remove statements that "no tier name is special" since OSAC-shipped templates depend on the tier name "default". Update the Proposal intro, API Extensions, and Design Decisions #1 and #2 to consistently reflect this. Add Design Decision #6 documenting the requirement for a shared StorageClass with tenant: Default, storage-tier: default on every VMaaS cluster, with rationale distinguishing the operational convention from controller-level enforcement. Assisted-by: Cursor/Claude * MGMT-23404: decouple default tier requirement from tenant: Default The requirement for OSAC-shipped templates is that a `default` tier resolves for every tenant, not that a shared StorageClass with tenant: Default specifically exists. CSPs can provide this tier either through tenant-specific StorageClasses or through a shared Default StorageClass. Update Assumptions, Proposal intro, API Extensions, template convention, and Design Decisions #5 and #6 to reflect this. Also replace "magic" with "special" or "implicit" throughout. Assisted-by: Cursor/Claude
This was referenced Jul 5, 2026
danmanor
added a commit
to danmanor/enhancement-proposals
that referenced
this pull request
Jul 12, 2026
PRD functional requirements should describe user-observable outcomes, not internal mechanisms. Addresses EP review feedback (Important osac-project#2). Unified PRD: removed fabric manager, K8s manager, dispatcher, ConfigMap, Ansible role, NetworkClass, DNAT/SNAT, proto field names from goals, user stories, and acceptance criteria. BMaaS PRD: FR-8 rewritten to describe outcome (connectivity established, server receives IP) instead of mechanism (switch port configuration, network fabric). FR-11 removes "static configuration string". FR-13 removes "network segment" internals. CaaS PRD: FR-10 removes "first interface with role fabric". Goals and acceptance criteria use "system determines" instead of naming the resolution mechanism. VMaaS PRD: FR-1 removes DNAT/SNAT parentheticals. FR-6 removes "underlying virtualization platform". Cloud Infra Admin story removes "(by deploying a K8s manager)". Default PRD: removed proto field names, enum values, label names, finalizer details, OSAC ticket references from all FRs and acceptance criteria. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Dan Manor <dmanor@redhat.com>
This was referenced Jul 19, 2026
danmanor
added a commit
to danmanor/enhancement-proposals
that referenced
this pull request
Jul 26, 2026
PRD functional requirements should describe user-observable outcomes, not internal mechanisms. Addresses EP review feedback (Important osac-project#2). Unified PRD: removed fabric manager, K8s manager, dispatcher, ConfigMap, Ansible role, NetworkClass, DNAT/SNAT, proto field names from goals, user stories, and acceptance criteria. BMaaS PRD: FR-8 rewritten to describe outcome (connectivity established, server receives IP) instead of mechanism (switch port configuration, network fabric). FR-11 removes "static configuration string". FR-13 removes "network segment" internals. CaaS PRD: FR-10 removes "first interface with role fabric". Goals and acceptance criteria use "system determines" instead of naming the resolution mechanism. VMaaS PRD: FR-1 removes DNAT/SNAT parentheticals. FR-6 removes "underlying virtualization platform". Cloud Infra Admin story removes "(by deploying a K8s manager)". Default PRD: removed proto field names, enum values, label names, finalizer details, OSAC ticket references from all FRs and acceptance criteria. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Dan Manor <dmanor@redhat.com>
masayag
pushed a commit
to masayag/enhancement-proposals
that referenced
this pull request
Jul 27, 2026
PRD functional requirements should describe user-observable outcomes, not internal mechanisms. Addresses EP review feedback (Important osac-project#2). Unified PRD: removed fabric manager, K8s manager, dispatcher, ConfigMap, Ansible role, NetworkClass, DNAT/SNAT, proto field names from goals, user stories, and acceptance criteria. BMaaS PRD: FR-8 rewritten to describe outcome (connectivity established, server receives IP) instead of mechanism (switch port configuration, network fabric). FR-11 removes "static configuration string". FR-13 removes "network segment" internals. CaaS PRD: FR-10 removes "first interface with role fabric". Goals and acceptance criteria use "system determines" instead of naming the resolution mechanism. VMaaS PRD: FR-1 removes DNAT/SNAT parentheticals. FR-6 removes "underlying virtualization platform". Cloud Infra Admin story removes "(by deploying a K8s manager)". Default PRD: removed proto field names, enum values, label names, finalizer details, OSAC ticket references from all FRs and acceptance criteria. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Dan Manor <dmanor@redhat.com>
empovit
pushed a commit
to empovit/osac-enhancement-proposals
that referenced
this pull request
Aug 2, 2026
PRD functional requirements should describe user-observable outcomes, not internal mechanisms. Addresses EP review feedback (Important osac-project#2). Unified PRD: removed fabric manager, K8s manager, dispatcher, ConfigMap, Ansible role, NetworkClass, DNAT/SNAT, proto field names from goals, user stories, and acceptance criteria. BMaaS PRD: FR-8 rewritten to describe outcome (connectivity established, server receives IP) instead of mechanism (switch port configuration, network fabric). FR-11 removes "static configuration string". FR-13 removes "network segment" internals. CaaS PRD: FR-10 removes "first interface with role fabric". Goals and acceptance criteria use "system determines" instead of naming the resolution mechanism. VMaaS PRD: FR-1 removes DNAT/SNAT parentheticals. FR-6 removes "underlying virtualization platform". Cloud Infra Admin story removes "(by deploying a K8s manager)". Default PRD: removed proto field names, enum values, label names, finalizer details, OSAC ticket references from all FRs and acceptance criteria. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Dan Manor <dmanor@redhat.com>
This was referenced Aug 6, 2026
vladikr
added a commit
to vladikr/osac-enhancement-proposals
that referenced
this pull request
Aug 12, 2026
Add Alternative osac-project#2: ServerCluster as top-level peer of VirtualNetwork (uniform isolation model). Documents pros (atomic resize, simpler for uniform deployments), cons (couples fabric lifecycles, non-uniform membership needs multiple objects anyway), and why FabricDomain was chosen (handles both uniform and non-uniform cases; type:multi planned for Phase 2/3 uniform deployments). Renumber remaining alternatives (3-5). Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Vladik Romanovsky <vromanso@redhat.com>
tzvatot
added a commit
to tzvatot/enhancement-proposals
that referenced
this pull request
Aug 13, 2026
Rewrite problem statement osac-project#2 to clearly explain why the current generic google.protobuf.Value model cannot distinguish between field types (InstanceTypeReference vs plain string). Assisted-by: Claude Code <noreply@anthropic.com> Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: Elad Tabak <etabak@redhat.com>
omer-vishlitzky
added a commit
that referenced
this pull request
Aug 18, 2026
…n, observability detail - Reorder sequence diagram: publish to Kafka before returning inference response, eliminating the data-loss window (CodeRabbit inline comment) - Add CAP-13 mechanism justification for Kafka-to-Kafka latency budget (AI Design Review Important #2) - Restore observability detail in tenant attribution: structured log fields, alert threshold (>0 for 5m), security constraint (no full payloads in logs), forensic recovery path via raw topic retention (AI Design Review Important #1) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
htayrie-rh
pushed a commit
to htayrie-rh/enhancement-proposals
that referenced
this pull request
Aug 27, 2026
Close Open Question osac-project#2: Enclave profiles drive service enablement values via value-map extension (OSAC-4106). The Enclave plugin translates its osacProfilesList into individual services.*.enabled flags via --set, rather than templating entire value files. Clarifies reconciliation with PR #380 (global.profilesList): this design's per-service booleans are the canonical chart interface — simpler to validate, propagate uniformly to all components, and directly settable via Enclave value-map extension. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Haim Tayrie <htayrie@htayrie-thinkpadt14gen5.raanaii.csb>
Merged
5 tasks
empovit
pushed a commit
to empovit/osac-enhancement-proposals
that referenced
this pull request
Aug 31, 2026
…n, observability detail - Reorder sequence diagram: publish to Kafka before returning inference response, eliminating the data-loss window (CodeRabbit inline comment) - Add CAP-13 mechanism justification for Kafka-to-Kafka latency budget (AI Design Review Important osac-project#2) - Restore observability detail in tenant attribution: structured log fields, alert threshold (>0 for 5m), security constraint (no full payloads in logs), forensic recovery path via raw topic retention (AI Design Review Important osac-project#1) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
empovit
pushed a commit
to empovit/osac-enhancement-proposals
that referenced
this pull request
Aug 31, 2026
Add Alternative osac-project#2: ServerCluster as top-level peer of VirtualNetwork (uniform isolation model). Documents pros (atomic resize, simpler for uniform deployments), cons (couples fabric lifecycles, non-uniform membership needs multiple objects anyway), and why FabricDomain was chosen (handles both uniform and non-uniform cases; type:multi planned for Phase 2/3 uniform deployments). Renumber remaining alternatives (3-5). Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Vladik Romanovsky <vromanso@redhat.com>
empovit
pushed a commit
to empovit/osac-enhancement-proposals
that referenced
this pull request
Aug 31, 2026
Close Open Question osac-project#2: Enclave profiles drive service enablement values via value-map extension (OSAC-4106). The Enclave plugin translates its osacProfilesList into individual services.*.enabled flags via --set, rather than templating entire value files. Clarifies reconciliation with PR #380 (global.profilesList): this design's per-service booleans are the canonical chart interface — simpler to validate, propagate uniformly to all components, and directly settable via Enclave value-map extension. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Haim Tayrie <htayrie@htayrie-thinkpadt14gen5.raanaii.csb>
This was referenced Sep 6, 2026
This was referenced Sep 16, 2026
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps actions/checkout from 4 to 5.
Release notes
Sourced from actions/checkout's releases.
... (truncated)
Changelog
Sourced from actions/checkout's changelog.
... (truncated)
Commits
08c6903Prepare v5.0.0 release (#2238)9f26565Update actions checkout to use node 24 (#2226)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)