Open Stack

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 <ikalnitsky at 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
> <afedorova at 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 <ikalnitsky at 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 <fzhadaev at 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 <
> vkozhukalov at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151211/7ae13ad9/attachment.html>