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
