I’m curious how most of you are handling products with multiple versions yet share the same package name (i.e. MongoDB 3.x or MongoDB 4.x both having the package name of mongodb-org-server).
Is it better to create a product for each “version” (i.e. MongoDB 3.x as one Product and MongoDB 4.x as another) or is it better to create one Product (i.e. MongoDB) with all the repos underneath it and present them all to the content view and hope the user disables the repos they don’t need.
Just fishing for a best practice/content management idea.
I think the more “natural” way to do it is with multiple products. There seem to be stronger tools for making the “right” packages visible (subscribe to zero or one of the mongo streams, as needed - and the bulk actions would allow changing that if needed).
Going into this, one of the big questions I always ask is how easy it would be for someone who is a casual user of the system to inadvertently “shoot themselves in the foot” - or cause a situation where updates/patches or blocked somehow.
Given that, hoping users will disable repos they don’t need might be hoping for a lot.
Finally, managing the actual products/repos/content views and lifecycle environments is a lot easier with the ansible modules. (It takes a bit of up-front time to understand how they work, but once it’s working, it’s a lot nicer than pointing and clicking through the interface, and more reliable as well. (What if I forget to change the default on this repo and not that one, for example?)
That’s just my perspective, though - happy to hear other opinions!
Yeah, my worry with the multiple products though was the stress on Foreman for synchronizing the content to the Smart-Proxies (I seem to remember a ~100 Product limit before you hit a performance wall with proxy syncs - but likely not an issue anymore).
