Add Licensing information to operations guide #405
Conversation
| `commercial.credentials` it’s important to use the email associated with your organization's license, and not a personal | ||
| account. If enterprise environments this is usually your corporate email. | ||
| 2. Download your `license` file manually. You can find your license by visiting | ||
| https://www.lightbend.com/product/conductr/license |
There was a problem hiding this comment.
We can use https://www.lightbend.com/account/license instead now. It provides the copy button, like access-token.
There was a problem hiding this comment.
@edwardcallahan Cool. Why does it say "Once you've copied the above license to your clipboard then paste it into the prompt that caused you to come here." What prompt asks you for the license?
There was a problem hiding this comment.
That particular page was created for the HPE Fortify Scala plugin feature. The verbiage on that page can certainly be improved. Particularly now that we've added another use-case.
There was a problem hiding this comment.
Thanks so much for writing this up, @seglo ! Appreciate the contribution.
Two change requests, please.
WRT the rendering. The MD preview is sufficient, thanks. Also note that we are moving to tech hub for doc this fall.
| when starting your cluster in the same manner you plan to license it. You should load all required support bundles | ||
| (`visualizer`, `haproxy`, `continuous-delivery`, etc.) as well as your latest running app bundles. | ||
| - While there is at least one node of the cluster up, the license will be intact. | ||
| - Future versions of ConductR will persist the license to disk in the cluster. |
There was a problem hiding this comment.
Let's note the backup and restore feature, typesafehub/conductr-cli#517, instead. For the immediate future, users preparing for full data center shutdown recovery should have their license and bundle backups in the plan. When/If CRDT state is persisted, the two are a shared concern. Or, a licensed but empty post-disaster cluster isn't very useful.
There was a problem hiding this comment.
@edwardcallahan I can remove the notes about reloading bundles and cluster state. Maybe the cluster backup stuff should be mentioned in another section and not Licensing. WDYT?
|
Thanks @edwardcallahan . I made the changes we agreed to as well as misc. wording fixes. Please review. |
seglo
changed the title
|
Removed single line breaks after previewing page with |
|
|
||
| If you need to update the license on an already licensed cluster you can do so using the `--force` command switch. This | ||
| is useful when you want to change the license to a different user or when your license is close to expiring. Enter | ||
| `conduct load-license --offline` and the command line and then follow the prompts to load a new license. |
There was a problem hiding this comment.
Did you mean to write conduct load-license --force here ?
There was a problem hiding this comment.
Yes. Thanks @patrick-premont .
| it's first started up. | ||
|
|
||
| Remember that licenses expire, so set a reminder to occassionally retrieve an updated `./.conductr/license` file for | ||
| your deployment script. |
There was a problem hiding this comment.
It might be good to add a sentence here like "License expiry does not affect running bundles but would prevent the execution of further ConductR operations, such as new bundle deployments."
There was a problem hiding this comment.
That's interesting. I've never tested this scenario. Have you confirmed this with the Enterprise Suite team?
There was a problem hiding this comment.
Agents need a license to have resource offers be usable/accepted. There's nothing that will stop bundles from running the moment the currently installed license expires. Once the license expires, no new agents can join the cluster as licensed members.
If, post expiry, an agent restarts for example, the new agent for the node will not validate and no bundle instances will be started on that agent's node. If the node host had reset, existing bundle load was also lost and now is no longer reschedulable on that agent node as that agent is not licensed.
Patrick is correct, if nothing happens to your cluster: nothing starts, stops, restarts, nothing; then nothing will happen to your bundles either.
There was a problem hiding this comment.
@edwardcallahan thanks. To confirm, if you were to deploy a bundle into an expired cluster, would the agents that joined the cluster before expiry still be able to deploy and run the bundle?
There was a problem hiding this comment.
@seglo I don't see/know of anything that clearly would prevent the new scale request from being fulfilled, provided said agents have sufficient resources in their offers. We want you to be successful and we have no motivation to stop existing bundles in the future, for example. Beyond that it is difficult to provide warranty for future behavior.
There was a problem hiding this comment.
Ok. I feel like this is getting pretty deep into the weeds. Given we're not 100% about what happens to newly deployed bundles would this statement be satisfactory?
An existing ConductR cluster and its running bundles will continue to run when the license expires. New agents, or agents that try to rejoin after a failure, will not be able to join the cluster.
* Add Licensing information to operations guide * Remove caveats section an incorporate info into rest of doc. Misc typo's. * Remove single line breaks * Fixed typo with load-license --force command * Notes on cluster behaviour after license expires
Add Licensing information to operations guide (CherryPick of #405)
Information on how to license the ConductR clusters. Tips for different types of cluster environments. Caveats of the licensing process.
I have not tested to see how this markdown looks rendered with play-doc. Can someone point me to directions on how to use this documentation tool?