[katello] modifying repository attributes in content views

Support
1

There are times when I wish I could edit the attributes of a repository in
a specific content view and am wondering how hard this would be.

For example, I sync RHEL-7.2 with a download policy of on demand. From
there I craft a content view with specific filters and publish and promote
it to my production lifecycle environment. At that point, I'd like to use
inter-server sync (ISS) to export for use in another organization. However,
ISS does not work with on demand. For my use case, I'd like to switch the
download policy of the specific repo in the product content view to
immediate, then sync it to pull down all the packages.

Another use case would be creating unprotected custom product repos
("Publish via HTTP") but then when they make it to my production
environment, switching them to protected HTTPS.

Is manipulating aspects of repositories in content views something others
would find useful? Is this a difficult thing to implement?

2

Hi Tom,

I don't believe that download policy is an attribute of a content view, only of a product repository, as packages aren't really owned by CVs, they are just referenced by CVs. So this change would really be at the product/repo level and affect consumers of that repo. You should be able to change the download policy of a repository at any time regardless of whether it is referenced via a CV or not and then initiate a sync (such as if you are moving from on demand to immediate).

Sorry if I'm not following you,

j

··· From: "Tom McKay" To: foreman-users@googlegroups.com Sent: Thursday, November 10, 2016 10:20:53 AM Subject: [foreman-users] [katello] modifying repository attributes in content views

There are times when I wish I could edit the attributes of a repository in a specific content view and am wondering how hard this would be.

For example, I sync RHEL-7.2 with a download policy of on demand. From there I craft a content view with specific filters and publish and promote it to my production lifecycle environment. At that point, I’d like to use inter-server sync (ISS) to export for use in another organization. However, ISS does not work with on demand. For my use case, I’d like to switch the download policy of the specific repo in the product content view to immediate, then sync it to pull down all the packages.

Another use case would be creating unprotected custom product repos (“Publish via HTTP”) but then when they make it to my production environment, switching them to protected HTTPS.

Is manipulating aspects of repositories in content views something others would find useful? Is this a difficult thing to implement?

