Is the kind of stacking/inheritance that I'm looking for possible? I don't
seem to be able to do it via the WebUI at any rate, On Satellite 6.1.4, or
Katello 2.4 RC installs.
···
On Wednesday, 2 December 2015 10:07:47 UTC, Duncan Innes wrote:
>
> Folks,
>
> Is it possible (or even wise?) to stack a composite content view within
> another composite content view?
>
> I've created a couple content views on my PoC installation;
>
> Content View: RHEL_7_SOE = "RHEL7" + "Satellite Tools"
> Content View: RHEL_7_Extras = "RHEL7 Extras"
> Content View: EPEL
>
> Composite View: RHEL_7_(SOE+Extras) = RHEL_7_SOE + RHEL_7_Extras
>
> What I'd like to be able to do is create another Composite View as follows:
>
> Composite View: RHEL_7_(SOE+Extras+EPEL) = RHEL_7_(SOE+Extras) + EPEL
>
> This last step doesn't seem possible. Looks like I have to create the new
> Composite view as:
>
> Composite View: RHEL_7_(SOE+Extras+EPEL) = RHEL_7_SOE + RHEL_7_Extras +
> EPEL
>
> Is the kind of stacking/inheritance that I'm looking for possible? I
> don't seem to be able to do it via the WebUI at any rate, On Satellite
> 6.1.4, or Katello 2.4 RC installs.
>
> Duncan
>
Follow-up question on EPEL setup for different RHEL/Centos releases.
I was looking at the Red Hat SOE guide
(https://access.redhat.com/articles/1585273) and they mentioned that one
should "create as few Products as possible" and "The minimum required
number of Products is determined by the GPG key" and "we recommend that you
bundle all Products and variants of each software within one Product as
long as they use the same GPG key".
EPEL ships with different GPG keys for each RHEL release (RHEL5, RHEL6 and
RHEL7). So, for something like this, should I create 1 "EPEL" product and
add each repo to this, or should I create 3 EPEL products, each with their
own key? When creating a product, I'm asked to provide a GPG key. As this
will vary between releases, I'm thinking I would need 3 different products?
We did something like you and we find it make sense, especially after
reading your post
cv-rhel6 (composite view)
cv-rhel6-base
cv-rhel6-extra
cv-rhel6-java
cv-rhel7(composite view)
cv-rhel7-base
cv-rhel7-extra
cv-rhel7-java
cv-rhelx-extra contains extra RPMS from nux,epel and our own repo of RPMS
and Puppet modules
seems good … so far
···
On Wednesday, December 2, 2015 at 11:07:47 AM UTC+1, Duncan Innes wrote:
>
> Folks,
>
> Is it possible (or even wise?) to stack a composite content view within
> another composite content view?
>
> I've created a couple content views on my PoC installation;
>
> Content View: RHEL_7_SOE = "RHEL7" + "Satellite Tools"
> Content View: RHEL_7_Extras = "RHEL7 Extras"
> Content View: EPEL
>
> Composite View: RHEL_7_(SOE+Extras) = RHEL_7_SOE + RHEL_7_Extras
>
> What I'd like to be able to do is create another Composite View as follows:
>
> Composite View: RHEL_7_(SOE+Extras+EPEL) = RHEL_7_(SOE+Extras) + EPEL
>
> This last step doesn't seem possible. Looks like I have to create the new
> Composite view as:
>
> Composite View: RHEL_7_(SOE+Extras+EPEL) = RHEL_7_SOE + RHEL_7_Extras +
> EPEL
>
> Is the kind of stacking/inheritance that I'm looking for possible? I
> don't seem to be able to do it via the WebUI at any rate, On Satellite
> 6.1.4, or Katello 2.4 RC installs.
>
> Duncan
>
I would suggest if we can assign multiple CVs to particular system without creating CCV that works better.
If you have many CCVs think of publishing activity, which is very slow and and you make change to single CV but in publish, you look for all CVs in CCV
if you are only managing OS contents, this works fine, but if you will also
manage different application contents, it will become difficult at some
stage, for example, you have database, middleware, finance, equities
different application groups, and you want to seperate their contents in
different CVs, you will have to create composite view like
now when you have to update, cv-rhel6-base, you have to publish
"cv-rhel6-base", you again have to change version of all above CCV and
publish it again. which will become difficult evantually. (i am not
creating only one CV as per SOE because, all my contents are not moving at
same speed, middleware is still testing in development but database is
ready for production ).
but if you dont have above requirements, everything just works nicely ( in
my case it doesnt )
I'm not using anything but EPEL for RHEL 7 at the moment, but I've just
created EPEL Product and then the repo beneath that. To add RHEL 6 or 5
EPEL repos, I'm planning to simply add them as repos under that same EPEL
Product.
D
···
On Friday, 11 December 2015 11:25:00 UTC, Richard wrote:
>
> Hi Duncan, Hi all,
>
> Follow-up question on EPEL setup for different RHEL/Centos releases.
>
> I was looking at the Red Hat SOE guide (
> https://access.redhat.com/articles/1585273) and they mentioned that one
> should "create as few Products as possible" and "The minimum required
> number of Products is determined by the GPG key" and "we recommend that you
> bundle all Products and variants of each software within one Product as
> long as they use the same GPG key".
>
> EPEL ships with different GPG keys for each RHEL release (RHEL5, RHEL6 and
> RHEL7). So, for something like this, should I create 1 "EPEL" product and
> add each repo to this, or should I create 3 EPEL products, each with their
> own key? When creating a product, I'm asked to provide a GPG key. As this
> will vary between releases, I'm thinking I would need 3 different products?
>
> Richard.
>
You're right, we do have a custom RPMs Product, which we regularly update,
and indeed we have to republish, increase version and so on.
Here we have to alternatives and may be both of them:
either we add some post-build hammer scripts to automatically publish and
change versions, or
cronjobs to automatically publish and change versions, no matter what's
published
there's no best alternative, every case will have it's solution. More over,
a major part of those scripts will be hard-coded: like content view ids or
names.
Zied.
···
On Fri, Jan 29, 2016 at 4:35 AM, Unix SA wrote:
Hello,
if you are only managing OS contents, this works fine, but if you will
also manage different application contents, it will become difficult at
some stage, for example, you have database, middleware, finance, equities
different application groups, and you want to seperate their contents in
different CVs, you will have to create composite view like
now when you have to update, cv-rhel6-base, you have to publish
"cv-rhel6-base", you again have to change version of all above CCV and
publish it again. which will become difficult evantually. (i am not
creating only one CV as per SOE because, all my contents are not moving at
same speed, middleware is still testing in development but database is
ready for production ).
but if you dont have above requirements, everything just works nicely ( in
my case it doesnt )
)