<div dir="ltr">Hello, Vladimir.<div>Seems nothing is better for end-user in UI/fuel-mirror/image-bootstrap than 'You Get What You See' because system administrator should not learn new standard:</div><div><a href="http://url/" target="_blank" style="font-size:12.8px">http://url</a><span style="font-size:12.8px"> </span><span style="font-size:12.8px">trusty main</span><br></div><div><div style="font-size:12.8px"><div><a href="http://anotherurl/" target="_blank">http://anotherurl</a> trusty universe multiverse restricted</div><div><a href="http://yet-another-url/" target="_blank">http://yet-another-url</a> trusty-my-favorite-updates my-favorite-section</div><div><br></div><div>Can You point to difference between current scheme rpm/deb libraries in Python and 'New Format' If You are talking about their representation in fuel code to understand pros of such format.</div><div><br></div><div>Like generalization of algorithms in such way:</div><div>><span style="font-size:12.8px">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.</span></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 2:44 PM, Vladimir Kozhukalov <span dir="ltr"><<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Regarding to UI. Of course, we could provide native format to a user on UI. Although I don't think it would be much easier to edit, but it is flexible enough to define something like this:<div><br></div><div><div><a href="http://url" target="_blank">http://url</a> trusty main </div><div><a href="http://anotherurl" target="_blank">http://anotherurl</a> trusty universe multiverse restricted</div><div><a href="http://yet-another-url" target="_blank">http://yet-another-url</a> trusty-my-favorite-updates my-favorite-section</div></div><div><br></div><div>While we (for some reasons) limited our UI to define only base url and base suite. That should be fixed.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div></font></span><div><div class="h5">
<br><div class="gmail_quote">On Fri, Dec 11, 2015 at 2:33 PM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> Do we really need a custom format? Why can not we use native format<br>
> for yum.conf and apt.sources files<br>
<br>
</span>Because we don't want to parse this format each time we want to verify<br>
/ handle particular component of this format. Moreover, there's no,<br>
for example, priority in Debian repo format. Priority is used by apt<br>
preference (not by repo itself).<br>
<br>
We're talking about Fuel internal representation, and it would be nice<br>
to have one internal format across various Fuel projects.<br>
<span><br>
<br>
> But UI, in my opinion, should follow practices that already exist, not define something new.<br>
<br>
</span>AFAIU, the idea is to unified internal representation and keep UI as<br>
close to distributive standards.<br>
<div><div><br>
On Fri, Dec 11, 2015 at 12:53 PM, Aleksandra Fedorova<br>
<<a href="mailto:afedorova@mirantis.com" target="_blank">afedorova@mirantis.com</a>> wrote:<br>
> Hi,<br>
><br>
> I agree with the idea of unification for repo configurations, but it<br>
> looks like we are developing yet another standard.<br>
><br>
> Do we really need a custom format? Why can not we use native format<br>
> for yum.conf and apt.sources files, and native tooling (all those<br>
> python bindings, cli utils and so on) which is already developed to<br>
> work with them?<br>
><br>
> On Fri, Dec 11, 2015 at 1:29 PM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>> wrote:<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" target="_blank">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" target="_blank">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>
><br>
><br>
> --<br>
> Aleksandra Fedorova<br>
> CI Team Lead<br>
> bookwar<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>
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>
</div></div></blockquote></div><br></div></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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><p style="margin-bottom:0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">Kind Regards,<br></span></p><p style="margin-bottom:0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">Alexandr Kostrikov,<br></span></p><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US"><br>Mirantis, Inc.</span><span style="font-family:Arial,sans-serif;color:rgb(31,73,125)" lang="EN-US"></span>
<p style="margin:0cm 0cm 0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">35b/3, Vorontsovskaya
St., 109147, Moscow, Russia</span><span style="font-family:Arial,sans-serif;color:rgb(31,73,125)" lang="EN-US"></span></p>
<p style="margin:0cm 0cm 0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US"><br>
Tel.: <a href="tel:%2B7%20%28495%29%20640-49-04" value="+74956404904" target="_blank">+7 (495) 640-49-04</a><br>
Tel.: <a href="tel:%2B7%20%28906%29%20740-64-79" value="+79067406479" target="_blank">+7 (925) 716-64-52</a></span><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US"></span></p>
<p style="margin:0cm 0cm 0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">Skype: akostrikov_mirantis</span></p>
<p style="margin:0cm 0cm 0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">E-mail:<span> </span></span><span style="font-size:10pt;font-family:Arial,sans-serif"><a href="mailto:elogutova@mirantis.com" target="_blank"><span style="color:rgb(17,85,204)" lang="EN-US"><span><span><span>akostrikov@mirantis.com</span></span></span></span></a></span><span style="font-family:Arial,sans-serif" lang="EN-US"></span></p>
<p style="margin-bottom:0.0001pt"><u><span style="font-size:10pt;font-family:Arial,sans-serif"><a href="http://www.mirantis.ru/" target="_blank"><span style="color:rgb(17,85,204)" lang="EN-US">www.mirantis.com</span></a></span></u><u><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US"><br>
</span></u><u><span style="font-size:10pt;font-family:Arial,sans-serif"><a href="http://www.mirantis.ru/" target="_blank"><span style="color:rgb(17,85,204)" lang="EN-US">www.mirantis.ru</span></a></span></u><span style="font-family:Arial,sans-serif" lang="EN-US"></span></p></div></div>
</div>