Copilot commented on code in PR #643:
URL: 
https://github.com/apache/cloudstack-documentation/pull/643#discussion_r3085418103


##########
source/adminguide/templates.rst:
##########
@@ -136,6 +136,89 @@ in a private Zone, it is available only to Users in the 
domain assigned
 to that Zone. If a public Template is created in a public Zone, it is
 available to all Users in all domains.
 
+Template Replication on Secondary Storage
+-----------------------------------------
+
+A Zone may have more than one secondary storage (image store). When a
+Template is registered, CloudStack decides how many of those image
+stores should hold a copy of the Template. Historically, this decision
+was tied to the Template's ``public`` flag:
+
+-  **Public Templates** were copied to **every** image store in the
+   Zone, so that the Template was readily available wherever a host
+   pulled from.
+
+-  **Private Templates** were copied to **exactly one** image store in
+   the Zone.
+
+This coupling mixed two unrelated concerns — *who can see a Template*
+(access control) and *how many copies are kept on secondary storage*
+(placement and durability). In environments where secondary storage
+already provides redundancy (for example Ceph, replicated NFS, or
+object storage), copying public Templates to every image store wastes
+capacity, lengthens sync times, and adds unnecessary network and I/O
+load. Conversely, operators who want a second copy of a private
+Template for availability had no way to ask for one.
+
+To give operators explicit control, CloudStack exposes two
+configuration settings that cap the number of secondary storage pools
+a Template is copied to:
+
+-  ``public.template.secstorage.copy`` — the maximum number of
+   secondary storage pools to which a public Template is copied. The
+   default is ``0``, which means "copy to every image store in the
+   Zone" and preserves the historical behavior.
+
+-  ``private.template.secstorage.copy`` — the maximum number of
+   secondary storage pools to which a private Template is copied. The
+   default is ``1``, which preserves the historical behavior.
+
+Replication stops once the configured replica count is reached. Image
+store selection reuses the existing CloudStack placement logic, so
+copies are spread across image stores in the Zone.

Review Comment:
   The section defines `public.template.secstorage.copy = 0` as a special value 
meaning “copy to every image store”, but a few lines later it states 
“Replication stops once the configured replica count is reached.” For the `0` 
case this reads as if replication would stop immediately. Consider explicitly 
calling out `0` as “unlimited / all image stores” and qualifying the “stops 
once reached” sentence as applying only to non-zero values.
   ```suggestion
      default is ``0``, a special unlimited value that means "copy to
      every image store in the Zone" and preserves the historical
      behavior.
   
   -  ``private.template.secstorage.copy`` — the maximum number of
      secondary storage pools to which a private Template is copied. The
      default is ``1``, which preserves the historical behavior.
   
   When the configured replica count is non-zero, replication stops once
   that count is reached. A value of ``0`` is the special case described
   above and means replication continues until the Template has been
   copied to every image store in the Zone. Image store selection reuses
   the existing CloudStack placement logic, so copies are spread across
   image stores in the Zone.
   ```



##########
source/adminguide/templates.rst:
##########
@@ -136,6 +136,89 @@ in a private Zone, it is available only to Users in the 
domain assigned
 to that Zone. If a public Template is created in a public Zone, it is
 available to all Users in all domains.
 
+Template Replication on Secondary Storage
+-----------------------------------------
+
+A Zone may have more than one secondary storage (image store). When a
+Template is registered, CloudStack decides how many of those image
+stores should hold a copy of the Template. Historically, this decision
+was tied to the Template's ``public`` flag:
+
+-  **Public Templates** were copied to **every** image store in the
+   Zone, so that the Template was readily available wherever a host
+   pulled from.
+
+-  **Private Templates** were copied to **exactly one** image store in
+   the Zone.
+
+This coupling mixed two unrelated concerns — *who can see a Template*
+(access control) and *how many copies are kept on secondary storage*
+(placement and durability). In environments where secondary storage
+already provides redundancy (for example Ceph, replicated NFS, or
+object storage), copying public Templates to every image store wastes
+capacity, lengthens sync times, and adds unnecessary network and I/O
+load. Conversely, operators who want a second copy of a private
+Template for availability had no way to ask for one.
+
+To give operators explicit control, CloudStack exposes two
+configuration settings that cap the number of secondary storage pools
+a Template is copied to:
+
+-  ``public.template.secstorage.copy`` — the maximum number of
+   secondary storage pools to which a public Template is copied. The
+   default is ``0``, which means "copy to every image store in the
+   Zone" and preserves the historical behavior.
+
+-  ``private.template.secstorage.copy`` — the maximum number of
+   secondary storage pools to which a private Template is copied. The
+   default is ``1``, which preserves the historical behavior.
+

Review Comment:
   This section introduces new global settings but doesn’t indicate the 
CloudStack version (or release line) where they become available. Adding a 
short “Since version …” note (similar to other parts of this guide) would 
prevent confusion for operators on older releases who won’t find these settings.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to