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

Adam King rak at linux.vnet.ibm.com
Wed Jan 29 20:02:52 UTC 2014


Looks like a pretty reasonable structure.
A few comments/questions follow inline.

On 1/29/2014 12: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.
Can we default the ID rather than require it as input?
>      * repo_name: Human-readable string describing the repository.
Can we query this from the repository itself, rather than making it 
required input?
>      * 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.
>      * gpgcheck *(optional)*: Indicates if a GPG signature check on the
Can this not be inferred from the presence of a gpgkey? When would 
someone want to provide a key, but not check it?
> 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.
Do we need to provide the means to import the key into yum? Does this 
apply to other repo types besides yum?
>
> ### 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:
Will there ever be more than one repo type for a given host? When would 
someone need this info, or can it be omitted?
>          * yum: Indicates it is a YUM repository.
>          * deb: Indicates it is a APT repository.
>          * zyp: Indicates it is a Zypper repository.
>      * 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.
enabled should not be optional. The get should always tell the caller if 
the repo is enabled or not.
>      * 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.
>      * 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
>

-- 
Adam King <rak at linux.vnet.ibm.com>
IBM CSI




More information about the Kimchi-devel mailing list