Open Stack

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 <
vkozhukalov at 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 <
> akostrikov at 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 <
>> vkozhukalov at 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 <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
>>>
>>>
>>
>>
>> --
>>
>> 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: akostrikov at mirantis.com <elogutova at 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-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/29a4d0a2/attachment.html>