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

RFC: Client/Server Configuration #4

Closed
geaaru opened this issue Nov 12, 2019 · 6 comments
Closed

RFC: Client/Server Configuration #4

geaaru opened this issue Nov 12, 2019 · 6 comments

Comments

@geaaru
Copy link
Contributor

geaaru commented Nov 12, 2019

Integrate support of Viper/Cobra configuration for both client and build packages commands.

Format supported is YAML (or viper supported format):

Example of a configuration for the client:

logging:
   path: /var/log/luet/luet.log
   level: "info"

general:
   concurrency: 4
   # debug: false

# Environment options are usable
proxy:
    http: xxx
    https: xxxx
    ftp: xxx

cache_repositories:
    -  name: "Local cache node2"
       priority: 3
       mode: "ro"
       urls:
          -  https://mynode2.local/
       type: "http"
       # auth:

    -  name: "Local cache node1"
       priority: 2
       mode: "rw"
       urls:
          -  https://mynode1.local/
       type: "http"
       # auth:
   -  name: "Local dir"
      type: "dir"
      mode: rw
      priority: 1
      path: "/var/cache/luet/"

# Repositories where fetch tree and packages could be defined in the main
# configuration file or under a specific directory.
system_repositories:
    - name: "repo1"
      descr: "Repository 1"
      type: "disk"
      # Optional URL where retrieve API Repository server (that uses same auth credentials)
      api: "https://myrepo.server.org/repo1"
      path: "/mypath/repo1"
      priority: 1
   -  name: "repo2"
      descr: "Repository 2"
      type: "http"
      urls:
         -  "https://myrepo.org/repo2"
         -  "https://mirror.myrepo.org/repo2"
      priority: 2
      auth:
          # Token key (for example Mottainai Api key)
          token: "xxxxxxx"
          # Basic authentication
          #  username: "user"
          # password: "pwd"

List of repositories could be defined under the directory /etc/luet/repositories.d/ in yaml:
Example of repo1:

# cat /etc/luet/repositories.d/repo1.yaml

name: "repo1"
descr: "Repository 1"
type: "disk"
path: "/mypath/repo1"
# type: "http"
# urls:
#   - "https://myrepo/repo1"
priority: 1
enable: true
auth:
   # Token key (for example Mottainai Api key)
   token: "xxxxxxx"
   # Basic authentication
   #  username: "user"
   # password: "pwd"
@mudler
Copy link
Owner

mudler commented Dec 8, 2019

Integrate support of Viper/Cobra configuration for both client and build packages commands.

Format supported is YAML (or viper supported format):

Example of a configuration for the client:

logging:
   path: /var/log/luet/luet.log
   level: "info"

general:
   concurrency: 4
   # debug: false

# Environment options are usable
proxy:
    http: xxx
    https: xxxx
    ftp: xxx

cache_repositories:

We should be consistent, and choose between underscore or dashes for naming (cache_repositories vs system-repositories). But my question is also, should we allow to define the cache per-repo for the user? or compute automatically the paths based on a root path (which is defined by the user?)

@geaaru
Copy link
Contributor Author

geaaru commented Dec 8, 2019

The cache_repositories is intended like an L2 Cache where luet could retrieve packages/layers before use mirrors. I'm not sure that /var/cache/luet/repos is right here because could be the default path where fetch packages.

The idea is to use for example a directory where retrieve/store fetched files:

$# ls /var/cache/luet/repos/
repo1/pkg1.tar
repo2/pkg2.tar
...

Or in a LAN fetch packages from a node used as local cache mirrors that is integrated in this way:

  1. Run: luet install pkg1
  2. luet try to see if pkg1 is already present in local cache
  3. if not present try to check if pkg is present on cached_repository with high priority
  4. if pkg is not present try to fetch the package from URL defined inside repository object
  5. if cached_repository has rw mode then try to push the package to cached_repos
  6. luet install fetched package.

The cached repository could be a feature of API Server instances.

geaaru pushed a commit that referenced this issue Dec 29, 2019
@geaaru
Copy link
Contributor Author

geaaru commented Dec 30, 2019

It seems that viper has an issue on parse structure from configuration files with field with an underscore (probably for the env key replacer):

$ ./luet config
 Using config file: /home/geaaru/go/src/github.com/mudler/luet/.luet.yaml
💣   [failed to load configuration: 1 error(s) decoding:

* 'cache_repositories[0]' expected a map, got 'string']🔥 
$ cat .luet.yaml
system_repositories:
   - name: "xxx"

I will rename system_repositories in repositories and cache_repositories in repetitors.

@geaaru
Copy link
Contributor Author

geaaru commented Dec 31, 2019

This implement repositories integration b8f7122

geaaru pushed a commit that referenced this issue Dec 31, 2019
mudler pushed a commit that referenced this issue Dec 31, 2019
geaaru pushed a commit that referenced this issue Jan 1, 2020
mudler pushed a commit that referenced this issue Jan 1, 2020
@geaaru
Copy link
Contributor Author

geaaru commented Jan 3, 2020

Just to trace the implemented configuration file: https://github.com/mudler/luet/blob/develop/contrib/config/luet.yaml

@geaaru
Copy link
Contributor Author

geaaru commented Jan 3, 2020

repetitors integration will be defined by a specific issue.

@geaaru geaaru closed this as completed Jan 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

2 participants