[RFC] Host's repositories support
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. * 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. * 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. * 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. * 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
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
Looks like a pretty reasonable structure. A few comments/questions follow inline. On 1/29/2014 12:03 PM, Paulo Ricardo Paz Vital wrote: 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Adam King <rak@linux.vnet.ibm.com> IBM CSI
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
* 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
* 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.
* 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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/Ever... 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/$base... 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 02/05/2014 05:30 PM, Paulo Ricardo Paz Vital wrote:
Hi Aline, my comments.
On Mon, 2014-02-03 at 09:55 -0200, Aline Manera 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
On 01/29/2014 03:03 PM, Paulo Ricardo Paz Vital wrote: 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/Ever... 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/$base... 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!
OK. But the repo_id will be also an optional parameter The user should just need to provide the URL to create a repo From my view there are 2 possibilities: - User provides repo_id and repo_url - User provides just repo_url and kimchi generates a repo_id for him Like we have for templates. Keep in mind, Kimchi needs to be easy to use by any kind of users: experts or not. Because that, the main idea of Kimchi is require the minimum information from user (to simplify the follow)
* 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (3)
-
Adam King -
Aline Manera -
Paulo Ricardo Paz Vital