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

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-$releas... 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-releas... 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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>