Hello, Vladimir. 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: http://url trusty main http://anotherurl trusty universe multiverse restricted http://yet-another-url trusty-my-favorite-updates my-favorite-section
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. Like generalization of algorithms in such way: >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. On Fri, Dec 11, 2015 at 2:44 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > 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: > > http://url trusty main > http://anotherurl trusty universe multiverse restricted > http://yet-another-url trusty-my-favorite-updates my-favorite-section > > While we (for some reasons) limited our UI to define only base url and > base suite. That should be fixed. > > > Vladimir Kozhukalov > > On Fri, Dec 11, 2015 at 2:33 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: > >> > Do we really need a custom format? Why can not we use native format >> > for yum.conf and apt.sources files >> >> Because we don't want to parse this format each time we want to verify >> / handle particular component of this format. Moreover, there's no, >> for example, priority in Debian repo format. Priority is used by apt >> preference (not by repo itself). >> >> We're talking about Fuel internal representation, and it would be nice >> to have one internal format across various Fuel projects. >> >> >> > But UI, in my opinion, should follow practices that already exist, not >> define something new. >> >> AFAIU, the idea is to unified internal representation and keep UI as >> close to distributive standards. >> >> On Fri, Dec 11, 2015 at 12:53 PM, Aleksandra Fedorova >> <afedor...@mirantis.com> wrote: >> > Hi, >> > >> > I agree with the idea of unification for repo configurations, but it >> > looks like we are developing yet another standard. >> > >> > Do we really need a custom format? Why can not we use native format >> > for yum.conf and apt.sources files, and native tooling (all those >> > python bindings, cli utils and so on) which is already developed to >> > work with them? >> > >> > On Fri, Dec 11, 2015 at 1:29 PM, Igor Kalnitsky < >> ikalnit...@mirantis.com> wrote: >> >> Hey folks - >> >> >> >> +1 from my side on the idea of having the unified repo format. It will >> >> simplify a cross-project contribution. I think we can file a blueprint >> >> for 9.0. >> >> >> >> I have only two questions to discuss: >> >> >> >> * We need to declare format for RPM repos either. >> >> * Shouldn't we use slightly different set of fields for flat Debian >> repos? >> >> >> >> - Igor >> >> >> >> On Fri, Dec 11, 2015 at 11:28 AM, Fedor Zhadaev <fzhad...@mirantis.com> >> wrote: >> >>> 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 < >> vkozhuka...@mirantis.com>: >> >>>> >> >>>> Dear colleagues, >> >>>> >> >>>> At the moment we have several places where we configure multiple >> rpm/deb >> >>>> repositories. Those are: >> >>>> >> >>>> Web UI (cluster settings tab) where we define repos for cluster >> deployment >> >>>> Fuel-menu (bootstrap section) where we define repos for building >> ubuntu >> >>>> bootstrap image >> >>>> 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-requ...@lists.openstack.org?subject:unsubscribe >> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Kind Regards, >> >>> Fedor Zhadaev >> >>> >> >>> Skype: zhadaevfm >> >>> IRC: fzhadaev >> >>> >> >>> >> __________________________________________________________________________ >> >>> OpenStack Development Mailing List (not for usage questions) >> >>> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>> >> >> >> >> >> __________________________________________________________________________ >> >> OpenStack Development Mailing List (not for usage questions) >> >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > -- >> > Aleksandra Fedorova >> > CI Team Lead >> > bookwar >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kind Regards, Alexandr Kostrikov, Mirantis, Inc. 35b/3, Vorontsovskaya St., 109147, Moscow, Russia Tel.: +7 (495) 640-49-04 Tel.: +7 (925) 716-64-52 <%2B7%20%28906%29%20740-64-79> Skype: akostrikov_mirantis E-mail: akostri...@mirantis.com <elogut...@mirantis.com> *www.mirantis.com <http://www.mirantis.ru/>* *www.mirantis.ru <http://www.mirantis.ru/>*
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
