Open EugenMayer opened 4 years ago
Yep, I'd like to add the Policy groups support too.
BTW are you using roles/environments today? And if you are, how are you using them?
Back in time, about starting 8 years before or something and until 3 years ago, i was using roles/envs heavily and extensively.
Now days, 95% of my infrastructure is Docker based, thus chef is rather a niche tool for configuring the barebone platforms like proxmox/openstack and special systems ( rare ). Right now, i do not even run a chef server, but i deploy using knife-zero which is just right for what i use it. I did never use policifiles yet
chef is rather a niche tool for configuring the barebone platforms like proxmox/openstack and special systems ( rare ).
But in order to do it, are you using environments, like staging/production?
I'm asking you this 'cause as I already said, if you're using one chef repository to manage those environments, then you would face the issue I'm facing.
No matter Policyfile or the roles/envs model, the way to define attributes is the same 😉.
i deploy using knife-zero
And I'm doing the same, but I'm building a tool on top of that in order to ease its use.
New PR replacing #27 is #28
Hi @EugenMayer,
Short comment to say that I have to stop working on this cookbook for a month (I'm moving of country + holidays) and then will be slow for some weeks. 😉
@zedtux you have already put so much time into this, i really thankful. Thank you sharing!
Great holidays to you and hopefully not a lot of things get broken during moving :)
I will update this issue to target 2.0.0 due to the openssl / minimum Chef changes for now and wait for your return for any further plans on this.
Stay safe!
@zedtux you asked for a new release, should we then continue here?
Oh yes, sure! So issue #31 is the only remaining one that I'd like to fix for 2.0.0 then.
I will take care of this last issue and come back to you, it's really sort like 30 minutes of work I would say (and impact is really small as it doesn't prevent the cookbook to work properly.
This is awesome @zedtux - thank you for all the effort!
I'm really glad you appreciate it! I was really happy to find this cookbook after having discovered the TincVPN, contributing to this cookbook is a way to say "Thanks!" for what you did! 🤩
Actually you've released the version 2, this issue should be closed, right?
@zedtux yes and no - I actually tried to release a beta1, but this is not allowed with the supermarket and I had then to release a stable (which I did not plan).
I had to release it since I was doing provisioning of fresh new boxes and could test it, but out of some reason I could not use the repo HEAD in berkshelf, so I did the dirty hack at some point releasing it.
I would actually like to prepare 2.1.0 with some of the fixes right away since I do not think that 2.0.0 is stable enough.
The issues I had were all related to the new code we added, specifically related to the new "auto-guess" features and the follow-up conditions which are confused. I guess the reason is, that the implementation is too big and the non-functional way of dealing with it grows out of our heads. We have a hard time understanding the scope and impact of the code since it is one huge scope and side effects are too big/invisible at first.
Either we for now just fix the issues or we still have left or we try to split the implementation into several functions, maybe even recipes on top of it, to split the complexity in understandable chunks.
What do you think?
Yeah, actually I'm used to create helper methods in a libraries/
folder but I didn't want to completely rewrite the recipe.
I would suggest you to open issues for each of the one you are facing so that we can better discuss them and find a way to solve them. Ideally even write tests which reproduce your issues so that we can make it more stable.
Please tell me if this would be fine by you.
I recently started with libraries to my defines and mostly used structural recipes beforehand.
I have rewritten all my recipes in the form that I no longer access attributes in the recipes but rather something like kwbase.hasSubnet?
or kwbase.getNetworkName(id)
- so all attribute access topics are hidden behind the wrapper library encapsulating the actual attributes.
I would love to refactor it or you starting with it so we can handle all the glimpses and aspects und understand the side effects.
An example what I did is
# https://mearnsb.medium.com/attributes-are-dead-long-live-helper-libraries-e936513793cc
class KontextWorkBase
def initialize(node)
@node = node
end
def getOsCodeName
@node['lsb']['codename']
end
def configureGrub?
nodeOrDefaultAttr(:kontextwork, :base, :grub)
end
def configureDefaultAdmins?
nodeOrDefaultAttr(:kontextwork, :base, :default_admins)
end
def configureSshServer?
nodeOrDefaultAttr(:kontextwork, :base, :sshd)
end
def getSshPort
nodeOrDefaultAttr(:sshd, :sshd_config, :Port)
end
# and a lot more
end
class Chef
class Resource
def kwbase
KontextWorkBase.new(node)
end
end
class Recipe
def kwbase
KontextWorkBase.new(node)
end
end
end
I did the same for all the other cookbooks and it really made all the things better. I guess you will also like to have tool methods and I guess we will think about having several of those classes maybe for "Network" and "BaseConfig" and then use those - also add the iterator and stuff there.
What do you think?
Looking really great !
We kind of fell asleep again, did we? :)
Well, actually I had to remove TincVPN from my stack so I will have no time working on this one 😕.
Oh I see, no worries. Did you move on to something else?
I was using TincVPN with Kubernetes, and the Flannel CNI. Now I moved to the Calico CNI + WireGuard.
Yeah, i guess Wireguard is currently taking it all in (I assume there are good reasons for that). I did not yet have happen to touch it and not sure if it is similar to tinc in terms of meshing, riding vs routing and sorts - but it has really spreaded widely and is already far more spreaded then tinc (by a magnitude).
I can't tell you much, I've just enabled a flag in the Calico CNI and installed a package on the host machine.
I read a bit about WireGuard, and there are many differences and seems to address different use cases.
We need to set the scope for 1.1.0 - probably just the buster support, maybe policyfile.
@zedtux any ideas / suggestions?
I created the milestone 1.1.0 to set our roadmap