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

Aline Manera alinefm at linux.vnet.ibm.com
Wed Feb 5 19:50:21 UTC 2014


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:
>> 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!

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 at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>




More information about the Kimchi-devel mailing list