bcgov / bcgov/cloud-pathfinder

Make Client teams access to their internal ALB logs

Open
#2,413 2 comments 0 reactions 0 assignees View on GitHub
CSP: AWS Technical Debt Technology
Dominant language
Jinja
Stars
2
Forks
7
PR merge metrics
No merged PRs in 30d

Description

**Describe the Issue**
- Right now teams do not have access to their own Internal Alb logs. All the Alb logs are sent to the Log Archive account.It would be nice for the teams to have access to their own Internal Alb logs

**Additional Context**
- Right now the S3 Bucket destination is the bucket in the Log-Archive account, Change it to the bucket in clients account
- Reach out to warren for Additional information
- Might require config file changes

**Acceptance Criteria**
- Changes made and deployed in all Env's
- The Log destination is changed and verified

.
.
.
.
.
.
.
.
.
.
.

**Extra Template Info**

***Definition of Ready***
These set of conditions will need to be met in order to bring a ticket into the sprint and start work. Protects the team from unclear requirements.
Issues (Task/Story/Spike) aligned to an EPIC and linked appropriately.
Assigned to the appropriate CPF MEMBER (and is not left blank in ZenHub) at the start of sprint (1st day of the sprint)
Acceptance has been defined for the issue and has been reviewed with CPF team and approved by the necessary approver.
Has been sized and estimated by the delivery team.
Detailed breakdown of the steps required to complete the story in the additional context
Any additional specifications have been documented, reviewed with CPF and approved by the necessary approver.

***Acceptance Criteria***
A set of pre-defined requirement that need to be met in order to mark the user story as ?done?.
It should be testable with no room for interpretation
It should be either ?pass? or ?fail?
It should be clear enough for business stake holders to understand
As part of the user story, it should be written from the user perspective
A well written acceptance criteria is great for
- managing expectations
- defining scope
- reducing ambiguity
- establishing testing criteria for QA
Given (Pre-condition)
When (Action)
Then (Outcome)

***Definition of Done***
These set of conditions are met for work to be considered as complete on an issue.
All acceptance criteria(s) have been validated.
All the necessary documentation for the issue has been uploaded to Teams.
Functionality has been tested when applicable.
Functionality has been demonstrated to the relevant stakeholders (where applicable).
Story has been scheduled for a Sprint Demo/community update and impacted teams invited to the Demo.
Stories accepted by PO and documented for potential sharing with impacted users.
- Documented = Captured in Community Update (CU) deck
- Release notes = aspirational goal of providing a bulleted list of features and changes that our users can touch. Was going to store them in our Cloud Pathfinder repo. Can also display to users in the CU

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by locating the configuration that sends Internal ALB logs to the Log Archive account and confirm the client-account bucket details with Warren. Update the relevant configuration, deploy it in every environment, and verify that the log destination is the client bucket and that teams can access their logs.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws
Domain
cloud, infrastructure
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.