BTW, here you can see an example http://demo.fuel-infra.org:8000 Just go to any cluster and see Repositories section on the settings tab.
Vladimir Kozhukalov On Fri, Dec 11, 2015 at 5:46 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > I'd like this module > https://github.com/openstack/fuel-menu/blob/master/fuelmenu/modules/bootstrapimg.py > 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. > > 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. > > 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. > > > > Vladimir Kozhukalov > > On Fri, Dec 11, 2015 at 5:10 PM, Alexander Kostrikov < > akostri...@mirantis.com> wrote: > >> 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 >> >> >
__________________________________________________________________________ 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
