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

オープン 初心者向け
  • 何か問題がありますか？
#401 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
78/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
terraform
領域
cloud, documentation

調査の方向性

gemini-stage-0/access_policy.tf のアクセス条件を読み、時間を含む判定と、gemini-stage-0/variables.tf、gemini-stage-0/terraform.tfvars.sample、deploy.sh、指定された README の説明を比較します。記載されている終了時刻、デフォルト値、タイムゾーンを、動作と提案された文言に合うように更新します。サンプル、プロンプト、README のテキスト、モジュールの例が一貫して条件に合う時間帯を説明していれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
HCL
スター
61
フォーク
28
平均マージ
1日 17時間
マージ済み PR（30日）
74

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

google/stellar-engine のほかの issue

google/stellar-engine の issue をすべて見る

似ている issue

Cloud の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。