Open Stack

Hello Vladimir,

I definitely agree that using one uri for generating number of repos is not
the best solution.
According to Fuel Menu - there was the discussion in gerrit [1] about
repositories format. The first version of my patch implements actually your
idea about equality and independence of repositories. It meets
disagreements and no one voted for this POV. So I had to change the
implementation in favor to the current version.

According to this situation I would like to discuss if proposed changes are
needed before making new patch. Guys, who took part in the previous patch
discussion, please share your opinions.

[1] https://review.openstack.org/#/c/242646/

2015-12-10 22:47 GMT+03:00 Vladimir Kozhukalov <vkozhukalov at mirantis.com>:

> Dear colleagues,
>
> At the moment we have several places where we configure multiple rpm/deb
> repositories. Those are:
>
>    1. Web UI (cluster settings tab) where we define repos for cluster
>    deployment
>    2. Fuel-menu (bootstrap section) where we define repos for building
>    ubuntu bootstrap image
>    3. Fuel-mirror where we define repos that are to be cloned (full or
>    partial mirrors)
>
> I'd prefer all these places to provide the same UX. By that I mean that
> these components should use the same input data structure like this [0],
> i.e. a flat list of fully independent repositories (see an example below).
> First repo in the list is supposed to be a base OS repo (i.e. contains base
> packages like libc).
>
> [
>  {
>     type: deb,
>     url: some-url,
>     section: some-section,
>     suite: some-suite,
>     priority: some-priority
>   },
>   {
>     type: deb,
>     url: another-url,
>     section: another-section,
>     suite: another-suite,
>     priority: another-priority
>   },
> ...
> ]
>
> I'd like to focus on the fact that these repositories should be defined
> independently (no base url, no base suite, etc.) That makes little sense to
> speculate about consistency of a particular repository. We only should talk
> about consistency of the whole list of repositories together.
>
> I'll try to explain. In the real world we usually deal with sets of
> repositories which look like this:
>
> http://archive.ubuntu.com/ubuntu/dists/trusty/
> http://archive.ubuntu.com/ubuntu/dists/trusty-updates/
> http://archive.ubuntu.com/ubuntu/dists/trusty-security/
> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0/
> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-updates/
> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-security/
>
> As you can see these repositories have common hosts and base suites and it
> instills us to think that repositories should not be defined separately
> which is wrong. This special case does not break the whole approach. It is
> just a special case. Repositories are nothing more than just sets of
> packages that can depend on each other forming a tree when taken together.
> Package relation does matter, not repository location, not suite name.
> Parsing package tree for a set of repositories we can easily figure out
> whether this set is consistent or not (e.g. python-packetary allows to do
> this).
>
> Taking into account the above, I'd say UI should allow a user to define
> repositories independently not forcing to use special patterns like suite +
> suite-updates + suite-security, not forcing repositories to be located on
> the same host. That means we should modify fuel-menu bootstrap section
> which currently allows a user to define a base url that is then used to
> form a group of repos (base, base-updates, base-security). Besides, it
> contradicts to our use case when we put mosX.Y locally on the master node
> while mosX.Y-updates and mosX.Y-security are supposed to be available
> online.
>
> What do you guys think of that?
>
>
> [0]
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053
>
>
> Vladimir Kozhukalov
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kind Regards,
Fedor Zhadaev

Skype: zhadaevfm
IRC: fzhadaev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151211/c445d7eb/attachment.html>