On 04/15/2014 03:05 PM, Miroslav Suchy wrote:

Hi, I created first prototype of Playground repo (you know - release early...).

The playground repo is just set of Copr repositories. I.e. some Copr projects can have attribute "playground" set to true (currently no interface, only directly in DB). I choosed randomly several projects and set the flag to true.

There is an API call to get list of those projects: http://copr.fedoraproject.org/api/playground/list/ (currently undocumented, because I plan to make some changes).

I wrote DNF plugin (based on Copr DNF plugin). You can test it by: curl https://raw.githubusercontent.com/akozumpl/dnf-plugins-core/master/plugins/c...

...

/usr/lib/python2.7/site-packages/dnf-plugins/copr.py

You could wrap the plugin in an RPM and publish in playground repo itself :) Self-hosting FTW

and you can do: dnf playground enable which will enable all Copr project, which are marked as part of Playground and store them in /etc/yum.repos.d/_playground_<owner>_<projectname>.repo and: dnf playground upgrade which will fetch new repos (by removing all old repos and fetch all playground repos). and: dnf playground disable which will delete all /etc/yum.repos.d/_playground_*.repo

As I said, this is first prototype (although functional) and it have some glitches. But you can get the idea.

Is this the path we want to follow? Questions? Comments?

Works for me (to the extent of DNF limitations, that is).

I'd expect assumeyes option to work (i.e. "dnf -y playground enable" should not wait for user input).

Playground repos could be better distinguished from other repos. If a user with FAS name "fedora" creates copr named "updates", then his copr could be easily mistaken for standard "fedora-updates" repo and so on.

Otherwise it looks good.

On 15 April 2014 14:05, Miroslav Suchy msuchy@redhat.com wrote:

Is this the path we want to follow? Questions? Comments?

I really hoped that the playground repo was going to be GPG signed.

Richard

Hi!

On Tue, 2014-04-15 at 15:05 +0200, Miroslav Suchy wrote:

I created first prototype of Playground repo (you know - release early...).

Cool, nice to see some code!

There is an API call to get list of those projects: http://copr.fedoraproject.org/api/playground/list/ (currently undocumented, because I plan to make some changes).

At the time of writing, it gives me "500 Internal Server Error"?

Is this the path we want to follow? Questions? Comments?

As I tried to explain on yesterday's Env and Stacks WG meeting [1], the previous steps on defining the Playground repository lead in the direction of having a real repository (for example, the first paragraph of [2] talks about "Repositories/packages successfully built and satisfying the Playground repository's Policies are copied into the Playgroud repository.").

I think the approach you presented (having a set of COPRs with the Playground flag + the Playground DNF plugin that handles them) looks interesting, but I would like to hear how you envision extending this approach to support some of following features:

1) Signing packages with an independent Playground repository key. I assume that if we add support for signing packages in Copr, each <user> or each <user-repo> will have its own key and when the <user-repo> becomes part of the Playground repository, we'll want to sign it with the Playground repository key.

2) Automatic gating/sanity-check on package update. Let's say user joe requested his foo repo be added to the Playground repository. To process the request, packages in joe/foo are sanity-checked with Taskotron and added to the list of Playground repositories. The next day Joe updates packages in joe/foo and (inadvertently) breaks them so they no longer pass the sanity-checks of Taskotron. In the case of having a real repository, where packages are feed from COPRs (i.e. copied over), users will continue to see the old packages in joe/foo that passed the sanity checks, whereas in case of this "virtual" repository, they would automatically be upgraded and break their systems.

Note about disk space constraints: Couldn't we hardlink the copied packages so they wouldn't consume twice the amount of space?

3) Handling package/repository removals (leaving legal issues to the other thread [3]). For example, user joe removes his joe/foo COPR that was also part of the Playground repository. After a week, frank encounters a problem with a package from the joe/foo COPR that he previously installed on his system. His tech-savvy fried bob is trying to reproduce the problem on his system but he is unable to since joe/foo is no longer available.

Tadej

[1] http://meetbot.fedoraproject.org/fedora-meeting/2014-04-15/env-and-stacks.20... [2] https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_(draft)#... [3] https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-April/000381.h...