add node aliases, optimized node eval #14
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: DGNum/colmena#14
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "griffi-gh/colmena:alias"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
changes eval strategy and adds aliases attr to node deploy conf
(should work but needs more testing)
based on #13
Old Flow:
New Flow:
There's no separate flow for evaluating just the names anymore; it should be more flexible (controlled by the first step), and in theory, this approach is much simpler.
(It's probably broken though, needs testing :p)
WIP: add node aliasesto add node aliasesba6a9dc798
to9276456b97
griffi-gh referenced this pull request2025-02-19 22:39:28 +01:00
add node aliasesto WIP: add node aliasesIt needs some cleanup, but looks good to me.
@ -399,0 +400,4 @@
assert!(needs_eval.any(), "no need to evaluate");
let expr = format!(
"map (attrs: {{ inherit (attrs) {}{}; }}) hive.deploymentConfig",
missing space between the 2
{}
ininherit (attrs) {}{};
(when both are required).@ -31,0 +81,4 @@
}
fn from_tags(tags: Vec<String>) -> Self {
Self {
aliases: Some(vec![]),
Should be
None
as we only queried tags ?(Same applies for
tags
infrom_aliases
bellow)If it's only for test purposes, maybe these functions should be moved in the test part of the file.
yeah, those are only used for tests... moving them would make sense...
It feels weird that we allow a node to have an alias being the name of another, like
a
andb
, withb.aliases = [ "a" ]
, in which casecolmena apply --on a
applies both nodes. Idk if we want to introduce a warning in such situations.@ -399,0 +397,4 @@
&self,
needs_eval: NeedsEval,
) -> ColmenaResult<HashMap<NodeName, PartialNodeConfig>> {
assert!(needs_eval.any(), "no need to evaluate");
This assert fails in the case of empty filter (which should matches all nodes)
@lbailly wrote in #14 (comment):
i believe that should be a hard error?
WIP: add node aliasesto add node aliasesadd node aliasesto add node aliases, optimized node evaladd node aliases, optimized node evalto WIP: add node aliases, optimized node eval@ -313,1 +364,3 @@
None
/// In case of trivial filters which dont actually use any node info
/// Try to eval them immediately
pub fn try_eval_trivial(&self) -> Option<bool> {
Currently, the only trivial filter is
Empty
as it's not possible to build trivialUnion
orInter
(trivial = size < 2), nor to have anEmpty
in a leaf of a more complex filter.(In syntactic analysis,
!a&a
is trivial, but require a semantic analysis, which I don't think we want)Yea, I agree that it's kinda over-engineered...
(but it does handle the Empty case so i guess its fine?)
Should i change this?
I don't think it's necessary to change this, this over-engineering won't weight much and will make future development cleaner (if the invariant was invalidated for example).
@ -31,0 +33,4 @@
// pub enum NeedsEval {
// Tags,
// Aliases,
// }
You can remove
@ -318,3 +393,4 @@
}
}
// TODO fix tests
they look good to me, no ?
yeah i forgot to remove it
i already fixed them in ba6a9dc798d77b3e32dfb1302543827cbaaf3a34
Forgot to write the final comment: it just need to make
aliases
optional, to avoid the errorand there's two dead code warning
@ -399,0 +441,4 @@
let expr = format!(
"(mapAttrs (name: attrs: {{ inherit (attrs) {} {}; }}) hive.deploymentConfig)",
needs_eval.aliases.then_some("aliases").unwrap_or_default(),
needs_eval.tags.then_some("tags").unwrap_or_default(),
no
in
src/nix/hive/options.nix
you should addWIP: add node aliases, optimized node evalto add node aliases, optimized node evalLGTM @rlahfa
b4e269759d
to57dc8e8ccd
57dc8e8ccd
to55b56196d5
@ -93,6 +93,7 @@ with builtins; rec {
# Largely compatible with NixOps/Morph.
deploymentOptions = { name, lib, ... }: let
inherit (lib) types;
mdDoc = lib.mdDoc or lib.id;
Why is
mdDoc
needed? That seems dead code to me.that part is from the #13
since i based the pr on it
(idk what the mdDoc is for, but the flake was failing to evaluate because of a missing variable
so i copied the same let binding that was used in the other 2 sections)
@ -29,2 +30,4 @@
}
#[derive(Clone, Copy, Debug, Default)]
pub struct NeedsEval {
What is
NeedsEval
, can we have a comment on what is this structure supposed to carry?which parts of the deployment metadata need to be evaluated to run the filter.
(Should probably add a doc comment)
@ -264,0 +317,4 @@
|| config
.aliases
.as_ref()
.expect("aliases missing")
expect
means we are crashing here, can we have better error reporting?@ -266,1 +325,3 @@
.tags()
.tags
.as_ref()
.expect("tags missing")
expect
means we are crashing here, can we have better error reporting?this error should never happen as tags are guaranteed to be gathered by the previous step (even the tags are empty, the field should never be None)
Panic if tags/deployment info is missing was also the original behavior before the rewrite...
same sith the aliases one
makes sense
Few changes and we can merge.
55b56196d5
to3ef5ba8658
I don't think those two parts need proper error handling
(the panic behaviour matches the original one and should never happen at runtime, unless there's another huge bug with eval)
I added the documentation to the
NeedsEval
struct as requested