[Kimchi-devel] [RFC] Host's repositories support

Paulo Ricardo Paz Vital pvital at linux.vnet.ibm.com
Wed Feb 5 19:30:55 UTC 2014


Hi Aline, my comments.

On Mon, 2014-02-03 at 09:55 -0200, Aline Manera wrote:
> On 01/29/2014 03:03 PM, Paulo Ricardo Paz Vital wrote:
> > Hello guys.
> >
> > This is the RFC for the Host's repositories support (task "Register YUM,
> > apt, zypper repos" of 1.2 sprint 3).
> >
> > The support will be provided by adding in the control/host.py a new
> > collection (Repositories), responsible to manage all repositories of the
> > system, and a new resource (Repository), responsible to operate with a
> > specific repository. All this management/operations will be transparent
> > to host's package management system, being provided by one of the new
> > back end classes.
> >
> > The back end support provides 4 new classes:
> >
> > 1) Repositories (object): Class to represent and operate with
> > repositories information in Kimchi's perspective. It's transparent to
> > host's package management system, and can execute all operations
> > necessary: add repository, get all repositories list, get information
> > about one repository, update a repository, enable and disable a
> > repository and remove a repository. This class will load in run time the
> > necessary classes to work with the host's package management: YumRepo
> > for YUM systems based, AptRepo for APT systems based and ZypperRepo for
> > Zypper systems based;
> >
> > 2) YumRepo (object): Class to represent and operate with YUM
> > repositories. Loaded only on those systems that supports YUM (e.g.
> > Fedora and RHEL), it's responsible to connect, collect and provide
> > information of YUM repositories in the system. Also it's responsible to
> > create/delete the files in disk to maintain the repositories in system
> > after disconnection.
> >
> > 3) AptRepo (object): Class to represent and operate with APT
> > repositories. Loaded only on those systems that supports APT (e.g.
> > Debian and Ubuntu), it's responsible to connect, collect and provide
> > information of APT repositories in the system. Also it's responsible to
> > create/delete the files in disk to maintain the repositories in system
> > after disconnection.
> >
> > 4) ZypperRepo (object): Class to represent and operate with Zypper
> > repositories. Loaded only on those systems that supports Zypper (e.g.
> > OpenSuse), it's responsible to connect, collect and provide information
> > of Zypper repositories in the system. Also it's responsible to
> > create/delete the files in disk to maintain the repositories in system
> > after disconnection.
> >
> > Bellow I present the REST API for the repositories support.
> >
> > ### Collection: Host Repositories
> >
> > **URI:** /host/repositories
> >
> > **Methods:**
> >
> > * **GET**: Retrieve a summarized list of all repositories available
> > * **POST**: Add a new repository
> >      * repo_id : Unique repository name for each repository, one word.
> 
> is repo_id required? I think the user can only input the repo_name and 
> baseurl and it will be
> enough to create a new repo

Here we have two different things: repo_id, one word, used to create an
unique ID to the repository, and this cannot be used before; repo_name,
something that you and me can read and understand about this repository.

But the point is, YUM needs, at least, 3 information while adding a new
repository: repo_id, repo_name and baseurl or mirrorlist. For exemple,
from my fedora.repo file, I have:

[fedora]
name=Fedora $releasever - $basearch
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1

[updates]
name=Fedora $releasever - $basearch - Updates
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch
enabled=1


The name between [ ] is the repo_id, the sentence after name= is the
repo_name, and the URL in mirrorlist is the baseurl with the is_mirror
flag described below set up.

I can provide a mechanism to create an repo_id based on repo_name, but
YUM uses it to provide information to user, like:

$ yum repolist
repo id           repo name                      status
fedora/19/x86_64  Fedora 19 - x86_64             36,253
updates/19/x86_64 Fedora 19 - x86_64 - Updates   17,391

$ yum update
Dependencies Resolved
=========================================================================
 Package         Arch    Version               Repository           Size
=========================================================================
Updating:
 autocorr-en     noarch  1:4.1.4.2-5.fc19      updates             157 k
 coreutils       x86_64  8.21-13.fc19          updates             3.3 M

So, if something needs be droped, I say repo_name!

