<div dir="ltr">This thread is not about format itself, but about the approach when all repos are thought independently. I.e. no patterns like this suite, suite-updates, suite-security, no limitations for suite and suite-updates should be located on the same host. It should be flat list of independent repos. There is an opinion that I am opposing to that when defining repos a user should define only base url and base suite:<div><br></div><div><a href="http://archive.ubuntu.com/ubuntu">http://archive.ubuntu.com/ubuntu</a> <br></div><div>trusty </div><div><br></div><div>and then we are supposed to derive a set of repos like this:<div><br></div><div><div><a href="http://archive.ubuntu.com/ubuntu/dists/trusty">http://archive.ubuntu.com/ubuntu/dists/trusty</a> main universe multiverse restricted</div><div><a href="http://archive.ubuntu.com/ubuntu/dists/trusty-updates">http://archive.ubuntu.com/ubuntu/dists/trusty-updates</a> main universe multiverse restricted</div><div><a href="http://archive.ubuntu.com/ubuntu/dists/trusty-security">http://archive.ubuntu.com/ubuntu/dists/trusty-security</a> main universe multiverse restricted</div></div><div><br></div><div>That is exactly what we have in fuel-menu at the moment. That is wrong (IMO). Why I think it is wrong to hard code "-updates -security" suffixes and "main universe multiverse restricted" sections is described in the very first letter of the ML thread. Again, repos should be independent. There should not be any assumptions about -updates or something like this. That is the main topic of the thread.</div><div><br></div><div><div>Regarding to format of the repo data I think the format that is now used by nailgun [0] (list of dicts) is very convenient and easily extendable. And we should use this format wherever we need to serialize/de-serialize repository data (you can think of this format as a part of Fuel internal communication protocol). We'd better avoid using native formats like apt sources or yum.conf for passing data between Fuel components because it requires having complicated (and thus fragile) code to serialize and de-serialize these data. Native formats should be used only when yum or apt should be directly configured.<br></div></div></div><div><br></div><div>[0] <a href="https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053">https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053</a><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div>Vladimir Kozhukalov</div></div></div>
<br><div class="gmail_quote">On Fri, Dec 11, 2015 at 1:56 PM, Aleksandr Mogylchenko <span dir="ltr"><<a href="mailto:amogylchenko@mirantis.com" target="_blank">amogylchenko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are common practices developed by operating system developers, and thousands of people using them every day.<br>
<br>
Redefining that experience will bring nothing more but questions and misunderstanding, because if someone has questions, instead of hundreds already written manuals a person would be forced to go to us.<br>
<br>
There is nothing wrong in storing it *internally* in whatever format is suitable for Fuel. But UI, in my opinion, should follow practices that already exist, not define something new.<br>
<br>
And, btw, URIs are not repositories, but just one component:<br>
<a href="https://wiki.debian.org/RepositoryFormat" rel="noreferrer" target="_blank">https://wiki.debian.org/RepositoryFormat</a><br>
<br>
--<br>
Aleksandr Mogylchenko<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> On Dec 11, 2015, at 12:29, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>> wrote:<br>
><br>
> Hey folks -<br>
><br>
> +1 from my side on the idea of having the unified repo format. It will<br>
> simplify a cross-project contribution. I think we can file a blueprint<br>
> for 9.0.<br>
><br>
> I have only two questions to discuss:<br>
><br>
> * We need to declare format for RPM repos either.<br>
> * Shouldn't we use slightly different set of fields for flat Debian repos?<br>
><br>
> - Igor<br>
><br>
> On Fri, Dec 11, 2015 at 11:28 AM, Fedor Zhadaev <<a href="mailto:fzhadaev@mirantis.com">fzhadaev@mirantis.com</a>> wrote:<br>
>> Hello Vladimir,<br>
>><br>
>> I definitely agree that using one uri for generating number of repos is not<br>
>> the best solution.<br>
>> According to Fuel Menu - there was the discussion in gerrit [1] about<br>
>> repositories format. The first version of my patch implements actually your<br>
>> idea about equality and independence of repositories. It meets disagreements<br>
>> and no one voted for this POV. So I had to change the implementation in<br>
>> favor to the current version.<br>
>><br>
>> According to this situation I would like to discuss if proposed changes are<br>
>> needed before making new patch. Guys, who took part in the previous patch<br>
>> discussion, please share your opinions.<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/242646/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/242646/</a><br>
>><br>
>> 2015-12-10 22:47 GMT+03:00 Vladimir Kozhukalov <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>>:<br>
>>><br>
>>> Dear colleagues,<br>
>>><br>
>>> At the moment we have several places where we configure multiple rpm/deb<br>
>>> repositories. Those are:<br>
>>><br>
>>> Web UI (cluster settings tab) where we define repos for cluster deployment<br>
>>> Fuel-menu (bootstrap section) where we define repos for building ubuntu<br>
>>> bootstrap image<br>
>>> Fuel-mirror where we define repos that are to be cloned (full or partial<br>
>>> mirrors)<br>
>>><br>
>>> I'd prefer all these places to provide the same UX. By that I mean that<br>
>>> these components should use the same input data structure like this [0],<br>
>>> i.e. a flat list of fully independent repositories (see an example below).<br>
>>> First repo in the list is supposed to be a base OS repo (i.e. contains base<br>
>>> packages like libc).<br>
>>><br>
>>> [<br>
>>> {<br>
>>>    type: deb,<br>
>>>    url: some-url,<br>
>>>    section: some-section,<br>
>>>    suite: some-suite,<br>
>>>    priority: some-priority<br>
>>>  },<br>
>>>  {<br>
>>>    type: deb,<br>
>>>    url: another-url,<br>
>>>    section: another-section,<br>
>>>    suite: another-suite,<br>
>>>    priority: another-priority<br>
>>>  },<br>
>>> ...<br>
>>> ]<br>
>>><br>
>>> I'd like to focus on the fact that these repositories should be defined<br>
>>> independently (no base url, no base suite, etc.) That makes little sense to<br>
>>> speculate about consistency of a particular repository. We only should talk<br>
>>> about consistency of the whole list of repositories together.<br>
>>><br>
>>> I'll try to explain. In the real world we usually deal with sets of<br>
>>> repositories which look like this:<br>
>>><br>
>>> <a href="http://archive.ubuntu.com/ubuntu/dists/trusty/" rel="noreferrer" target="_blank">http://archive.ubuntu.com/ubuntu/dists/trusty/</a><br>
>>> <a href="http://archive.ubuntu.com/ubuntu/dists/trusty-updates/" rel="noreferrer" target="_blank">http://archive.ubuntu.com/ubuntu/dists/trusty-updates/</a><br>
>>> <a href="http://archive.ubuntu.com/ubuntu/dists/trusty-security/" rel="noreferrer" target="_blank">http://archive.ubuntu.com/ubuntu/dists/trusty-security/</a><br>
>>> <a href="http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0/" rel="noreferrer" target="_blank">http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0/</a><br>
>>> <a href="http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-updates/" rel="noreferrer" target="_blank">http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-updates/</a><br>
>>> <a href="http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-security/" rel="noreferrer" target="_blank">http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-security/</a><br>
>>><br>
>>> As you can see these repositories have common hosts and base suites and it<br>
>>> instills us to think that repositories should not be defined separately<br>
>>> which is wrong. This special case does not break the whole approach. It is<br>
>>> just a special case. Repositories are nothing more than just sets of<br>
>>> packages that can depend on each other forming a tree when taken together.<br>
>>> Package relation does matter, not repository location, not suite name.<br>
>>> Parsing package tree for a set of repositories we can easily figure out<br>
>>> whether this set is consistent or not (e.g. python-packetary allows to do<br>
>>> this).<br>
>>><br>
>>> Taking into account the above, I'd say UI should allow a user to define<br>
>>> repositories independently not forcing to use special patterns like suite +<br>
>>> suite-updates + suite-security, not forcing repositories to be located on<br>
>>> the same host. That means we should modify fuel-menu bootstrap section which<br>
>>> currently allows a user to define a base url that is then used to form a<br>
>>> group of repos (base, base-updates, base-security). Besides, it contradicts<br>
>>> to our use case when we put mosX.Y locally on the master node while<br>
>>> mosX.Y-updates and mosX.Y-security are supposed to be available online.<br>
>>><br>
>>> What do you guys think of that?<br>
>>><br>
>>><br>
>>> [0]<br>
>>> <a href="https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053</a><br>
>>><br>
>>><br>
>>> Vladimir Kozhukalov<br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Kind Regards,<br>
>> Fedor Zhadaev<br>
>><br>
>> Skype: zhadaevfm<br>
>> IRC: fzhadaev<br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>