<div dir="ltr">BTW, here you can see an example <a href="http://demo.fuel-infra.org:8000">http://demo.fuel-infra.org:8000</a> Just go to any cluster and see Repositories section on the settings tab.</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 5:46 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">I'd like this module <a href="https://github.com/openstack/fuel-menu/blob/master/fuelmenu/modules/bootstrapimg.py" target="_blank">https://github.com/openstack/fuel-menu/blob/master/fuelmenu/modules/bootstrapimg.py</a> to be fixed so a user can define several repos independently. This particular ML thread is not about internal repo data format, it is not about particular format that we expose to end user. This thread is rather about flexibility of repo configuration. Whether we expose Fuel internal format or native format, UI must be flexible enough to allow a user to define repos independently. That is it. <div><br></div><div><div>There is no reason to think that repository structure will always follow the pattern suite suite-updates suite-security, there is no reason to think that sections will always be main, universe, multiverse, restricted, there is no reason to think that all suites will be located on the same host. <br></div><div><br></div><div>I am not a big expert in UX. I like what we currently have on Web UI (is native format). I don't suggest to change this. I suggest to use something similar of what we have on Web UI in our fuel-menu. </div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div></font></span></div></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 5:10 PM, Alexander Kostrikov <span dir="ltr"><<a href="mailto:akostrikov@mirantis.com" target="_blank">akostrikov@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">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/" style="font-size:12.8px" target="_blank">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"><span><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></span><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><span><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></span></div></div></div><div class="gmail_extra"><div><div><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><font color="#888888"><div><br></div></font></span></div><div class="gmail_extra"><span><font color="#888888"><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div></font></span><div><div>
<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></div><div><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>
<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></div></div>
</blockquote></div><br></div>