A decent amount of this is already written on the Satellite blog (https://access.redhat.com/blogs/1169563/posts/2576311)

Stephen - there is a lot of information in the blog post that looks like it could be a good addition for something like the Architecture Guide.

Most importantly, it looks like a good chance to provide some contextual details about manifests, add a copy of the diagram to help explain it, and provide an overview of manifests.

Is this something you would be keen and available to look into at this time? If so, I can assign it over, and I'd be keen to hear your thoughts as well.

Hello Andrew

Yes, I can work on this. A review of the guides first:

The Installation Guide [0] now has a section "Creating a Manifest"

We need to at least mention there that you can have multiple manifests, maybe add somewhere a warning:

Make sure you DO NOT delete the manifest from the Customer Portal or in the Satellite Web UI as this will unregister all of your content hosts.

I feel that the subject of using multiple manifests should be covered elsewhere as a reader of the Installation Guide wants to get it installed ASAP. During planing stages seems a better time to consider the need for multiple manifests.

We could link to [Managing Subscriptions](https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/managing_subscriptions) and explain there about *using* multiple manifests. Architecture Guide might be a better place for diagrams and concepts as to *why* you might want to use them. I'll return to this topic later and ping sbream as its Content Strategy.

Re comment 0 and the places where manifests are mentioned:

Re. Server Admin Guide: ⁠CHAPTER 3. CONFIGURING A SELF-REGISTERED SATELLITE

That chapter was moved to the Installation Guide [1] due to:
Bug 1413992 - Install documentation does not outline self hosted satellite servers


In the  "Registering a Satellite to Itself" section it says "Before a self-registered Satellite can be configured to get updates from itself, the Satellite subscription must be added to the Satellite’s manifest"

That "to the Satellite’s manifest" is assuming there is only one manifest. More importantly, if you have one manifest per organization, then you would have to decided to which organization the Satellite belongs. Who pays for the Satellite or who manages the Satellite.

Perhaps say "Before a self-registered Satellite can be configured to get updates from itself, the Satellite subscription must be added to a manifest. If you have more than one manifest, then add the Satellite subscription to the manifest corresponding to the organization that manages the Satellite".

Then it says "For further information on Manifests see the Content Management Guide." Unfortunately, that is not a live link. FIXME

I think that "link" should go to this chapter directly: [Managing Subscriptions](https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/managing_subscriptions). {That, it seems, is where we should explain about *using* multiple manifests. Architecture Guide might be a better place for diagrams and concepts}.

The rest of that procedure looks OK except that it looks a little inconsistent. It does not tell you the "label" or CLI name for the 6 Server and 7 Server repo like it does for the Satellite repos (rhel-X-server-satellite-6.2-rpms). I just checked, those CLI names are not visible in the web UI. They should be removed. FIXME

There is more verbose version of this in the Installation Guide, in the upgrade section. Maybe we could use that ? See [2] and search for "Configure the repositories in the Satellite web UI."

We could add a warning at the top, just after the intro para to the section "Registering a Satellite to Itself", about never deleting manifests.

Make sure you DO NOT delete the manifest from the Customer Portal or in the Satellite Web UI as this will unregister all of your content hosts.


Re. Quick Start Guide: 3.6. CREATING A MANIFEST [3]

This procedure is the same as in the Installation Guide; just no explanations. Seems not point to add anything there, if you did, where would you stop?

Re. Content Management Guide: 3.2. CREATING A SUBSCRIPTION MANIFEST [4]

This section contains more verbose procedures than the Installation Guide. This guide seems like a good place for describing how to use multiple manifests.


I will study Rich Jerrido's article next.



[0] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/installation_guide/installing_satellite_server#creating_a_manifest

[1] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/installation_guide/installing_satellite_server#Configuring_a_Self_Registered_Satellite

[2] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/installation_guide/upgrading_satellite_server_and_capsule_server#upgrading_self_registered_satellite

[3] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/quick_start_guide/installing_satellite_server#creating_manifest

[4] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/managing_subscriptions

(In reply to Rich Jerrido from comment #1)
> A decent amount of this is already written on the Satellite blog
> (https://access.redhat.com/blogs/1169563/posts/2576311)

Hello Rich

Re. "Subscription Management applications"

Does a Satellite 6 user need to configure anything to do with 'Subscription Management Application'? I am not sure of the point in mentioning this if the user has no way or need to configure it.

Re. "Smart Management"

Is that a Sat5 only term? i.e. only applies to Sat5? If so, we can drop that bit. IIRC this is something to do with being entitled to manage guests using SatX.

Thank you

Hello

In the Architecture Guide, Chap. 4 "Satellite Server Configuration" section[1], it mentions manifest. 

It has a brief description of what it is, and links to the Content Management Guide for more info. Actually, it links directly to the chapter "Managing Subscriptions", which is good, but does not mention that, which is not good.

That section does mention "Create one manifest per organization. ", so that is good.

Then it says "Note that the subscription manifest can be modified and reloaded to the Satellite Server in case of any changes in your infrastructure. ". We should add "but it should not be deleted".

In Chap. 4 "Locations and Topology", it might be a good idea to mention the possibility to have multiple organizations and associated manifests.


[1] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/architecture_guide/chap-red_hat_satellite-architecture_guide-deployment_considerations#sect-Satellite_Server_Configuration

Hi Stephen,

Thank you for the detailed review - I agree with everything you are saying, and acknowledge the need for us to seek guidance from Steve as well.

Based on your comments, it looks like we may need the following -

1. Context and diagrams in the Architecture Guide

2. An improved description in the Installation Guide

3. Procedural information in the Content Management Guide

I will wait for further comment from Steve, but assuming we head in this direction, would you prefer we have a separate bug for each guide? I would be happy to raise some if needed.

Kind regards,

Andrew

Hello Andrew

Charles spoke to me today about unused text in enabling_new_repositories.adoc.


This go us talking about the issues I labeled as FIXME in comment 3, and as he worked on that section I cloned this bug for him to fix those issues(BZ#1433002).

I will need one clone for the Architecture Guide, and we can use this BZ for the "Content Management Guide".


our Designated Diagram Person (DPP) is away. PTO, till 22 of March.

Hi Stephen,

Thank you for the update.

I have now raised BZ#1433152 to handle the content in the Architecture Guide, and have assigned it to you.

Let me know if there is anything else you require!

Kind regards,

Andrew

Hello Rich

Further to comment 4

After further reading, I think "Subscription Management Application" is the collective term used on the portal[1] for "Subscription Asset Manager" and "Satellite Server".

So for example I think this is correct:
Type 	Type of Subscription Management application 	usually 'Satellite' or 'Sam'

but this not:
directly to the Subscription Management app

- - - - - - - - - - 

In the URL[2] we can see these products that use manifests being referred to as "distributors", but the term is not used on the web pages, so we do not need to mention that in the guide.

Thank you



[1] https://access.redhat.com/management/
[2] https://access.redhat.com/management/distributors?type=satellite

Hello Rich

further to comment 10 and comment 4

In the diagram[1] where it says "Subscription Management Applications" we can change that to "Subscription manifest" for ACME and "Subscription manifests" for Example Corp. 


Thank you


[1] https://access.redhat.com/sites/default/files/smfrhnu_2.png

(In reply to Stephen Wadeley from comment #4)
> (In reply to Rich Jerrido from comment #1)
> > A decent amount of this is already written on the Satellite blog
> > (https://access.redhat.com/blogs/1169563/posts/2576311)
> 
> Hello Rich
> 

> 
> Re. "Smart Management"
> 
> Is that a Sat5 only term? i.e. only applies to Sat5? If so, we can drop that
> bit. IIRC this is something to do with being entitled to manage guests using
> SatX.
> 
> Thank you

Rich confirms, "Smart Management" applies to Sat5 *and* 6

Hello


These updates are now live on the customer portal.

Managing Multiple Organizations Using Multiple Manifests [1]

Updating and Refreshing a Manifest

[1] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/content_management_guide/managing_subscriptions#Managing_Subscriptions-Using_Multiple_Manifests

Thank you