Feature request: Profile deployment

[DieracDelta]

Thoughts on adding a deployment part to the utils? Ideally this would work across multiple deployment tools, but the one I use is deploy-rs so I'll roll with that specific example, though it could also be extended to nixops, etc. My thought is a flake along the lines of:

hosts.HostnameExample = {
        ....
    deploy-to = {
    type = "deploy-rs";
    hosts = [ "101.101.101.101"; "101.101.101.102"; ];
  };
};

The idea is that FUP builds the attributes and checks used by deploy-rs if the deploy-to set is not empty. The big question in my mind is: is this out of scope for this project? And is there demand for this feature? Another issue is this might be oversimplifying deployment. However, this would let the user take the equivalent utility functions out of their flake.nix. As far as I can tell, this is the entire point of FUP. And I think it hits the sweet spot of use cases for deployment tool users: "I want to deploy my flake hosts to my server cluster."

On the implementation side, all this would need to do is generate a bunch of deploy.nodes attributes, similarly to what I've done here. I could see FUP picking sane defaults, such as fastConnection = false and user=sshUser="root" which could be overridden.

Does this fits in the vision for FUP?

[blaggacao]

@Pacman99 and me have pondered about the possibility of including more "configuration builders", such as for home manager and deploy-rs.

However, aome of them might introduce additional dependencies (such as deploy-rs) and it is declared objective of this project to be dependency free.

The reason is that it remains a universal and slick tool that does not pretend upon what dependencies one wants to have included.

That being said, we are working on a conceptual :onion: of things in this order:

flake-utils → flake-utils-plus → devos-lib → devos-templates.

Hope that makes sense.

Currently, we work on the extraction of devos-lib which should make it in the coming days into the main branch. devos-lib currently comes with (opinionated) deploy-rs, cachix & home-manager integrations.

[Pacman99]

home-manager builder doesn't actually depend on anything, you just pass it self.nixosConfigurations and if your hosts have the home-manager module enabled then it can just pull the home configurations from there.

deploy-rs could be added here but one of the arguments for the function could be deploy itself. deployConfigurationBuilder = { deploy, nixosConfigurations }: ...

[gytis-ivaskevicius]

Just a thought: I bet it would be quite easy to create concept of optional dependency by just filterAttrs (it: it.outputs.someProperty) inputs 🤔

On Tue, Apr 20, 2021, 17:20 David Arnold @.***> wrote:

@Pacman99 https://github.com/Pacman99 and me have pondered about the possibility of including more "configuration builders", such as for home manager and deploy-rs.

However, aome of them might introduce additional dependencies (such as deploy-rs) and it is declared objective of this project to be dependency free.

The reason is that it remains a universal and slick tool that does not pretend upon what dependencies one wants to have included.

That being said, we are working on a conceptual 🧅 of things in this order:

flake-utils → flake-utils-plus → devos-lib (without "no-dependency" rule and additional conveniences) → devos-templates.

Hope that makes sense.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gytis-ivaskevicius/flake-utils-plus/issues/41#issuecomment-823314062, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFRP5RRC3BQ2JG3AKTY65W3TJWETNANCNFSM43HBU22A .

[blaggacao]

I think @nrdxp had already explored that to programatically manipulate inputs. It's not possible.

Flakes need a notion of development deps, but that's another issue.

So I'd suggest closing this defering to the divnix/devos sister project which does not have those dependency restriction.

I still think no-deps is one of flake-utils-plus bedrock features.

[blaggacao]

Ah wait! @Pacman99 do we still need to make the generic config builder even more generic so that it can output a deploy.nodes (nested attribute)?

[DieracDelta]

I agree with you. Doesn't seem like it belongs here, so I'll close the issue.

Out of curiosity, though: couldn't we pass in the input? E.g. something like

outputs = inputs:
...
hosts.HostnameExample = {
        ....
    deploy-to = {
    type = inputs.deploy-rs;
    hosts = [ "101.101.101.101"; "101.101.101.102"; ];
  };
};
...

Then, the FUP code would go in and basically do something akin to pattern matching on the type to create the node topology IF the type wasn't null and was something it knew how to handle. This wouldn't introduce dependencies explicitly.

[Pacman99]

Ah wait! @Pacman99 do we still need to make the generic config builder even more generic so that it can output a deploy.nodes (nested attribute)?

I don't think so, since deploy-rs nodes don't need any fancy pkgs handling - one of the main features of fup - theres no benefit to using the hosts arg for deploy outputs. You may as well just do deploy.nodes = mkNodes ....

[blaggacao]

@DieracDelta I see you are wishing to deploy one host config to different IPs. Of that is correct, you'd have to coerce a lot of other prerequisites about those machines, too, like architecture, etc.

Devos lifts those.limitation by introducingbsuites which is a machine agnostic global configuration, like "developmemt-suite" or "gaming-suite" that you could pull into each host.

The benefit is that you can attend different hosts of different characteristics (e.g. archs) uniformely, while it also preserves a 1:1 mapping to deploy-rs.

I think that's a betrer way of thinging about the underlaying data structures than deploying one host to two different IPs.

If those IPs represent two interfaces of the same host, then that is an issue that coyld be opened upstream with deploy-rs, instead.