Yup, I am hoping to avoid all of these kinds of customizations if
possible... But if we have to we'll probably have to make something like
that.
Or we'll just have to render out files for each host and serve it from
the same REST endpoint, ya da ya da...
-Josh
Michał Jastrzębski wrote:
How
On 30 January 2018 at 09:34, Joshua Harlow wrote:
> I'm ok with #2,
>
> Though I would like to show an alternative that we have been experimenting
> with that avoids the whole needs for a globals.yml and such files in the
> first place (and feels more naturally inline with how ansible works IMHO).
I'm ok with #2,
Though I would like to show an alternative that we have been
experimenting with that avoids the whole needs for a globals.yml and
such files in the first place (and feels more naturally inline with how
ansible works IMHO).
So short explanation first; we have this yaml format
Sometimes there are features that require different containers to be
deployed, or different config files to be generated. These are things that
cannot be done simply through merging a fixed set of config files.
nova_compute_virt_type
is an example of such a variable - various non-config tasks depen
On 30/01/18 12:54, Simon Leinen wrote:
The perceived downside of (2) - or a perceived advantage of (1) - is
that in an ideal world, (1) isolates us from the arcane configuration
file details that the crazy devs of individual services come up with.
In practice, it turns out that (a) those files ar
Paul Bourke writes:
> So I think everyone is in agreement that it should be option 2. I'm
> leaning towards this also but I'm wondering how much of this makes
> things easier for us as developers rather than operators.
> How committed this are we in practice? For example, if we take
> nova.conf[0]
Zhang
Reply-To: "OpenStack Development Mailing List (not for usage
questions)"
Date: Monday, January 29, 2018 at 7:14 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [kolla] Policy regarding template
customisation
Than
-steve
From: Jeffrey Zhang
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Monday, January 29, 2018 at 7:14 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [kolla] Policy regarding template cus
Monday, January 29, 2018 at 7:14 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Subject: Re: [openstack-dev] [kolla] Policy regarding template customisation
>
>
>
> Thank Paul for pointing this out.
>
>
>
> for me, I prefer to cons
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Monday, January 29, 2018 at 7:14 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [kolla] Policy regarding template customisation
Thank Paul f
I have to agree - I prefer the minimal approach of option 2. It keeps the
kolla-ansible code base small and easy to understand. The required test
matrix is therefore relatively small (although better coverage of services
in CI would be good). Finally, the approach has allowed the project to move
qu
Thank Paul for pointing this out.
for me, I prefer to consist with 2)
There are thousands of configuration in OpenStack, it is hard for Kolla to
add every key/value pair in playbooks. Currently, the merge_config is a more
better solutions.
On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke wrote:
Hi all,
I'd like to revisit our policy of not templating everything in
kolla-ansible's template files. This is a policy that was set in place
very early on in kolla-ansible's development, but I'm concerned we
haven't been very consistent with it. This leads to confusion for
contributors and o
13 matches
Mail list logo
