Feature Request: Configuration file (.aptly.conf) should also be able to configure individual repositories

[papamoose]

Currently the .aptly.conf file is used to specify defaults so when you use the 'aptly' command you don't have to always specify certain options.

I believe this functionality should be extended so that one can create mirrors just by editing the configuration file. I believe this would be mean that 'aptly' would have to become a service that would need to reload the config file whenever it is changed.

I imagine new parts of the config file would look something like this:

{
  "rootDir": "$HOME/.aptly", # if not specified use default
  "url": 'http://archive.ubuntu.com/ubuntu',
  "source": true,
  "name": 'myubuntumirror',
}

Obviously, one would need to add all the options associated with creating a repo.

I could also imagine that each mirror would not have to exist in the default .aptly.conf file. One could use the concept of the '.d' directory (aptly.conf.d). Where every mirror would be its own file and the service would probably just do the equivalent of cat /etc/aptly/aptly.conf.d/* > tmp to combine them.

My reason for suggesting this method of managing mirrors/repositories is because it is more easily managed by configuration management tools like puppet, chef, salt, ansible, etc. Most of the operations in $config_man_tool come down to placing a file and reloading some service. The currently method involves a bunch of 'exec's, as seen in this well written puppet module: https://github.com/gds-operations/puppet-aptly/tree/master/manifests. Exec statements are bad because they bypass (in this case) puppet, they are not guaranteed to be idempotent, and you lose the ability to track any changes without doing some work yourself.

With a configuration file the configuration management tool can track all changes made to a system very easily (think version control) and make sure that all mirror files are up to date with a simple checksum, which guarantees idempotency.

Doing any work on the command line now becomes a problem because it is state that is not tracked by a configuration file managed by $config_man_tool. I would say this isn't too much of an issue as long as the admin knows the risks. The work done would still be stored in the aptly database, one would have to make sure that this data is not cleared (read: make a decision about data persistence) when new config files are loaded.

[smira]

@papamoose I got your point, and I agree that having configuration as files is better for configuration management systems.

Currently aptly does some checks when calling aptly mirror create (and other similar commands), also internally database references objects (e.g. snapshots reference source mirrors) and so on. This can't be replicated with configuration file creation.

Many operations require action (e.g. publishing, creating snapshots, updating mirrors and so on), so you need to exec aptly anyway.

I would like to think more about that and come up with solution. One option: adding command to "export" configuration as files and "import" configuration from files (creating/removing/editing when necessary), this could be seen as a bridge between internal DB, consistent state and having configuration easily inspectable and adjustable by puppet.

[papamoose]

@smira

One option: adding command to "export" configuration as files and "import" configuration from files

This feature alone would be fantastic!

[fewaffles]

In an environment with multiple project users, none of which are system administrators, it would be nice to have an aptly.conf file at the top level of the repository. That way all maintainers of the mirrors/snapshots/repos will be using a common configuration, but no one needs to bother the system administrator to update the file under /etc.

[rtennill]

I think the ability to update or create a new aptly object (repo, mirror, publish) by importing a configuration file would be extremely useful. Aptly command lines can get quite long when specifying multiple options and especially with package filters....

Including the filter in the config would also address #157!