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 <[email protected]>: > 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 < > [email protected]> 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 < >> [email protected]> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 < >>>>> [email protected]> 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 >>>>>> <[email protected]> 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 < >>>>>> [email protected]> 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 < >>>>>> [email protected]> 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 < >>>>>> [email protected]>: >>>>>> >>>> >>>>>> >>>> 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: >>>>>> [email protected]?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: >>>>>> [email protected]?subject:unsubscribe >>>>>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>> >>>>>> >> >>>>>> >> >>>>>> __________________________________________________________________________ >>>>>> >> OpenStack Development Mailing List (not for usage questions) >>>>>> >> Unsubscribe: >>>>>> [email protected]?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: >>>>>> [email protected]?subject:unsubscribe >>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>>> __________________________________________________________________________ >>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>> Unsubscribe: >>>>>> [email protected]?subject:unsubscribe >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>> >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> [email protected]?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: [email protected] <[email protected]> >>>> >>>> *www.mirantis.com <http://www.mirantis.ru/>* >>>> *www.mirantis.ru <http://www.mirantis.ru/>* >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
