Bug#819816: ITP: debops -- Ansible based server management utility
On Sat, 2 Apr 2016 20:06:47 +0200 Geert Stappers wrote: > Thank _you_ for bringing it to a wider audience. > > Groeten > Geert Stappers > -- > Leven en laten leven BTW, I've got some references here (only German, though): Ansible among other deployment systems (Puppet, Chef, Salt): Bößwetter/Johannsen/Steig: "Baukastensysteme - Konfigurationssysteme mit Open-Source-Software". In: iX 04/2016, S. 94-99 Ansible vs. Puppet in particular: Martin Loschwitz: "David gegen Goliath - Zwei Welten treffen aufeinander: Puppet und Ansible". In: Linux-Magazin 01/2016, S. 50-53 Debops: Hartmut Goebel: "Rollenfindung - Ansible-Playbooks für Debian-Systeme". In: iX 01/2016, S. 144 Oliver Frommel: "Operation geglückt - Server-Management mit Debops". In: IT-Administrator 04/2016, S. 60-62 DS -- 4096R/DF5182C8 http://www.danielstender.com/blog/
Bug#819816: ITP: debops -- Ansible based server management utility
On Apr 07, Daniel Stender wrote: > The upstream tarball actually is the result of debops-update, manually > stripped > and tar-ed with --exclude-vcs. That appears to be the only way to get also the > roles right now ... > I don't have a clue yet how to create a get-orig-source target. For packaging, > the most convenient way would be if the roles are included in the project > repo, > could that be possible somehow? Because Ansible will deprecate support for plain requirements files and switch to YAML-based requirements, debops-update is in need of an update to use the new format. There's currently no list of role repositories, but that could be added to the debops-playbooks package in some place. Would a plain URL-based list of git repositories be useful for this? I'm not sure if going with git submodules in debops-playbooks repository would be a good solution... This is currently done in the documentation repository and it's cumbersome to update (probably a bot account would be needed to make it easier). If a role is updated, debops-playbooks repository doesn't need to be changed unless that respective role playbook need to be changed. There were talks about going with https://github.com/ingydotnet/git-subrepo/ for this, but I haven't gotten to trying that out yet. Maciej
Bug#819816: ITP: debops -- Ansible based server management utility
On Thu, 7 Apr 2016 09:27:52 +0200 Maciej Delmanowski wrote: > On Apr 06, Daniel Stender wrote: > > I've worked towards this now and prepared two packages, debops containing > > the scripts [1] and another one, debops-playbooks [2] containing the > > playbooks and the roles. > > I was worried for a bit, but it looks like the debops-playbooks package works > fairly well... Do you get the 'master' branch of all of the roles, or do you > grab the last tagged commit? Some of the roles are not tagged yet. Thanks for appreciation. That way it runs out of the box, plus the user could run debops-update on individual projects to get the latest snapshot. Collecting deb/copyright was painful, but it's worth it ... The upstream tarball actually is the result of debops-update, manually stripped and tar-ed with --exclude-vcs. That appears to be the only way to get also the roles right now ... > The project is in a transition period at the moment where I clean up some of > the roles. How will the debops-playbooks be updated when a new role is added > or an existing role is updated? I don't have a clue yet how to create a get-orig-source target. For packaging, the most convenient way would be if the roles are included in the project repo, could that be possible somehow? > I've had an idea to do something similar to > https://wiki.debian.org/AutomaticPackagingTools and create a script that could > package Ansible Galaxy roles instead of bundling everything in one huge > package. Although apart from DebOps itself I'm not sure if other Galaxy users > are writing roles to work together, or separately. Thanks for pointer, I'll check that out ... So far everything works but needs only some more fine tuning but there might be other perspectives for packaging Ansible stuff generally. > I'm switching the project mailing list to a self-hosted one (on DebOps, > obviously), at https://lists.debops.org/ (mailing list address would be > . Can you change that in the package > description, or should I make the changes in the documentation first? Please go ahead. When it's in experimental, I'll add this and much more information to the package. > As for the documentation of various roles, there's a separate > http://docs.debops.org/ page generated by Sphinx, code can be found in > https://github.com/debops/docs/ repository. Perhaps a separate debops-docs > package could be made using that? Yes, sure, a separate docs package would be an option ... That could be done. > One more thing, some of DebOps roles require Ansible v2.0+, can you set the > required Ansible package version accordingly? Thx for pointer. On the to-do list. :-) Thx, Daniel -- 4096R/DF5182C8 http://www.danielstender.com/blog/
Bug#819816: ITP: debops -- Ansible based server management utility
On Apr 06, Daniel Stender wrote: > yes, I agree, the main advantage would be to have also the playbooks and > roles as a package. One more thing, some of DebOps roles require Ansible v2.0+, can you set the required Ansible package version accordingly? Maciej
Bug#819816: ITP: debops -- Ansible based server management utility
On Apr 06, Daniel Stender wrote: > I've worked towards this now and prepared two packages, debops containing > the scripts [1] and another one, debops-playbooks [2] containing the > playbooks and the roles. I was worried for a bit, but it looks like the debops-playbooks package works fairly well... Do you get the 'master' branch of all of the roles, or do you grab the last tagged commit? Some of the roles are not tagged yet. The project is in a transition period at the moment where I clean up some of the roles. How will the debops-playbooks be updated when a new role is added or an existing role is updated? I've had an idea to do something similar to https://wiki.debian.org/AutomaticPackagingTools and create a script that could package Ansible Galaxy roles instead of bundling everything in one huge package. Although apart from DebOps itself I'm not sure if other Galaxy users are writing roles to work together, or separately. I'm switching the project mailing list to a self-hosted one (on DebOps, obviously), at https://lists.debops.org/ (mailing list address would be . Can you change that in the package description, or should I make the changes in the documentation first? The various script templates are an issue for lintian... Not sure what to do about that. As for the documentation of various roles, there's a separate http://docs.debops.org/ page generated by Sphinx, code can be found in https://github.com/debops/docs/ repository. Perhaps a separate debops-docs package could be made using that? Maciej
Bug#819816: ITP: debops -- Ansible based server management utility
On Tue, 5 Apr 2016 13:39:43 +0200 Maciej Delmanowski wrote: > Having a .deb package per role (separate git repository) seems a little > overkill, and the number of roles would only grow over time. On the other > hand, preparing a 'debian/' directory for easier packaging of all of the roles > should be easily doable. The roles could alternatively be bundled some broad > categories which would reduce number of packages involved, however that might > be tricky when each role is tracked separately with its own version tags. > > Is there any precedence in Debian similar to this issue? ... I don't know if there could be solution for the docs, though. Any suggestion very much welcome! DS -- 4096R/DF5182C8 http://www.danielstender.com/blog/
Bug#819816: ITP: debops -- Ansible based server management utility
On 05.04.2016 13:39, Maciej Delmanowski wrote: > Hello, > > The base repository contains just scripts which are a frontend and glue > between Ansible and playbooks/roles. Any ideas how the rest of the project, > meaning the playbooks and roles themselves, should be handled, if at all, in > Debian? > > Having a .deb package per role (separate git repository) seems a little > overkill, and the number of roles would only grow over time. On the other > hand, preparing a 'debian/' directory for easier packaging of all of the roles > should be easily doable. The roles could alternatively be bundled some broad > categories which would reduce number of packages involved, however that might > be tricky when each role is tracked separately with its own version tags. > > Is there any precedence in Debian similar to this issue? > > Thanks, > Maciej Hi Maciej, yes, I agree, the main advantage would be to have also the playbooks and roles as a package. I've worked towards this now and prepared two packages, debops containing the scripts [1] and another one, debops-playbooks [2] containing the playbooks and the roles. This combination runs (/etc/debops.cfg point to /usr/share/ for the playbooks and roles) out of the box, but it's going into experimental first because it needs some more fine tuning [3]. However, the debops-playbooks package needs more work, too. Yes, the collected invidivual repos in roles/ are problematic, I've put unwanted things like the individual LICENSEs into the Files-Excluded list in deb/copyright to please the Lintian complaints on these to begin with. Cheers, DS [1] https://github.com/debops/debops [2] https://github.com/debops/debops-playbooks [3] like fixing the error on "could not create retry file '/usr/share/debops-playbooks/playbooks/site.retry'" among other things like that -- 4096R/DF5182C8 http://www.danielstender.com/blog/
Bug#819816: ITP: debops -- Ansible based server management utility
Hello, The base repository contains just scripts which are a frontend and glue between Ansible and playbooks/roles. Any ideas how the rest of the project, meaning the playbooks and roles themselves, should be handled, if at all, in Debian? Having a .deb package per role (separate git repository) seems a little overkill, and the number of roles would only grow over time. On the other hand, preparing a 'debian/' directory for easier packaging of all of the roles should be easily doable. The roles could alternatively be bundled some broad categories which would reduce number of packages involved, however that might be tricky when each role is tracked separately with its own version tags. Is there any precedence in Debian similar to this issue? Thanks, Maciej
Bug#819816: ITP: debops -- Ansible based server management utility
On Sat, Apr 02, 2016 at 07:55:41PM +0200, Daniel Stender wrote: > Package: wnpp > Severity: wishlist > > * Package name: debops > Version : 0.4.3 > Upstream Author : DebOps Project > * URL : https://github.com/debops/debops > > The binary package is going to be of the same name. > > Thanks, Thank _you_ for bringing it to a wider audience. Groeten Geert Stappers -- Leven en laten leven
Bug#819816: ITP: debops -- Ansible based server management utility
Package: wnpp Severity: wishlist Owner: Daniel Stender * Package name: debops Version : 0.4.3 Upstream Author : DebOps Project * URL : https://github.com/debops/debops * License : GPL-3 Programming Lang: Python Description : Ansible based data center management utility This is a server configuration manager written in Python [1] which is based on a collection of Ansible playbooks [2]. It's especially for the configuration of Debian/Ubuntu servers and features several refined playbooks to set up a multitude of different features on them from a distance. The binary package is going to be of the same name. Thanks, DS [1] http://debops.org/ [2] https://en.wikipedia.org/wiki/Ansible_(software)
