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 :
> If there are no any objections, let's do fix fuel-menu ASAP. As Fedor said
> this approach w
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://b
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 <
vkozhuka...@mirantis.com> wrote:
> I'd like this module
> https://github.com/openst
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
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-up
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 :
> 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 en
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-
This thread is not about format itself, but about the approach when all
repos are thought independently. I.e. no patterns like this suite,
suite-updates, suite-security, no limitations for suite and suite-updates
should be located on the same host. It should be flat list of independent
repos. There
> 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. Priorit
There are common practices developed by operating system developers, and
thousands of people using them every day.
Redefining that experience will bring nothing more but questions and
misunderstanding, because if someone has questions, instead of hundreds already
written manuals a person would
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) w
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
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 r
13 matches
Mail list logo
