info about Active (Needs Renewal) status after allocation End Date

docs/get-started/allocation/archiving-a-project.md

@@ -6,8 +6,8 @@ by accessing [NERC's ColdFront interface](https://coldfront.mss.mghpcc.org/).
 !!! danger "Important Note"
 
     If you archive a project then this will expire all your allocations on that
-    project, which will disable your group's access to the resources in those
-    allocations. Also, you cannot make any changes to archived projects.
+    project, which will clean up and also disable your group's access to the resources
+    in those allocations. Also, you cannot make any changes to archived projects.
 
     ![Alert Archiving a Project](images/archiving_project_alert.png)
 

docs/get-started/allocation/coldfront.md

@@ -47,7 +47,8 @@ do the following tasks:
 -   Monitor resource utilization such as storage and cloud usage
 
 -   Receive email notifications for expiring/renewing access to resources as well
-    as notifications when allocations change status - i.e. activated, expired, denied
+    as notifications when allocations change status - i.e. Active, Active (Needs
+    Renewal), Denied, Expired
 
 -   Provide information such as grants, publications, and other reportable data for
     periodic review by center director to demonstrate need for the resources

docs/get-started/allocation/project-and-allocation-review.md

@@ -56,23 +56,26 @@ detail page and they see the status change to "project review pending".
 
 ## Allocation Renewals
 
-When the requested allocation is approved, it must have an expiration date - which
-is normally 365 days or 1 year from the date it is approved. Automated emails are
-triggered to all users on an allocation when the expiration date is 60 days away,
-30 days, 7 days, and then expired, unless the user turns off notifications on the
-project.
+When the requested allocation is approved, it must have an "End Date" - which
+is normally 365 days or 1 year from the date it is approved i.e. "Start Date".
+Automated emails are triggered to all users on an allocation when the end date
+is 60 days away, 30 days, 7 days, and then set the allocation status to
+"Active (Needs Renewal)", unless the user turns off notifications on the project.
 
-!!! danger "Very Important: Urgent Allocation Renewal is Required Before Expiration"
+!!! danger "Very Important: Urgent Allocation Renewal is Required Before End Date"
 
     If the allocation renewal isn't processed prior to the original allocation
-    expiration date by the PI or Manager, the allocation will expire and the
-    allocation users will get a notification email letting them know the allocation
-    has expired!
+    end date by the PI or Manager, the allocation will set the allocation status
+    to "Active (Needs Renewal)" and the allocation users will get a notification
+    email letting them know the allocation needs renewal!
 
-    ![Allocation Renewal Prior Expiration](images/renew_expiring_allocation.png)
+    ![Allocation Renewal Prior End Date](images/renew_expiring_allocation.png)
 
-    Currently, a project will continue to be able to utilize **expired** allocations.
-    So this will continue to incur **costs** for you.
+    Currently, a project will continue to be able to utilize allocations even after
+    the allocation end date, which will result in ongoing **costs** for you. Such
+    allocation will be marked as "Active (Needs Renewal)" as shown below:
+
+    ![Allocation Needs Renewal After End Date](images/needs_renew_allocation.png)
 
 Allocation renewals may not require any additions or changes to the allocation
 attributes from the PI or Manager. By default, if the PI or Manager clicks on
@@ -101,11 +104,12 @@ below:
 Then an automated email notification will be sent to the PI and all users on the
 allocation that have enabled email notifications.
 
-## Cost Associated with Expired Allocations
+## Cost Associated with Allocations that Need Renewal after "End Date"
 
-Currently, a project will continue to be able to utilize **expired** allocations.
-So this will continue to incur **costs** for you. In the future, we plan to change
-this behavior so expired allocations will result in its associated VMs/pods not
-to start and possibly having associated active VMs/pods to cease running.
+Currently, a project will continue be able to utilize allocations even after their
+"End Date", resulting in ongoing **costs** for you. Such allocations will be
+marked as "Active (Needs Renewal)". In the future, we plan to change this behavior
+so that allocations after end date will prevent associated VMs/pods from starting
+and may cause active VMs/pods to cease running.
 
 ---

docs/get-started/cost-billing/billing-faqs.md

@@ -52,10 +52,13 @@ or, by submitting a new ticket at [the NERC's Support Ticketing System](https://
     **Persistent storage** related to an OpenStack VM or OpenShift Pod will continue
     to be billed even when the **VM is stopped** or the **Pod is not running**.
 
-??? question "6. Am I going to incur costs for expired allocations?"
+??? question "6. Am I going to incur costs for allocations after end date?"
 
-    Currently, a project will continue to be able to utilize **expired** allocations.
-    So this will continue to incur **costs** for you.
+    Currently, a project will continue be able to utilize allocations even after
+    their "End Date", resulting in ongoing **costs** for you. Such allocations
+    will be marked as "Active (Needs Renewal)". In the future, we plan to change
+    this behavior so that allocations after end date will prevent associated
+    VMs/pods from starting and may cause active VMs/pods to cease running.
 
 ??? question "7. Are VMs invoiced even when shut down?"
 

docs/openshift/decommission/decommission-openshift-resources.md

@@ -248,14 +248,15 @@ you can filter the allocation of your interest and then proceed to request a
 
     Although other allocated resources i.e. CPU, RAM, GPU, etc. operate on a
     **pay-as-you-go** model, wherein charges are incurred solely based on usage,
-    **Expired** allocations will remain accessible to the users assigned under the
-    allocation. It is advisable to set all other allocation quota attributes to
-    zero (0) during the change request. **This measure ensures that existing users
-    will not accidentally use the resources from the project.**
+    **Active (Needs Renewal)** allocations after "End Date" will remain accessible
+    to the users assigned under the allocation. It is advisable to set all other
+    allocation quota attributes to zero (0) during the change request. **This
+    measure ensures that existing users will not accidentally use the resources
+    from the project.**
 
     Alternatively, PIs can control access to the allocation by [removing users](../../get-started/allocation/manage-users-to-a-project.md#addremove-users-tofrom-a-project)
     assigned to their NERC-OCP (OpenShift) allocation. This ensures that even if
-    the allocation expires, users will not have access to the unused resources.
+    the allocation ends, users will not have access to the unused resources.
 
 Please make sure your change request looks like this: