ixxie has quit [Ping timeout: 264 seconds]
{`-`}_ has joined #nixos-kubernetes
{`-`} has quit [Ping timeout: 246 seconds]
ixxie has joined #nixos-kubernetes
<ixxie> johanot, you around?
<johanot> yep :)
<ixxie> so, I was wondering about how morph deals with hardware-configuration.nix
<ixxie> previously I have had to download those files from newly created VMs
<ixxie> or maybe I just didnt think of a better way to do it :D
<johanot> morph does absolutely no magic :D
<johanot> it cannot provision anything. it can only switch configurations, so it requires an existing nix expression to work on.
<ixxie> and the closure is always built in the deployment machine not the host right>
<ixxie> so I guess there is no way around having to fetch the hardware-config from the host
<johanot> for now only local builds yes, except: you can always configure remote nix builders with nix.conf. And yes, morph will need to have access to the hardware-config, but there's nothing preventing you from executing morph commands from a remote host.
<johanot> but that perhaps beats the purpose of morph, since you might as well just run nixos-rebuild :)
<ixxie> I'm planning to run morph in a github action
<simpson> That sounds like an adventure. Dry-run?
<azazel> what's morph?
<ixxie> simpson: don't know? just getting orientated with morph as well as github actions :D
<simpson> ixxie: Ah, I guess I chained together too much backlog, and guessed that you were going to use GH Actions to deploy to some local hardware, or something like that.
<simpson> ...But after thinking about it for a moment, this makes sense, if you trust your Action's configuration. And if your Action is configured like your existing Morph setup, then that makes a sort of sense.
<ixxie> simpson: I don't have any existing Morph config... my plan is to have a CI/CD pipeline that uses my hosting providers CLI to build a cluster of NixOS machine and the deploy Kubernetes configs to them with Morph.
<ixxie> I guess now the biggest annoyance is there hardware-configuration.nix files... I want a reproducible cluster but these are autogenerated and it seems weird to start having my deployment pipelines commiting them to my git repo
<ixxie> then again I guess autocommiting files is not unheard of
<simpson> Yeah, I'm torn on that front; I don't mind sharing hardware configuration information, but I dislike sharing *my* configuration.
<ixxie> so wait, is there any danger in it?
<simpson> My main thought is only that pulling is better than pushing for automatic actions, so that I'd want to run Morph in each cluster and have the cluster decide for itself whether to update. But I am overly focused on agency and perhaps overcomplicating things.
<simpson> There's no danger, just the normal cringe of publishing dotfiles.
<ixxie> interesting thought about agency... does it bring benefits somehow?
<simpson> Removes the difference between humans and computers in security/threat modeling, which I find *incredibly* desirable and convenient, but which some other researchers find insufferable.
<simpson> Also, pulls compose; pushes don't. e.g. Prometheus can scrape from Prometheus, naturally composing; to do this with pushes requires reconfiguring the entire system.
<simpson> (Also also, as a matter of networking, there's usually technically no such thing as a push; a push is a sort of inverted pull. This may be part of the explanation; not sure.)
<ixxie> simpson: is there any literature you can link me on this idea of agency as a design pattern in general and its relation to security in particular
<azazel> simpson: to pull I use https://docs.fluxcd.io/
<simpson> ixxie: http://www.erights.org/elib/capability/ode/ode-capabilities.html is on HN today. http://www.cap-lore.com/CapTheory/ConfusedDeputy.html is a more traditional starting point. http://habitatchronicles.com/2017/05/what-are-capabilities/ has the good quotes and the good attitude for newcomers.
<simpson> "The capability paradigm is about access control. When a system, such as an OS or a website, is presented with a request for a service it provides, it needs to decide if it should actually do what the requestor is asking for. The way it decides is what we’re talking about when we talk about access control."
<simpson> "If you’re like most people, the first thing you’re likely to think of is to ask the requestor “who are you?” The fundamental insight of the capabilities paradigm is to recognize that this question is the first step on the road to perdition."
<simpson> "That’s highly counterintuitive to most people, hence the related controversy."
<simpson> azazel: Thanks, will check it out.
<ixxie> thank you simpson, I will dig in
<simpson> Good luck. It is not necessarily easy stuff; some folks have an allergic reaction. Take it slow. I'd start with the Confused Deputy; it is short and makes the point.
ixxie has quit [Ping timeout: 240 seconds]
ixxie has joined #nixos-kubernetes
ixxie has quit [Ping timeout: 256 seconds]