Here is how I would like to proceed:
* We move forward with mmccune's proposal for a "--allow-uploads" flag
on *all* repository objects.
* The flag will be set to *off* by default for repositories created with
a feed;
and *on* for default repositories created without a feed; as this is
what is required to support the RHEL/Fedora use cases we know of today.
* For now, we will not expose the attribute (setting or getting) via our
CLI tooling (client or admin); only in the data model.
* Attempts to modify the default values for this attribute will raise
an "unsupported" error condition.
* Single feed per repository maximum.
* In the future as time and focus permits (and future use cases become
clearer), we could/will add support for the alternative states:
* On for repository with feed
* Off for repository without feed
-Todd
On 10/11/2010 11:17 AM, Pradeep Kilambi wrote:
Should we allow the case where, user creates a repo with a feed, syncs
down the content and then tries to upload additional content to the
same repo?
Pros:
* A user probably will have an easy time adding custom content to
their repos without having to create new repos
Cons:
* We need to regenerate metadata for the repo. Today we get the
metadata for repos with feed directly from the feed.
* Will need to worry about what version of RHEL/Fedora pulp is running
on for compatible yum metadata.
* For Red Hat repos, we probably dont want to allow this anyway. So
we'll need some extra rules to bypass this.
Overall seems like keeping uploads separate from feed repos is
cleaner. User can always create a new repo, upload content and
subscribe to both repos to get that additional content.
Lemme know your feedback.
~ Prad
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
