Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hub online synchronization #82

Open
wants to merge 16 commits into
base: master
Choose a base branch
from
Open

hub online synchronization #82

Changes from 1 commit
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
aff2588
hub online synchronization
rjmateus Nov 28, 2023
5155c49
update description abou the channel mapping
rjmateus Dec 5, 2023
6a434f0
update next steps
rjmateus Dec 5, 2023
0e0f039
update images data#
rjmateus Dec 5, 2023
4c98e61
clarification on issv2
rjmateus Dec 5, 2023
ba50117
update information about image sync
rjmateus Dec 18, 2023
c2ab44f
rename master to main
rjmateus Dec 18, 2023
24915d9
add clarification about API calls
rjmateus Dec 18, 2023
0d25b72
disclaimer about concrete methods
rjmateus Dec 18, 2023
1ac3a6f
information about error scenarios
rjmateus Dec 19, 2023
26e77c3
provide alternative 2
mcalmer Oct 10, 2024
e943edb
fixup! provide alternative 2
mcalmer Oct 10, 2024
2adc104
define peripheral system on the hub
mcalmer Oct 11, 2024
eedf14d
adapt Alternative 2 to the outcome of the meeting
mcalmer Oct 11, 2024
efc44b7
adapt according to comments on the RFC
mcalmer Oct 11, 2024
1099c6f
clarify the import to peripheral
mcalmer Oct 13, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 26 additions & 10 deletions accepted/0000-hub-online-synchronization.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -122,18 +122,34 @@ During development phase we should consider if we can join both namespaces in on


### Alternative 2:
We can follow a similar approach to what we do to activate a proxy.
On the Hub we create an API which is called authenticated and can take additional data like credentials for the peripheral server.
This API create the configuration on the Hub side and also handle the creation of a system which represent an Uyuni Peripheral Server.

On the peripheral side we call the API on the Hub and fill out the required configuration data needed locally on the peripheral server (e.g. auto generated mirror credential password).
We will also change the `scc_url` configuration on the Peripheral to point to the Hub Server.
We need to establish a secure connection between Hub and Peripheral Server.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rjmateus @mcalmer are we going to drop the existing way of Hub and peripheral servers way of work? What would be the hub_xmlrpc_api role, will that be gone too?

What path are we providing for the users who are working with the current approach.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hub_xmlrpc_api is for ISSv2. In worst case the user can stay in it.
I cannot say if this is compatible with ISSv3. I do not really know what this is doing.
@rjmateus might be able to answer this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hub_xmlrpc_api will stay as is, since it's note dependent on the ISS version in use. This means it can work with any version of ISS, even the v3.
However, we may need to make some changes to one API that is providing the hub servers FQDN to the xml-rpc API, to instead of looking at the system entitlement it returns a list of configured peripherals

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And what about all different authentication methods https://documentation.suse.com/suma/5.0/en/suse-manager/specialized-guides/large-deployments/hub-auth.html ?
To support them, we will leave it up to the user to create the appropriate API users, ensuring that those users can be utilized to correctly make the API calls later on?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is correct. Users must exists in the peripheral servers to be able to call the API.
In 4.3 this config was possible with a salt formula, wich in 5.0 was transformed to a API call: https://github.com/SUSE/spacewalk/issues/22498

HOwever, I was trying to find the documentation for this and was unable. I ping Cedric and Vladimir to check if it's missing or if I'm blind.

For this we create a Peripheral configuration on the Hub server.
It mainly defines the FQDN of the Peripheral and generate credentials to authenticate from the Hub.
The Root CA must be configured as well when the peripheral server is already setup.

On the hub, the activate call will create the peripheral configuration with first data.
This configuration can be exported and needs to be transferred to the Peripheral Server.
This configuration include:
- the Root CA of the Hub
- the FQDN of the Hub
- the credentials to setup on the Peripheral Server

Alternatively for the Hub/peripheral communication an new API might be useful to have a clear separation.
This is needed when we want to make this API organization independent.
In the existing API the calling user is only allowed to operate on his own organization any maybe utilize "Vendor Channel" when he is a "SUSE Manager Administrator".
The authentication credentials works only for a special server-to-server API and is not connected to any user on the hub or peripheral server.
The new server-to-server API is required as the existing API is tied to the organization of the calling user. The new API should work organization independent.

The Peripheral Server may already be configured. When restarted with this additional configuration, it configures the Hub configuration and setup the credentials
that the Hub can connect and finish the configuration.

We may want to provide the possibility to generate a full peripheral configuration which makes it possible to setup the peripheral server from scratch including the Hub configuration (similar to the proxy configuration).


After the peripheral server is setup and the Hub can connect via the server-to-server API, the final configuration can be triggered by the Hub.
This include:
- Mirror credentials that the Peripheral Server can use to call the SCC endpoints on the Hub (See `Hub as a proxy for SCC data`). These credentials must be generated and set on Hub and Peripheral. This is required to authenticate and verify the authentication. Every Peripheral Server get a different credential.
- On the Peripheral server the `scc_url` must be changed to point to the Hub Server
- Create the Channels on the Peripheral Server which should be synchronized from the Hub

More configurations might be needed at a later point when additional features will be added.


#### The Peripheral Server system entry
Expand All @@ -153,7 +169,7 @@ Only in case if no host is available, the "Container Workload Entitlement" would

We have the use case that the operators of hub and peripheral server are not the same company. In this case the hub is only used to provide content to the peripheral and no data should be flowing in the other direction. This has several implications:

- The Hub and the Peripheral Server may use different Root CAs. To esteblish trusted TLS connections, Root CAs must be exchanged during the onboarding process.
- The Hub and the Peripheral Server may use different Root CAs. To establish trusted TLS connections, Root CAs must be exchanged during the on boarding process.
- The report database synchronization must be optional and should be configurable
- The peripheral server maybe not be managed by the Hub
- sending SCC Data from the peripheral to the hub must be optional as well
Expand Down