> 
> >      * repo_name: Human-readable string describing the repository.
> >      * baseurl: URL to the repodata directory when "is_mirror" is false.
> > Otherwise, it can be URL to the mirror system for YUM. Can be an
> > http://, ftp:// or file://  URL.
> >      * is_mirror *(optional)*: Set the given URI of baseurl as a mirror
> > list, instead of use baseurl in repository configuration.
> >      * url_args *(optional)*: Arguments to be passed to baseurl, like the
> > list of APT repositories provided by the same baseurl.
> 
> >      * enabled *(optional)*: Indicates if repository should be included
> > as a package source:
> >          * false: Do not include the repository.
> >          * true: Include the repository.
> 
> We can also remove the "enabled"  parameter. We can follow the same 
> logic we do for networks and storage pools
> When creating a new resource it will be disable by default, them user 
> can enable/activate it

Ok, I'm going to change, but only to follow project's logic, that IMO is
not good. 
If I'm adding something to somewhere, I want this available when I click
"ADD" button. I don't like the idea of add something and then execute 3
more clicks to enable the feature.

> 
> >      * gpgcheck *(optional)*: Indicates if a GPG signature check on the
> > packages gotten from repository should be performed:
> >          * false: Do not check GPG signature
> >          * true: Check GPG signature
> >      * gpgkey *(optional)*: URL pointing to the ASCII-armored GPG key
> > file for the repository. This option is used if yum needs a public key
> > to verify a package and the required key hasn't been imported into the
> > RPM database.
> >
> > ### Resource: Repository
> >
> > **URI:** /host/repositories/*:repo-id*
> >
> > **Methods:**
> >
> > * **GET**: Retrieve the full description of a Repository
> >      * repo_id : Unique repository name for each repository, one word.
> 
> >      * repo_type: Indicates which type of repository is:
> >          * yum: Indicates it is a YUM repository.
> >          * deb: Indicates it is a APT repository.
> >          * zyp: Indicates it is a Zypper repository.
> 
> Does the repo_type relative to host SO? or it is the repo type itself?
> 
> Because if it is the repo type, zypper also allow YUM repositories - so 
> we need to update the documentation.

I guess this is useless. Will drop in RFC V2.

> 
> >      * repo_name: Human-readable string describing the repository.
> >      * baseurl: URL to the repodata directory when "is_mirror" is false.
> > Otherwise, it can be URL to the mirror system for YUM. Can be an
> > http://, ftp:// or file://  URL.
> >      * url_args *(optional)*: Arguments to be passed to baseurl, like the
> > list of APT repositories provided by the same baseurl.
> >      * enabled *(optional)*: Indicates if repository should be included
> > as a package source:
> >          * false: Do not include the repository.
> >          * true: Include the repository.
> >      * gpgcheck *(optional)*: Indicates if a GPG signature check on the
> > packages gotten from repository should be performed:
> >          * false: Do not check GPG signature
> >          * true: Check GPG signature
> >      * gpgkey *(optional)*: URL pointing to the ASCII-armored GPG key
> > file for the repository. This option is used if yum needs a public key
> > to verify a package and the required key hasn't been imported into the
> > RPM database.
> > * **DELETE**: Remove the Repository
> > * **POST**: *See Repository Actions*
> > * **PUT**: update the parameters of existing Repository
> >      * repo_id *(otional)*: Unique repository name for each repository,
> > one word.
> 
> As the user will not provide the repo_id (we will select one for him) we 
> can remove it from PUT method too
> 
> >      * repo_name *(otional)*: Human-readable string describing the
> > repository.
> >      * baseurl *(optional)*: URL to the repodata directory when
> > "is_mirror" is false. Otherwise, it can be URL to the mirror system for
> > YUM. Can be an http://, ftp:// or file://  URL.
> >      * is_mirror *(optional)*: Set the given URI of baseurl as a mirror
> > list, instead of use baseurl in repository configuration.
> >      * url_args *(optional)*: Arguments to be passed to baseurl, like the
> > list of APT repositories provided by the same baseurl.
> >      * enabled *(optional)*: Indicates if repository should be included
> > as a package source:
> >          * false: Do not include the repository.
> >          * true: Include the repository.
> >      * gpgcheck *(optional)*: Indicates if a GPG signature check on the
> > packages gotten from repository should be performed:
> >          * false: Do not check GPG signature
> >          * true: Check GPG signature
> >      * gpgkey *(optional)*: URL pointing to the ASCII-armored GPG key
> > file for the repository. This option is used if yum needs a public key
> > to verify a package and the required key hasn't been imported into the
> > RPM database.
> >
> > **Actions (POST):**
> >
> > * enable: Enable the Repository as package source
> > * disable: Disable the Repository as package source
> >
> >
> >
> > _______________________________________________
> > Kimchi-devel mailing list
> > Kimchi-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/kimchi-devel
> >
> 




More information about the Kimchi-devel mailing list