search

NixOS / nixops

NixOps is a tool for deploying to NixOS machines in a network or cloud.
https://nixos.org/nixops
GNU Lesser General Public License v3.0
1.86k stars 365 forks source link

Manage deployment locks in $NIXOPS_STATE dir if provided #1533

Open kampka opened 2 years ago

kampka commented 2 years ago

The locks feel a bit inconsistent atm. as the state is stored in $NIXOPS_STATE while locks are still stored in $HOME/.nixops.

roberth commented 1 year ago

I understand the feeling, but I'm not confident that this is the right thing to do in the context of state and locking plugins. How are these features supposed to interact?

kampka commented 1 year ago

Sorry, I can't follow, can you explain your thoughts with a bit more context regarding your concerns?

In any case, I have moved mostly to nixops master with flakes while porvisioning with Terraform, so I am sort of happy with the memory backend for at the moment. Feel free to close this issue if feel this is not actionable.

roberth commented 1 year ago

Perhaps the local deployment lock and the remote lock interface should be merged into one interface. Instead of a noop remote lock by default, we'd have the local deployment lock as the default, and the remote lock would replace the local lock.

Another option would be to move the locks to /run, essentially saying "this is non-persistent state that's managed for you; you don't need to care about its placement".

I guess what I'm trying to say is I haven't decided and I don't think I know enough about the design and implementation at this point to say anything definitive. I might prioritize other PRs first, although I'd be happy to discuss the nixops state design and requirements.

kampka commented 1 year ago

Perhaps the local deployment lock and the remote lock interface should be merged into one interface. Instead of a noop remote lock by default, we'd have the local deployment lock as the default, and the remote lock would replace the local lock.

Honestly, I was not aware that nixops had a concept of remote logs till yesterday. I agree with your suggestion, I think the local lock offers little benefit in presence of a remote lock, so merging the interfaces is probably a good idea.

Another option would be to move the locks to /run, essentially saying "this is non-persistent state that's managed for you; you don't need to care about its placement".

This would of course solve my personal aesthetic requirements of programs not cluttering my $HOME. I think it also makes sense regarding clarification about what those locks are intended for.

I guess what I'm trying to say is I haven't decided and I don't think I know enough about the design and implementation at this point to say anything definitive. I might prioritize other PRs first, although I'd be happy to discuss the nixops state design and requirements.

Fair enough. As I said, this issue is not really a priority any more.