Hi guys,
If we're talking about implementation of new features, this should go to
ansible-devel list
Thanks!
On Fri, Dec 6, 2013 at 2:23 AM, Kahlil Hodgson <
kahlil.hodg...@dealmax.com.au> wrote:
> Ergh, hit send too fast.
>
> The branch you want to look at is called 'merge-filter'.
>
> Apolog
Ergh, hit send too fast.
The branch you want to look at is called 'merge-filter'.
Apologies if this makes no sense because:
1. I've had a few beers,
2. I'm writing this on a tram,
3. My python skills are limited.
K
Kahlil (Kal) Hodgson GPG: C9A02289
Head of Technology
Er maybe?
Checkout my quick implementation at https://github.com/tartansandal/ansible.git
If I run the following against it
---
- name: merging like a maniac
hosts: localhost
connection: local
vars:
- foo:
- a:
- luck:
a: c
b: d
- b
Kahlil,
Is this how you'd expect your solution to work?
I'm thinking in your case you'd have a
group_vars/all:
default_mysql:
setting1: foo
setting2: bar
setting3: baz
group_vars/prod_mysql
setting2: bip
and maybe you had a role called mysql that internally used "mysql" as
the varia
I don't like it at all.
We shouldn't be inserting lesser known YAML syntax into things, especially
if we have to define a new "directive".
This would be moving Ansible down the wrong direction.
On Thu, Dec 5, 2013 at 5:14 PM, James Martin wrote:
> Brian,
>
> That's interesting -- so if "!!
Brian,
That's interesting -- so if "!!merge" was specified somewhere down the
line that var would get merged versus replaced? I like it!
- James
On Thu, Dec 5, 2013 at 4:58 PM, Brian Coca wrote:
> this is easy to implement using yaml tags/directives, but would look a bit
> diff:
>
> mysql: !!m
this is easy to implement using yaml tags/directives, but would look a bit
diff:
mysql: !!merge
port: some_default_value4
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, sen
Something like this sounds like a good compromise!
-- Michael
> On Dec 5, 2013, at 2:48 PM, Kahlil Hodgson
> wrote:
>
> I wonder if merging could be handled explicitly with a jinja filter,
> say, something like:
>
>mysql: prod_mysql | merge(default_mysql)
>
> That way the merging would be e
I'd rather not introduce something like that as adds something rather
abstract to think about which would not be immediately clear when
auditing the playbook.
-- Michael
> On Dec 5, 2013, at 12:17 PM, James Martin wrote:
>
> Thanks for the example. Would it be crazy/possible to implement
> opti
On 5 December 2013 20:48, Kahlil Hodgson wrote:
> I wonder if merging could be handled explicitly with a jinja filter,
> say, something like:
>
> mysql: prod_mysql | merge(default_mysql)
>
> That way the merging would be explicit and encapsulated in the playbook.
>
I agree it would be a good
I wonder if merging could be handled explicitly with a jinja filter,
say, something like:
mysql: prod_mysql | merge(default_mysql)
That way the merging would be explicit and encapsulated in the playbook.
Kahlil (Kal) Hodgson GPG: C9A02289
Head of Technology
Thanks for the example. Would it be crazy/possible to implement
optional merging dependent on the hash's name? Seems like for some
vars you could possibly want it, in others, not. So things that are
in nature restrictive like sudo would be merged, and others wouldn't.
something like:
hash_beha
group_vars/all:
tomcat_jvm_settings:
- debug=on
- GCfunckymode=True
- dump_heap=true
group_vars/prod:
tomcat_jvm_settings:
- XmxMax: 234324
- XmxMin: 12342
with merge off, i can use same settings for dev/qa/staging and differnt
ones for prod, if i had merge ON, i would have to always overr
Yep!
-- Michael
> On Dec 4, 2013, at 3:32 PM, James Martin wrote:
>
> I'm trying to visualize a case where hash merging would be bad:
>
> Let's you had this in your group_vars/all
>
> foo:
> bar: baz
> zib: zab
>
> but at some point you wanted to override that completely with:
>
> foo:
> bar:
I'm trying to visualize a case where hash merging would be bad:
Let's you had this in your group_vars/all
foo:
bar: baz
zib: zab
but at some point you wanted to override that completely with:
foo:
bar: biz
If you had merging on, that would yield:
foo:
bar: biz
zib: zab
Without mer
There's no problem doing it either way, but you're right in that the first
requires configuring host variable merging in ansible.cfg (which is not the
standard option).
As a result, people shouldn't really write roles for sharing that rely on
that in many cases.
On Wed, Dec 4, 2013 at 2:05 PM,
Is it considered bad practice to have variables in group_vars defined as such:
ntp:
server: server.foo.com
setting: foo
myapp:
database: bar
option: baz
instead of :
ntp_server: server.foo.com
ntp_setting: foo
myapp_database: bar
myapp_option: baz
It seems the first option is cle
17 matches
Mail list logo
