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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#401 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
terraform
Área
cloud, documentation

Línea de trabajo

Lee la condición de acceso en gemini-stage-0/access_policy.tf y compara su comprobación inclusiva de la hora con las descripciones de gemini-stage-0/variables.tf, gemini-stage-0/terraform.tfvars.sample, deploy.sh y los README mencionados. Actualiza la hora final documentada, los valores predeterminados y la zona horaria para que coincidan con el comportamiento y la redacción propuesta. El trabajo estará terminado cuando el ejemplo, las indicaciones, el texto del README y los ejemplos del módulo describan de forma coherente ventanas que coincidan con la condición.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
HCL
Estrellas
61
Forks
28
Merge medio
1 d 17 h
PR fusionados (30 d)
74

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de google/stellar-engine

Todos los issues de google/stellar-engine

Issues similares

Más issues de Cloud

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.