–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [ mailto:foreman-users+unsubscribe@googlegroups.com | foreman-users+unsubscribe@googlegroups.com ] .
To post to this group, send email to [ mailto:foreman-users@googlegroups.com | foreman-users@googlegroups.com ] .
Visit this group at [ https://groups.google.com/group/foreman-users | https://groups.google.com/group/foreman-users ] .
For more options, visit [ https://groups.google.com/d/optout | https://groups.google.com/d/optout ] .

3

> Hi Tom,
>
> I don't believe that download policy is an attribute of a content view,
> only of a product repository, as packages aren't really owned by CVs, they
> are just referenced by CVs. So this change would really be at the
> product/repo level and affect consumers of that repo. You should be able
> to change the download policy of a repository at any time regardless of
> whether it is referenced via a CV or not and then initiate a sync (such as
> if you are moving from on demand to immediate).
>
> Sorry if I'm not following you,
>
> j
>
>
Each version of a content view has a reference to its own version of a
product repo. So for CV-1.0, there is a repo, and for CV-2.0 there is a
repo. My goal would be to allow the attributes of these separate repos to
be managed separately. How that management is presented to user user (eg.
is it tied to the content view, the lifecycle environment, or that version
of a repo) would be worth discussing. I'm interested, though, if anyone
else has seen the need for something like this.

··· On Thu, Nov 10, 2016 at 12:24 PM, 'Jason B. Nance' via Foreman users < foreman-users@googlegroups.com> wrote:

*From: *“Tom McKay” thomasmckay@redhat.com
*To: *foreman-users@googlegroups.com
*Sent: *Thursday, November 10, 2016 10:20:53 AM
*Subject: *[foreman-users] [katello] modifying repository attributes in
content views

There are times when I wish I could edit the attributes of a repository in
a specific content view and am wondering how hard this would be.

For example, I sync RHEL-7.2 with a download policy of on demand. From
there I craft a content view with specific filters and publish and promote
it to my production lifecycle environment. At that point, I’d like to use
inter-server sync (ISS) to export for use in another organization. However,
ISS does not work with on demand. For my use case, I’d like to switch the
download policy of the specific repo in the product content view to
immediate, then sync it to pull down all the packages.

Another use case would be creating unprotected custom product repos
(“Publish via HTTP”) but then when they make it to my production
environment, switching them to protected HTTPS.

Is manipulating aspects of repositories in content views something others
would find useful? Is this a difficult thing to implement?

–
You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

4

Hi Tom,

I don't believe that download policy is an attribute of a content view, only of a product repository, as packages aren't really owned by CVs, they are just referenced by CVs. So this change would really be at the product/repo level and affect consumers of that repo. You should be able to change the download policy of a repository at any time regardless of whether it is referenced via a CV or not and then initiate a sync (such as if you are moving from on demand to immediate).

Sorry if I'm not following you,

j

> Each version of a content view has a reference to its own version of a product repo. So for CV-1.0, there is a repo, and for CV-2.0 there is a repo. My goal would be to allow the attributes of these separate repos to be managed separately. How that management is presented to user user (eg. is it tied to the content view, the lifecycle environment, or that version of a repo) would be worth discussing. I'm interested, though, if anyone else has seen the need for something like this.

In your example of download policies how would this work, though? Each CV doesn't have its own copy of a package, right? I thought that CVs were basically just symlinks and database entries and that pulp was unaware of them.

I don't mean to derail and I'm sorry if I'm focusing too much on one specific example. You noted download policy and http/https publishing. Is that where you would draw the line or would you also include mirror on sync, metadata, etc?

j

··· On Thu, Nov 10, 2016 at 12:24 PM, 'Jason B. Nance' via Foreman users < [ mailto:foreman-users@googlegroups.com | foreman-users@googlegroups.com ] > wrote:
5

>
>
>
>> Hi Tom,
>>
>> I don't believe that download policy is an attribute of a content view,
>> only of a product repository, as packages aren't really owned by CVs, they
>> are just referenced by CVs. So this change would really be at the
>> product/repo level and affect consumers of that repo. You should be able
>> to change the download policy of a repository at any time regardless of
>> whether it is referenced via a CV or not and then initiate a sync (such as
>> if you are moving from on demand to immediate).
>>
>> Sorry if I'm not following you,
>>
>> j
>>
>>
> > Each version of a content view has a reference to its own version of a
> product repo. So for CV-1.0, there is a repo, and for CV-2.0 there is a
> repo. My goal would be to allow the attributes of these separate repos to
> be managed separately. How that management is presented to user user (eg.
> is it tied to the content view, the lifecycle environment, or that version
> of a repo) would be worth discussing. I'm interested, though, if anyone
> else has seen the need for something like this.
>
> In your example of download policies how would this work, though? Each CV
> doesn't have its own copy of a package, right? I thought that CVs were
> basically just symlinks and database entries and that pulp was unaware of
> them.
>
> I don't mean to derail and I'm sorry if I'm focusing too much on one
> specific example. You noted download policy and http/https publishing. Is
> that where you would draw the line or would you also include mirror on
> sync, metadata, etc?
>
> j
>
>
No derailing; good discussion.

I'm not that familiar with the inner workings of pulp so my notions may not
be realistic.

Perhaps the "on demand changed to immediate" does not map to anything in
pulp but is an attribute in katello that lets me force-sync all the
packages that make up a repo in a cv.

The expose of http vs. https would simply be the removal of the versioned
repo down the published/yum/http/ path, which I don't know if pulp would do
or not.

Here are the paths for one of my synced repos for reference:

published/yum/http/repos/examplecorp/content_views/katellonightly/2.0/custom/zoo

published/yum/http/repos/examplecorp/content_views/katellonightly/2.0/custom/zoo/zoo

published/yum/http/repos/examplecorp/content_views/katellonightly/1.0/custom/zoo

published/yum/http/repos/examplecorp/content_views/katellonightly/1.0/custom/zoo/zoo

published/yum/http/repos/examplecorp/Development/katellonightly/custom/zoo
published/yum/http/repos/examplecorp/Development/katellonightly/custom/zoo/zoo

published/yum/http/repos/examplecorp/Library/katellonightly/custom/zoo
published/yum/http/repos/examplecorp/Library/katellonightly/custom/zoo/zoo
published/yum/http/repos/examplecorp/Library/custom/zoo
published/yum/http/repos/examplecorp/Library/custom/zoo/zoo
published/yum/https/repos/examplecorp/content_views/katellonightly/2.0/custom/zoo

published/yum/https/repos/examplecorp/content_views/katellonightly/2.0/custom/zoo/zoo

published/yum/https/repos/examplecorp/content_views/katellonightly/1.0/custom/zoo

published/yum/https/repos/examplecorp/content_views/katellonightly/1.0/custom/zoo/zoo

published/yum/https/repos/examplecorp/Development/katellonightly/custom/zoo
published/yum/https/repos/examplecorp/Development/katellonightly/custom/zoo/zoo

published/yum/https/repos/examplecorp/Library/katellonightly/custom/zoo
published/yum/https/repos/examplecorp/Library/katellonightly/custom/zoo/zoo
published/yum/https/repos/examplecorp/Library/custom/zoo
published/yum/https/repos/examplecorp/Library/custom/zoo/zoo

··· On Thu, Nov 10, 2016 at 1:17 PM, 'Jason B. Nance' via Foreman users < foreman-users@googlegroups.com> wrote: > On Thu, Nov 10, 2016 at 12:24 PM, 'Jason B. Nance' via Foreman users < > foreman-users@googlegroups.com> wrote:

–
You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.