Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork364
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
base:master
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
roberth commentedJan 3, 2023
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 commentedJan 3, 2023
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 |
roberth commentedJan 3, 2023
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 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. |
kampka commentedJan 4, 2023
Honestly, I was not aware that nixops had a concept of remote logs till yesterday.
This would of course solve my personal aesthetic requirements of programs not cluttering my
Fair enough. As I said, this issue is not really a priority any more. |
Uh oh!
There was an error while loading.Please reload this page.
The locks feel a bit inconsistent atm. as the state is stored in
$NIXOPS_STATEwhile locks are still stored in$HOME/.nixops.