devlift-cli 0.1.3__tar.gz → 0.1.4__tar.gz

{devlift_cli-0.1.3 → devlift_cli-0.1.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: devlift-cli
-Version: 0.1.3
+Version: 0.1.4
 Summary: DevLift command-line tool: create, change, review and deploy DevLift resources from the terminal.
 License: Proprietary
 Keywords: devlift,devops,deployment,infrastructure,cli

{devlift_cli-0.1.3 → devlift_cli-0.1.4}/devlift_cli/MANUAL.md

@@ -227,11 +227,13 @@ devlift clusters list [--app NAME] [--env ENV] [--region REGION] [--type eks|ecs
 ```
 
 The clusters services run on, and the `--cluster` values for `eks create`.
-Narrowed to placements you could really create in: the backend reports only
-the environments this deployment serves, and the placement allowlist
-(section 5) says which of those offer EKS or ECS. Clusters outside both are
-real but unusable from here, so they are hidden and counted; `--all` shows
-everything the backend reports.
+Narrowed by three filters, the same ones a create goes through: the backend
+reports only the environments this deployment serves, the placement allowlist
+(section 5) says which of those offer EKS or ECS, and only a **registered**
+cluster may take a new service. Anything outside those is real but can never
+be chosen, so it is hidden and counted. `--all` drops all three and shows
+everything the backend reports, for checking what exists rather than for
+choosing.
 
 ```
 devlift clusters list --type eks --app core --env stage
@@ -239,16 +241,20 @@ devlift clusters list --type eks --app core --env stage
 
 ```
 22 of 25 hidden: not a placement this deployment offers; --all shows everything.
+2 more hidden: not registered, so no service can be created on them.
 
-Cluster                                         Type  Environment  Region  Application  Registered
+Cluster                                        Type  Environment  Region  Application  Registered
 acme-core-stage-mumbai-01-application-cluster  EKS   stage        Mumbai  core         yes
-…two more in the same placement, not registered
 ```
 
-Within that, **Registered** is the flag that matters: only a registered
-cluster may take a new service, and `eks create` will not offer the others.
-A row whose Application reads "tenant-level" belongs to no single product
-and is the fallback for products with no cluster of their own.
+Everything listed is a cluster `eks create` would accept. A row whose
+Application reads "tenant-level" belongs to no single product and is the
+fallback for products with no cluster of their own.
+
+**Name and code are two labels for one cluster.** The Cluster column and
+`eks create` both show the name; the Code column and `eks show`'s
+`cluster_code` show the backend's identifier. They look nothing alike, so do
+not read a difference between them as two different clusters.
 
 With exactly one registered cluster in a placement, `eks create` fills it in
 silently. With several it asks, or wants `--cluster` under `--no-input`.

{devlift_cli-0.1.3 → devlift_cli-0.1.4}/devlift_cli/__init__.py

@@ -1,3 +1,3 @@
 """DevLift command-line tool."""
 
-__version__ = "0.1.3"
+__version__ = "0.1.4"

{devlift_cli-0.1.3 → devlift_cli-0.1.4}/devlift_cli/commands/clusters.py

@@ -66,14 +66,17 @@ def clusters_list(
 ):
     """List the clusters a service can run on.
 
-    Narrowed to placements this deployment serves and the placement allowlist
-    permits, so a cluster listed here is one a service could actually be
-    created on. `--all` shows everything the backend reports.
-
-    "Registered" is the flag that matters within that: only a registered
-    cluster may take a new service, and `eks create` will not offer the
-    others. A cluster with no application is tenant-level and is the fallback
-    for every product that has none of its own.
+    Three filters, the same ones every create goes through: placements this
+    deployment serves, placements the allowlist permits, and registration.
+    Only a registered cluster may take a new service, so an unregistered one
+    is never a candidate and is not listed. Everything shown here is a cluster
+    `eks create` would actually accept.
+
+    `--all` drops all three and shows everything the backend reports, which is
+    for checking what exists rather than for choosing.
+
+    A cluster with no application is tenant-level and is the fallback for
+    every product that has none of its own.
     """
     inv: Invocation = ctx.obj
     res = Resolver(inv.api, inv.profile.name)
@@ -95,8 +98,20 @@ def clusters_list(
     if not show_all:
         before = len(rows)
         rows = _placeable(res, rows)
-        if before > len(rows):
-            output.info(f"{before - len(rows)} of {before} hidden: not a placement this deployment offers; --all shows everything.")
+        placement_hidden = before - len(rows)
+
+        # Unregistered clusters are not offerable, so listing them is worse than
+        # useless: a service cannot be created on one, and naming it invites a
+        # comparison against the registered cluster that reads as a discrepancy.
+        # `--all` still shows them, for someone checking what exists.
+        registered = [r for r in rows if r.get("is_registered")]
+        unregistered_hidden = len(rows) - len(registered)
+        rows = registered
+
+        if placement_hidden:
+            output.info(f"{placement_hidden} of {before} hidden: not a placement this deployment offers; --all shows everything.")
+        if unregistered_hidden:
+            output.info(f"{unregistered_hidden} more hidden: not registered, so no service can be created on them.")
     inv.emit(rows, lambda d: rows_table(
         ["Cluster", "Type", "Environment", "Region", "Application", "Registered", "Status", "Code"],
         [(r.get("cluster_name") or r.get("name"), r.get("cluster_type"), r.get("environment"),

{devlift_cli-0.1.3 → devlift_cli-0.1.4}/devlift_cli/commands/eks.py

@@ -119,7 +119,13 @@ def eks_show(
     request = eff.draft
     data = {
         "service": eff.target.service_name, "service_config_code": eff.target.config_code,
-        "environment": live.get("environment"), "region": eff.target.region_name, "cluster": live.get("infrastructure_mst_code"),
+        "environment": live.get("environment"), "region": eff.target.region_name,
+        # The NAME, the same identifier `eks create` and `clusters list` print.
+        # This used to report infrastructure_mst_code, so the two commands named
+        # one cluster two different ways and anyone comparing them concluded the
+        # service had moved. The code is still here, under its own key.
+        "cluster": eff.config.get("cluster_name") or live.get("infrastructure_mst_code"),
+        "cluster_code": live.get("infrastructure_mst_code"),
         "type": eff.service.get("service_type"), "repository": eff.config.get("repository"),
         "branches": eff.config.get("branches") or eff.config.get("selected_branches"),
         "language": f"{eff.language_label or ''} {eff.language_version or ''}".strip() or None,
@@ -131,6 +137,8 @@ def eks_show(
         output.err_console.print(kv_table([
             ("Service", d["service"]), ("Type", d["type"]), ("Environment", f"{d['environment']} / {d['region']}"),
             ("Cluster", d["cluster"]), ("Repository", d["repository"] or "–"),
+            # Kept out of the table: the code adds nothing a reader can act on,
+            # and showing both invites exactly the comparison this fixes.
             ("Branches", ", ".join(d["branches"] or []) or "–"), ("Language", d["language"] or "–"),
             ("Pending request", f"{d['pending_request']['code']} ({d['pending_request']['status']})" if d["pending_request"] else "none"),
         ], title=d["service"]))

{devlift_cli-0.1.3 → devlift_cli-0.1.4}/devlift_cli/skill/SKILL.md

@@ -239,6 +239,14 @@ the approved rows. The summary is printed on every dry run, in json mode too.
   finished, and `eks status <service> --env <env>` also asks ArgoCD whether the
   pod is actually serving, which is the real "is it up" question. A finished
   pipeline is not a running application.
+- **Never compare a cluster code with a cluster name.** `eks show` returns both
+  `cluster` (the name, e.g. `acme-core-stage-mumbai-01-application-cluster`)
+  and `cluster_code` (e.g. `infra-acme-eks-staging-mumbai-app-01`). They are
+  two labels for the SAME cluster. Use `cluster` when you talk about it, and
+  never tell a user their services are on different clusters because the
+  strings differ — check with `devlift clusters list` before claiming any such
+  thing. That list is already narrowed to registered clusters a service can
+  actually be created on, so it is the authority.
 - Resources behave differently. `s3`, `sqs` and `dynamodb` create and update
   deploy straight away, so there report the resource name and the workflow id,
   which is what `deployment status` needs.

{devlift_cli-0.1.3 → devlift_cli-0.1.4}/devlift_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: devlift-cli
-Version: 0.1.3
+Version: 0.1.4
 Summary: DevLift command-line tool: create, change, review and deploy DevLift resources from the terminal.
 License: Proprietary
 Keywords: devlift,devops,deployment,infrastructure,cli