First take on LTSS documentation

[cwickert]

1st take on LTSS documentation. The BYOS part is based on the SLE documentation, PYAG on Robert's blog post draft.

For now, the docs assume that BYOS is registered with SUSEConnect and PAYG with registercloudguest. I know this assumption is not correct and consider merging both procedures, but then I need an easy and reliable way of determining the plan of an instance (e.g. checking the metadata) and what was used for the initial registration. This is a recurring topic, e.g. when troubleshooting registration issues, so I'd like a simple but reliable approach, ideally a single command. Once I got that, we can think about adding troubleshooting instructions etc.

[kvanderveer]

LGTM

[rjschwei]

Should we not tell users how to check that there instance is registered? And should we not tell users that for PAYG a registered system is the default state?

Since there is a difference between PAYG and BYOS I think we should not have the exact same wording.

[rjschwei]

Should we have a side note here to clarify that $REGISTRATION_CODE is the LTSS registration code previously activated in SCC?

[rjschwei]

@cwickert w.r.t. BYOS vs PAYG there is an easy way to check. There is a command, instance-flavor-check, that will provide the answer whether an instance is BYOS or PAYG. The command is delivered with the python-instance-billing-flavor-check package that is available in the Public Cloud Module and is pre-installed in images starting November 2023.

[rjschwei]

Also I think we should make some additional notes in the doc.
1.) Customers should not start net new workloads using distribution that are in LTSS
2.) With this PAYG images change their life-cycle and now match the BYOS image life-cycle, i.e. images move from "active" to "inactive" state in pint rather than from "active" to "deprecated"
3.) People should not expect new instance type enablement for distributions in LTSS

I will add these to the blog as well.