Open Stack

Hi, Vladimir,

Please be informed that we'll have to also make an appropriate changes on
the fuel-agent side. But yes, it's possible to do it before SCF.

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

> If there are no any objections, let's do fix fuel-menu ASAP. As Fedor said
> this approach was suggested first, but then it was rejected during review
> process. It should not be so hard to get it back. Fedor, could you please
> confirm that it is possible to do this before SCF? Here is the bug
> https://bugs.launchpad.net/fuel/+bug/1525323
>
> Vladimir Kozhukalov
>
> On Fri, Dec 11, 2015 at 5:48 PM, Vladimir Kozhukalov <
> vkozhukalov at mirantis.com> wrote:
>
>> 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
>>>>
>>>>
>>>
>>
>
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151214/78e56c06/attachment.html>