Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a single additional cache is not enough #545

Closed
blaggacao opened this issue Sep 16, 2021 · 10 comments
Closed

a single additional cache is not enough #545

blaggacao opened this issue Sep 16, 2021 · 10 comments

Comments

@blaggacao
Copy link
Contributor

In my scenario, I got:

  • nixos cache
  • company cache
  • project cache
@kamadorueda
Copy link
Contributor

Having many read caches and one write cache would be really awesome,

I think with current arch this would be very simple to implement

@blaggacao
Copy link
Contributor Author

blaggacao commented Sep 16, 2021

In addition, hard-coding it to cachix.org might not be very legit. But maybe that can be solved via #546 as well (read: nixConfig settings).

@blaggacao
Copy link
Contributor Author

blaggacao commented Sep 16, 2021

x-ref: input-output-hk@3cd7dc0

BTW, I absolutely love how all cache config is totally self-contained.

@kamadorueda
Copy link
Contributor

x-ref: input-output-hk/makes@3cd7dc0

Good news is that we will get to the point where you won't have to fork

I'll try to merge those features upstream so the entire ecosystem benefits from this feedback,
we are also needing this feature at Fluid Attacks

@kamadorueda kamadorueda added the help wanted Will be solved only if someone contributes it label Sep 16, 2021
@kamadorueda kamadorueda self-assigned this Sep 16, 2021
@kamadorueda kamadorueda removed the help wanted Will be solved only if someone contributes it label Sep 16, 2021
kamadorueda added a commit that referenced this issue Sep 17, 2021
- Enable using more read caches
@kamadorueda
Copy link
Contributor

@blaggacao your feedback would be very appreciated: https://github.com/fluidattacks/makes#cache

@kamadorueda kamadorueda removed their assignment Sep 17, 2021
@blaggacao
Copy link
Contributor Author

Ok, gotta schedule it for after lunch. ⌛

@dsalaza4
Copy link
Contributor

@kamadorueda

What do you think about making readExtra a map so we can name each cache, just for clarity.

    readExtra = {
      fluidattacks = {
        url = "https://example.com";
        pubKey = "example.example.org-1:123...";
      };
      fluidattacksBackup = {
        url = "https://example2.com";
        pubKey = "example2.example2.org-1:123...";
      };
      autonomicjump = {
        url = "https://example3.com";
        pubKey = "example3.example3.org-1:123...";
      };
    };

@dsalaza4
Copy link
Contributor

dsalaza4 commented Sep 21, 2021

@kamadorueda Also, is there a specific reason for not including all readAndWrite parameters within each cache declared in readExtra? that way we would only have:

cache = {
  fluidattacks = {...}
  fluidattacksBackup = {...}
  autonomicmind = {...}
}

Also, Is priority being considered here?

@kamadorueda
Copy link
Contributor

Also, Is priority being considered here?

caches priority is defined by the cache itself, for example: https://cache.nixos.org/nix-cache-info (40) and https://fluidattacks.cachix.org/nix-cache-info (41)

@kamadorueda
Copy link
Contributor

What do you think about making readExtra a map so we can name each cache, just for clarity.

That's nice, though we don't use that data so that's why I didn't include it, also, there are code comments if people feel the need of adding such information

Also, is there a specific reason for not including all readAndWrite parameters within each cache declared in readExtra? that way we would only have:

yes, the reason is that we only support read+write on cachix, whereas read caches can be anything from cachix, to hydra, to S3 buckets, anything over HTTP

the read protocol is standardizes, whereas the write protocol is not

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants