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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: devlift-cli
-Version: 0.1.3
+Version: 0.1.5
 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.5}/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`.
@@ -503,7 +509,7 @@ devlift eks create --name NAME --app APP --env ENV --region REGION --type api|wo
                    [--set key=value ...] [--public] [-y]
 devlift eks settings                  Every key --set accepts, and when each applies.
 devlift eks settings <service>        Only the keys that apply to it, with its current values.
-devlift eks show <service> --env ENV  The configuration as it stands, with pending values marked.
+devlift eks show <service> --env ENV  The configuration, with any pending draft over it; pending rows name the deployed value too.
 devlift eks diff <service> --env ENV  Preview the pending change: Field | Deployed | Requested.
 devlift eks diff <service> --deployed The live configuration versus the last deployment.
 devlift eks edit <service> --env ENV [--set key=value ...]
@@ -746,7 +752,15 @@ last deployed. That one ignores drafts entirely, so on a service whose
 change is still a draft it shows the live row and its defaults, not what the
 draft proposes.
 
-`eks show` marks each value that a pending request would change.
+**`eks show` is not "what is deployed" while a request is open.** Its
+Configuration table is the live configuration with the open draft laid over
+it, so a pending row shows the value the draft *proposes*. Each such row is
+marked `pending (<status>) — deployed <value>`, so both numbers are visible.
+
+In `-o json` the same thing is spelled out: `settings` is the merged view,
+`deployed_settings` is what is actually running, and `pending` gives
+`{deployed, requested}` for each changed key. When `pending_request` is null
+there is no draft and `settings` is simply the deployed configuration.
 
 ### kong
 

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

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

{devlift_cli-0.1.3 → devlift_cli-0.1.5}/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.5}/devlift_cli/commands/eks.py

@@ -110,35 +110,67 @@ def eks_show(
     region: str | None = typer.Option(None, "--region", help="Region, when the service runs in several."),
 ):
     """Show a service's configuration as it stands, marking values pending in an open request."""
-    from devlift_cli.ops.eks import LABELS, load_effective, _show
+    from devlift_cli.ops.eks import LABELS, load_effective, settings_from_config, _show
     from devlift_cli.render import output
 
     inv: Invocation = ctx.obj
     eff = load_effective(inv, Resolver(inv.api, inv.profile.name), service, env, region, for_edit=False)
     live = eff.live
     request = eff.draft
+    # `eff.settings` is the live config with the open draft laid OVER it, so for
+    # any pending key its value is what the draft proposes, not what is running.
+    # Reading it as "the current configuration" is the obvious mistake, and one
+    # that has been made, so the deployed values are published beside it rather
+    # than left to be inferred from pending_keys.
+    deployed_settings = settings_from_config(dict(live.get("config") or {}))
     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,
-        "settings": eff.settings, "pending_request": {"code": request["code"], "status": request["status"]} if request else None,
+        # effective = deployed, with the pending draft laid over it.
+        "settings": eff.settings,
+        # what is actually running right now, whatever is pending.
+        "deployed_settings": deployed_settings,
+        "pending_request": {"code": request["code"], "status": request["status"]} if request else None,
         "pending_keys": sorted(eff.pending_keys),
+        # Both sides per changed setting, so "what is deployed" needs no
+        # cross-referencing of two dicts against a list of keys.
+        "pending": {
+            k: {"deployed": deployed_settings.get(k), "requested": eff.settings.get(k)}
+            for k in sorted(eff.settings)
+            if k in eff.pending_keys or (k in ("hpa_enabled", "min_replicas", "max_replicas") and "hpa" in eff.pending_keys)
+        } if request else {},
     }
 
     def table(d):
         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"]))
         pend = set(d["pending_keys"])
         def mark(k):
             hit = k in pend or (k in ("hpa_enabled", "min_replicas", "max_replicas") and "hpa" in pend)
-            return f"pending ({d['pending_request']['status']})" if hit and d["pending_request"] else ""
-        return rows_table(["Setting", "Value", ""], [(LABELS.get(k, k), _show(v), mark(k)) for k, v in d["settings"].items()], title="Configuration")
+            if not (hit and d["pending_request"]):
+                return ""
+            # Name the value that is actually running. Marking the row "pending"
+            # while showing only the draft's number tells the reader the setting
+            # is changing but not what it is changing FROM, which is the half
+            # they need to judge it.
+            return f"pending ({d['pending_request']['status']}) — deployed {_show(d['deployed_settings'].get(k))}"
+        header = "Value (deployed)" if not d["pending_request"] else "Value (with pending draft)"
+        return rows_table(["Setting", header, ""], [(LABELS.get(k, k), _show(v), mark(k)) for k, v in d["settings"].items()], title="Configuration")
     inv.emit(data, table)
 
 

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

@@ -239,6 +239,24 @@ 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.
+- **`eks show` is not "what is deployed" when a request is open.** Its
+  `settings` are the live configuration with the open draft laid OVER it, so
+  for any pending key the value shown is what the draft PROPOSES. Quoting one
+  as the running value is wrong and has misled a user.
+  Check `pending_request` first. If it is null, `settings` is the deployed
+  configuration and you can quote it freely. If it is set, use
+  `deployed_settings` for what is running, or `pending` which gives
+  `{deployed, requested}` per changed key, or run `devlift eks diff <service>
+  --env <env>`. Never describe a value as current, running or deployed on the
+  strength of `settings` alone while something is pending.
+- **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.5}/devlift_cli/skill/reference/commands.md

@@ -63,7 +63,7 @@ devlift eks create --name NAME --app APP --env ENV --region REGION --type api|wo
                    --repository owner/name --branch main [--branch ...]
                    --language Go|Python|Node.js|"Java Maven"|"Java Gradle" --version 1.24
                    [--set key=value ...] [--public] [-y]
-devlift eks show <service> --env ENV            configuration as it stands; pending values marked
+devlift eks show <service> --env ENV            live config WITH any open draft over it; deployed_settings + pending{} give the real deployed values
 devlift eks diff <service> --env ENV            preview the pending request: Field | Deployed | Requested
 devlift eks diff <service> --deployed           instead: live config vs the last deployment
 devlift eks settings <service> --env ENV        the --set keys that apply to it, with current values

{devlift_cli-0.1.3 → devlift_cli-0.1.5}/devlift_cli/skill/reference/workflows.md

@@ -59,7 +59,9 @@ the user it is a draft, nothing is deployed, and continue with workflow 6.
 ## 4. Change a running service's settings
 
 ```
-devlift eks show orders --env stage --no-input -o json           # current values; pending_request + pending_keys if a draft exists
+devlift eks show orders --env stage --no-input -o json           # settings = live WITH the open draft over it.
+#   pending_request null  -> settings IS the deployed config
+#   pending_request set   -> use deployed_settings, or pending{key:{deployed,requested}}, or `eks diff`
 devlift eks edit orders --env stage --set memory_limit=1 --no-input     # Current | New, exit 5
 devlift eks edit orders --env stage --set memory_limit=1 --no-input -y -o json
 # → {changed, changes{field:{from,to}}, queue_code, queue_status}

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

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