[Documentation] gemini-enterprise: access_end_hour is inclusive, so a window documented as 9 AM - 5 PM stays open through 5:59 PM

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#401 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
78/100
Loại issue
Tài liệu
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
terraform
Lĩnh vực
cloud, documentation

Hướng nghiên cứu

Đọc điều kiện truy cập trong gemini-stage-0/access_policy.tf và so sánh cách kiểm tra giờ có bao gồm giờ kết thúc với các mô tả trong gemini-stage-0/variables.tf, gemini-stage-0/terraform.tfvars.sample, deploy.sh và các README được nêu tên. Cập nhật giờ kết thúc được ghi lại, các giá trị mặc định và múi giờ để khớp với hành vi và cách diễn đạt được đề xuất. Công việc hoàn tất khi mẫu, lời nhắc, nội dung README và ví dụ của mô-đun mô tả nhất quán các khoảng thời gian phù hợp với điều kiện.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Documentation Gemini - Enterprise Level of Effort - Low Priority - Low Scope - Blueprint Scope - Module

Description of Documentation Need

The gemini-enterprise blueprint's time-based access level compares whole hours, and both ends are inclusive. gemini-stage-0/access_policy.tf:51 generates:

request.time.getHours("<zone>") >= <access_start_hour> && request.time.getHours("<zone>") <= <access_end_hour>

getHours() returns only the hour, so minutes are ignored: access_end_hour = 17 stays true through 17:59:59 and closes access at 18:00. To close at 5:00 PM, the value is 16.

Every place that describes the variable reads as though 17 closes access at 5:00 PM. An operator told to close at 5 PM enters 17, and the access level stays open an hour longer than was approved, with nothing in the plan or the output to show it. A student in one of our classes asked which it was, and our own answer key had made the same mistake.

At main @ 2267b973, under blueprints/gemini-enterprise/:

Location Says Actually
gemini-stage-0/terraform.tfvars.sample:96 access_end_hour = 17 # e.g., 5 PM ET through 5:59 PM
README.md:879, :884 Access only during business hours (Mon-Fri, 9 AM - 5 PM ET). through 5:59 PM with the sample's 17; through 9:59 PM with the default 21
README.md:894 Time of Day (7AM-9PM M-F) through 9:59 PM
gemini-stage-0/variables.tf:104 The hour (0-23) in the configured access_time_zone (default America/New_York) when access ends. does not say the hour itself is included
deploy.sh:1241 Enter End Hour in ${ACCESS_TIME_ZONE} (0-23) [21]: does not say the hour itself is included

Two details in the same README section are also out of date:

  • README.md:903-904 give the defaults as 9 and 17. variables.tf (lines 100 and 106) and deploy.sh (lines 1239 and 1241) default to 7 and 21.
  • The same lines say 0-23 ET, but the hours are evaluated in access_time_zone, which is configurable.

A related example: modules/organization/README.md:470-471, modules/organization-se/README.md:470-471, and modules/project/README.md:893-894 show the condition getHours("Europe/Berlin") <= 9 && getHours("Europe/Berlin") >= 17. No hour satisfies both, so that binding would never apply.

The same wording appears in Google's public documentation, which may be where it came from. A change in this repository cannot fix these pages, so they are listed for whoever owns them:

Neither page says that an hour check includes the minutes of the end hour.

Target Audience

Operators who turn a customer's approved hours into access_start_hour and access_end_hour, through the sample or the deploy.sh prompts, and the assessors who compare the deployed window with what was approved.

Proposed Location

The files in the table above, and the three module READMEs.

Content Outline / Draft

Keeping the <= is the smallest change, and it leaves every deployed window as it is. Suggested text:

  1. variables.tf:104: The last hour (0-23) in the configured access_time_zone (default America/New_York) during which access is allowed. Inclusive: minutes are ignored, so 17 allows access through 17:59 and closes it at 18:00.
  2. terraform.tfvars.sample:96: access_end_hour = 16 # last open hour: access closes at 5 PM ET
  3. README.md:879, :884, :894: state the window the defaults produce, 7 AM through 9:59 PM, or name the variables instead of a clock time.
  4. README.md:903-904:
    • access_start_hour: First hour access is allowed (0-23 in access_time_zone, default: 7)
    • access_end_hour: Last hour access is allowed, inclusive (0-23 in access_time_zone, default: 21, which closes access at 22:00)
  5. deploy.sh:1241: Enter End Hour in ${ACCESS_TIME_ZONE}, the last hour access stays open (0-23) [21]:
  6. The three module READMEs: getHours("Europe/Berlin") >= 9 && getHours("Europe/Berlin") < 17, which is a true 9 AM to 5 PM.

If maintainers would rather make the end hour a closing time, changing the operator to < does that, but it shortens every existing window by an hour on the next apply, and a window that runs to midnight would then need an end hour of 24.

Compliance Context (if applicable)

A time-based access level is a control that an operator documents and an assessor can test. If the approved window ends at 5 PM and the deployed level admits requests until 5:59 PM, access stays open for an hour nobody approved, on every day the window applies.

Ngôn ngữ chính
HCL
Star
61
Fork
28
Merge trung bình
1 ngày 17 giờ
Pull request đã merge (30 ngày)
74

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của google/stellar-engine

Tất cả issue của google/stellar-engine

Issue tương tự

Thêm issue về Cloud

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.