Open Stack

Folks, when you get consensus here, please file a bug - it's most likely
fixable in 8.0.

2015-12-11 14:44 GMT+03:00 Vladimir Kozhukalov <vkozhukalov at mirantis.com>:

> 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
>>
>
>
> __________________________________________________________________________
> 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151211/0dc4c1cb/attachment.html>