[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Deep merge in 0.10.10 and 10.12.0


Chronological Thread 
  • From: Michael Glenney < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Deep merge in 0.10.10 and 10.12.0
  • Date: Tue, 4 Sep 2012 16:36:17 -0700

Thanks for all the replies.  I'll have a read through all that but it sounds like I'm going to have to reengineer how we supply node data for our haproxy configs.  Or stay on 0.10.8 :)   Unfortunately, we don't use roles in our organization because they can't be versioned so that's not an option.

It does seem like a weird thing to get rid off though.  Is there another way to clear an attribute and put in new data without that?  Or once a node has data that data must live on forever unless you use roles? 

I suppose the problem ultimately is that we don't use roles.  I just need to find a way around this.  Putting this data in data_bags isn't an option since nodes can't edit data_bags unless they have admin rights so we only use data bags for data that doesn't get updated often or at runtime.

MG

On Tue, Sep 4, 2012 at 4:18 PM, Daniel DeLeo < " target="_blank"> > wrote:
Note that this behavior is intentional:


Also, knockouts will most likely be removed from Chef 11.0. See:


-- 
Daniel DeLeo

On Tuesday, September 4, 2012 at 4:14 PM, Juanje Ojeda Croissier wrote:

Yes, I'm running 10.12.0, but I did it with a role. Maybe that's it.

On Wed, Sep 5, 2012 at 12:02 AM, Michael Glenney < " target="_blank"> > wrote:
Hmm. You're running 10.12.0? I just tested again. Started with the
following:

Node data (with 'knife node show <nodename> -Fj'):

"haproxy": {
"config": "classroom.cfg.erb",
"nodes": {
"portal_api": [
"2.2.2.2",
"3.3.3.3"
]
}

haproxy config:

server portal_api-2.2.2.2 2.2.2.2:443 check port 443 inter 10s rise 4 fall
4
server portal_api-3.3.3.3 3.3.3.3:443 check port 443 inter 10s rise 4 fall
4

I ran 'chef-client -j /etc/chef/routing_rules.json' with the following in
"routing_rules.json":

{ "haproxy": { "nodes": { "portal_api": [ "!merge:", "10.10.10.10",
"11.11.11.11" ] } } }


This is what I ended up with:

Node data:

"haproxy": {
"config": "classroom.cfg.erb",
"nodes": {
"portal_api": [
"2.2.2.2",
"3.3.3.3",
"!merge:",
"10.10.10.10",
"11.11.11.11"
]
}

haproxy config:

server portal_api-2.2.2.2 2.2.2.2:443 check port 443 inter 10s rise 4 fall
4
server portal_api-3.3.3.3 3.3.3.3:443 check port 443 inter 10s rise 4 fall
4

server portal_api-!merge: !merge::443 check port 443 inter 10s rise 4 fall
4
server portal_api-10.10.10.10 10.10.10.10:443 check port 443 inter 10s
rise 4 fall 4
server portal_api-11.11.11.11 11.11.11.11:443 check port 443 inter 10s
rise 4 fall 4

The docs say you can run without the colon now but I'm not seeing a
difference. Doesn't work either way.

MG


On Tue, Sep 4, 2012 at 3:41 PM, Juanje Ojeda Croissier

I believe the issue here is the " (without the colon) ". I had some
troubles here as well, but it's now working with the colon
("!merge:").

Could you test it with colon, please?

wrote:
I have now verified that putting !merge does not work in 10.12.0 I'll
go
back an read over the link AJ sent again but it appears as if deep merge
is
gone or broken.

Here's the json I passed to the chef-client run:

{ "haproxy": { "nodes": { "portal_api": [ "!merge", "4.4.4.4", "5.5.5.5"
] }
} }

Here's the resulting haproxy config:

server portal_api-!merge !merge:443 check port 443 inter 10s rise 4
fall 4
server portal_api-4.4.4.4 4.4.4.4:443 check port 443 inter 10s rise 4
fall
4
server portal_api-5.5.5.5 5.5.5.5:443 check port 443 inter 10s rise 4
fall
4

Not what I was going for obviously.

MG


wrote:

Yeah. Looking at your link it looks like using "!merge" (without the
colon) will probably work. just need to test it. That goes along with
what
it says in the wiki except for the fact that the wiki says it "can" be
used
instead of saying it must.

MG

wrote:

From DeepMerge mixin class:

# Inherited roles use the knockout_prefix array subtraction
functionality
# This is likely to go away in Chef >= 0.11
def role_merge(first, second)
first = Mash.new(first) unless first.kind_of?(Mash)
second = Mash.new(second) unless second.kind_of?(Mash)

DeepMerge.deep_merge(second, first, {:knockout_prefix =>
"!merge", :preserve_unmergeables => false})
end




Maybe there's something useful for you here.

I've only once used the attribute knockout functionality -- what is
your use case? There may be another simple solution.

--AJ

wrote:
Weird. For some reason it's not sending me my own. Oh well. Have
there
been any responses to my question? Because I dont see any of those
either

Michael Glenney
Sent from my iPhone


Nope - I saw it two days ago.

Adam

On Sun, Sep 2, 2012 at 10:04 AM, Michael Glenney
I sent this on friday. Still hasn't made it to my inbox. Am I
getting
moderated?

Michael Glenney
Sent from my iPhone

On Aug 31, 2012, at 4:08 PM, Michael Glenney
wrote:

I had a problem with deep merge not working properly in 10.12.0.
Tested in
0.10.10 and it didn't work there either. Instead of replacing my
array it
was actually putting "!merge:" into my array.

After I reverted to 0.10.4 to get my deployment completed I
stumbled
on this

"!merge (without the colon) can be used in Chef >= 0.10.10"

I haven't had a chance to go back and test. Will have to wait
until
Monday.
But should that line read:

"!merge (without the colon) MUST be used in Chef >= 0.10.10"

Thanks,

MG



--
Opscode, Inc.
Adam Jacob, Chief Customer Officer



--
Juanje




--
Juanje






Archive powered by MHonArc 2.6.16.

§