EugenMayer / chef-tinc-cookbook

Chef cookbook for creating tinc vpn networks
MIT License
4 stars 3 forks source link

Prepare 2.0.0 release #26

Open EugenMayer opened 4 years ago

EugenMayer commented 4 years ago

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

zedtux commented 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?

EugenMayer commented 4 years ago

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

zedtux commented 4 years ago

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.

zedtux commented 4 years ago

New PR replacing #27 is #28

zedtux commented 4 years ago

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. 😉

EugenMayer commented 4 years ago

@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!

EugenMayer commented 3 years ago

@zedtux you asked for a new release, should we then continue here?

zedtux commented 3 years ago

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.

EugenMayer commented 3 years ago

This is awesome @zedtux - thank you for all the effort!

zedtux commented 3 years ago

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! 🤩

zedtux commented 3 years ago

Actually you've released the version 2, this issue should be closed, right?

EugenMayer commented 3 years ago

@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?

zedtux commented 3 years ago

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.

EugenMayer commented 3 years ago

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?

zedtux commented 3 years ago

Looking really great !

EugenMayer commented 3 years ago

We kind of fell asleep again, did we? :)

zedtux commented 3 years ago

Well, actually I had to remove TincVPN from my stack so I will have no time working on this one 😕.

EugenMayer commented 3 years ago

Oh I see, no worries. Did you move on to something else?

zedtux commented 3 years ago

I was using TincVPN with Kubernetes, and the Flannel CNI. Now I moved to the Calico CNI + WireGuard.

EugenMayer commented 3 years ago

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).

zedtux commented 3 years ago

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.