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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 < > [email protected]>: > >>>> > >>>> 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: > [email protected]?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: > [email protected]?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >> > >> > __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > [email protected]?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: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
