I’m wondering when and how the Content View is used.
I know content view acts as a sort of filter to form individual repo.
but it seems possible to install content even not in CV, to managed host via remote execution or on host’s terminal.
what does it mean “managed hosts get content from CV” and how?
according to manual, it says “content should be promoted to the environment where the hosts are assigned” before applying collection action.
then is CV used only when applying collection action?
content views are mainly there to manage your content, not to do some other arbitrary stuff using them (which can be done, but that is not the main purpose).
Mainly, content views are used to:
a) Group content (primarily products/repos) into managable units and then only assigning one (maybe composite) content view to your hosts instead of assigning every repo yourself.
b) Freeze versions of your content and then roll those frozen versions through your staging environments (like dev, testing, production) to make sure you do not get faulty/incompatible packages installed on your production machines just because somebody hit yum update.
You can in fact bypass all this and use the plain unmanaged repos directly via http, but that cuts a lot of the management potential of Katello and subscription-manager. If you would favor some further reading how this works, I did a somewhat extensible writeup here.
Thanks for getting back.
then when some host gets assigned new content view, I guess it must be done to remove existing contents(packages) and install all new contents into the host.
generally how to do such things via web UI or something, in foreman or satellite.
Not exactly sure what you mean, but large companies do not actually want to update all hosts daily. They want the opposite - update only those which are necessary to update (security related stuff, selected performance fixes etc). Other than that - any change to your infrastructure is a treat - you don’t want your pager to beep.
Usually hosts are associated to various Content Views and changes (package updates) are moved (or “promoted”) across your CVs/Environments. Typical use is Preproduction -> Production environment - you want to test things before pushing it live.
I suggest Satellite 6 documentation on this topic:
Thanks for getting back.
by the link, it says ‘CV needs to be published in order for it to be visible and usable by hosts’.
here, i’m wondering how the content view is used by hosts.
Does host install packages in CV via general yum command?? (considering published CV as a kind of added repository in host)
otherwise, should I use specific command through Satellite web UI or hammer??
By “using the contentview”, for package content this refers to the repositories in the CV beeing accessible via yum. The term can refer to other things depending on the type of content in your CV (e.g. Puppetclasses are obviously not accessible via yum). That is why the formulation is so generic.
If you want to, you can trigger package actions via katello, I have never tried this myself though (except for remote execution, where I am still using yum), but if yum commands or some sort of config management like puppet or ansible suites your needs better, you can use those without a problem.
You should be aware of the fact that using CVs usually means that you also need to use activation keys and subscription-manager on your managed hosts to access the repos in the Content View in a sane way.
Thanks for getting back!! I understood it somewhat now.
it seems like if I use remote execution, I can access not only repo in CV but also repo already added in the host (/etc/yum.repos.d/…).
what about triggering action? is it able to access both repos? (one in CV, the other in /etc/yum.repos.d/…)
of course, under the assumption that I use activation keys and subscription-manager on the host.
and do you usually perform such configuration managements through Foreman/Satellite web UI?
Think of CVs as a snapshot/point in time view of a set of repositories. You are locking the version of all the packages to a set version. You can then promote that version through testing, QA, production lifecycles (for example) which means that by the time you get to production, you know that all the package versions are consistent and tested. It means you won’t get to production and accidentally for example deploy a new version of libssl which breaks something, and then spend hours/days trying to figure out what is different. Same goes for files/puppet modules/etc. that are also configured in a CV.
Its a great way to ensure consistency across your platform and minimise random issues.
You can still use other repos programmed up /etc/yum.repos.d/ but I would recommend keeping all those disabled and actually create a product in foreman and sync the external repo there and make it part of the CV.
thank you for your reply
one more question please…
When I promote CV from one environment to the next containing target system, the target system can update to the new package versions in CV. right?
And I guess some are not in CV among packages already installed in target system.
Is it out of scope and user’s role to identify and remove such packages from target system??
Or does foreman have any function to do such tasks automatically?
If you promote a new version of a CV to an environment with systems in, you can do a yum update then (or let foreman handle it)
If the target system already has packages that are outside any repos you have in foreman then nothing will happen to them.
You’re talking about removing random packages that a user has installed? Thats where things like chef, puppet, etc. would come in. Foreman and CVs don’t define what packages are to be installed, they’re just copies of things like the CentOS repositories.
