I am so glad I found your video 3 years after you published it. Thank you very much for your detailed explanation of this process, it helped me set mine up.
We look at creating a content view, adding repository, adding filters and then publishing it into library life cycle environment. Once it's published into the library, you can promote the CV into Dev, QA and Prod.
Content view is satellite way of allowing what Content to provide to systems. In short they have versioned bundles of repositories with optional filters applied.
Was struggling past few days with Lifecycle and CV.. beautifully explained. Thanks. Why do you specifically say "kickstart repo" is needed for environment with capsule. I am not planning to use puppet for kickstart (anything) but only use satellite->capsule
Thanks for the question, again :) If you do not add a kickstart repo to a content view, the kickstart repo will never get synced to a Capsule: only content in a content view is ever synced to Capsules. Puppet is a different beast and has no direct relation with kickstarting. Basically the flow is like this: you kickstart (install) a new system, during which Anaconda, based on the kickstart file installs various RPMs and runs scripts afterwards. Installing the Puppet agent can be part of that installation process. After that's done, the system reboots, Puppet starts up and executes Puppet modules you might have added to a hostgroup. (It's slightly more complicated than this, obviously, but this covers a lot.) So if you are not going to use Puppet, which can be a valid choice, you still need to add the kickstart repo to your CVs, because the installer itself (Anaconda) is included in those kickstart repos. Hope this helps!
Question:While enabling repos for a particular RHEL server release do i need to select all the minor release within the repo? for eg: repo: Red Hat Enterprise Linux 7.-> enable repo: RHEL 7, 7.1,7.2, 7.3 or just need to select RHEL 7?
Thanks for your questions. So if you want to make sure your system never installs any RPM that was released in the 7.3 timeframe, you select 7.2 and stick that into your CV. This basically locks your system to a minor release. If you really need to stay on 7.2 though, I suggest you take a look at the EUS channels you get with premium support: they actually allow you to stay on 7.2 for a prolonged period of time, without having to move to 7.3 If you plan to move from 7.1 to 7.2 to 7.3, you probably want to select 7Server, which will get all RPMs that are updated in RHEL7 over the complete life cycle of the RHEL7 product. Hope this helps, if not, let me know!
Hi, Thanks for your video. your reply for above que is "This basically locks your system to a minor release." Question : Meaning if we run "yum update -y" with CV selected for 7.2 will it still get update and stay as RHEL 7.2? meaning it still receives latest erratum?
It will receive whatever is in your CV, of course, but if you only add the 7.2 repository to your CV, your system can never get packages for 7.3. Those are simply not available then. Does that answer your question?
Question for posting these video's, can I use content views as a means of migrating away from RHEL 5.X and not needing to reinstall applications that are running on a given server?
Hi Kevin, you will have to reinstall applications, as swapping out RHEL5 for any other version of RHEL requires a complete reinstall. However, if you would write Puppet modules (or Ansible roles, in an upcoming version of Satellite) to install and configure your application, reinstallation and redeployment does become less impactful. Hope this helps. M
Why separate content views such as rhel base and epel. Wouldn't it be easier to include more products in one content view to make it easier to promote? I'd love to see your take on Life cycle environments. Thanks for the video. It's helpful
Thanks for the comment, Greg, and great to hear that you found the video helpful! The choice between content views and composite content views is actually a topic of an upcoming episode. I just need some time to finish it :) I'll make sure to spend some time talking about lifecycle environments in the future as well.
Sorry this took so long, I never got notifications for these replies! Fixed that now! I realize this is a really old comment, but what life cycle did you mean? And are you still interested?
I am so glad I found your video 3 years after you published it. Thank you very much for your detailed explanation of this process, it helped me set mine up.
Glad it was helpful!
We look at creating a content view, adding repository, adding filters and then publishing it into library life cycle environment.
Once it's published into the library, you can promote the CV into Dev, QA and Prod.
I am new to Satellite, excellent presentation. Thanks.
Content view is satellite way of allowing what Content to provide to systems.
In short they have versioned bundles of repositories with optional filters applied.
Well done! Great job!
Was struggling past few days with Lifecycle and CV.. beautifully explained. Thanks.
Why do you specifically say "kickstart repo" is needed for environment with capsule. I am not planning to use puppet for kickstart (anything) but only use satellite->capsule
Thanks for the question, again :)
If you do not add a kickstart repo to a content view, the kickstart repo will never get synced to a Capsule: only content in a content view is ever synced to Capsules.
Puppet is a different beast and has no direct relation with kickstarting. Basically the flow is like this: you kickstart (install) a new system, during which Anaconda, based on the kickstart file installs various RPMs and runs scripts afterwards. Installing the Puppet agent can be part of that installation process. After that's done, the system reboots, Puppet starts up and executes Puppet modules you might have added to a hostgroup. (It's slightly more complicated than this, obviously, but this covers a lot.)
So if you are not going to use Puppet, which can be a valid choice, you still need to add the kickstart repo to your CVs, because the installer itself (Anaconda) is included in those kickstart repos.
Hope this helps!
Question:While enabling repos for a particular RHEL server release do i need to select all the minor release within the repo?
for eg: repo: Red Hat Enterprise Linux 7.-> enable repo: RHEL 7, 7.1,7.2, 7.3 or just need to select RHEL 7?
Thanks for your questions.
So if you want to make sure your system never installs any RPM that was released in the 7.3 timeframe, you select 7.2 and stick that into your CV. This basically locks your system to a minor release.
If you really need to stay on 7.2 though, I suggest you take a look at the EUS channels you get with premium support: they actually allow you to stay on 7.2 for a prolonged period of time, without having to move to 7.3
If you plan to move from 7.1 to 7.2 to 7.3, you probably want to select 7Server, which will get all RPMs that are updated in RHEL7 over the complete life cycle of the RHEL7 product.
Hope this helps, if not, let me know!
Hi,
Thanks for your video. your reply for above que is "This basically locks your system to a minor release."
Question : Meaning if we run "yum update -y" with CV selected for 7.2 will it still get update and stay as RHEL 7.2? meaning it still receives latest erratum?
It will receive whatever is in your CV, of course, but if you only add the 7.2 repository to your CV, your system can never get packages for 7.3. Those are simply not available then. Does that answer your question?
100 things to do with Red Hat Management products
thanks. meaning latest available erratum not applicable to those machines, if I am not wrong!
Hi, really good job. Just a request, please add some more videos about Red Hat Satellite. Thanks :)
+Hradayesh Shukla more to follow, stay tuned! And also, any specific topics you want to see?
Good video. Is there a way to see in the GUI the list of packages are being included ? it might really useful to be sure how the filter is doing.
Sorry this took so long, I never got notifications for these replies! Fixed that now!
I think this is an RFE at the moment
Question for posting these video's, can I use content views as a means of migrating away from RHEL 5.X and not needing to reinstall applications that are running on a given server?
Hi Kevin, you will have to reinstall applications, as swapping out RHEL5 for any other version of RHEL requires a complete reinstall. However, if you would write Puppet modules (or Ansible roles, in an upcoming version of Satellite) to install and configure your application, reinstallation and redeployment does become less impactful.
Hope this helps.
M
Why separate content views such as rhel base and epel. Wouldn't it be easier to include more products in one content view to make it easier to promote? I'd love to see your take on Life cycle environments. Thanks for the video. It's helpful
Thanks for the comment, Greg, and great to hear that you found the video helpful!
The choice between content views and composite content views is actually a topic of an upcoming episode. I just need some time to finish it :) I'll make sure to spend some time talking about lifecycle environments in the future as well.
Good job! Please can you do a video on life cycle? thank you
Sorry this took so long, I never got notifications for these replies! Fixed that now!
I realize this is a really old comment, but what life cycle did you mean? And are you still interested?