Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Manage deployment locks in $NIXOPS_STATE dir if provided#1533

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
kampka wants to merge1 commit intoNixOS:master
base:master
Choose a base branch
Loading
fromkampka:locks-nixops-state

Conversation

@kampka
Copy link

@kampkakampka commentedJul 25, 2022
edited
Loading

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

lukebfox reacted with thumbs up emoji
@roberth
Copy link
Member

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
Copy link
Author

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 tonixops master with flakes while porvisioning with Terraform, so I am sort of happy with thememory backend for at the moment. Feel free to close this issue if feel this is not actionable.

@roberth
Copy link
Member

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
Copy link
Author

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.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@kampka@roberth

[8]ページ先頭

©2009-2025 Movatter.jp