debops / ansible-apt

Configure and manage APT Package Manager
GNU General Public License v3.0
10 stars 15 forks source link

Update and Dist Upgrade Only #37

Open devekko opened 9 years ago

devekko commented 9 years ago

I've been trying to get Proxmox updated and upgraded using Debops host inventory only and am having problems

is it possible to use this role so it only updates and upgrades without managing the packages installed ?

I started adding packages and repositories using inventory but got issues with versions and that would lead to pinning and I end up with an elaborate Proxmox role

https://github.com/dpausp/ansible-playbook-pve/blob/master/proxmox.yml

all I want to do is include an update and upgrade in a proxmox inventory along with some other inventory variables


I wanted to do the same thing with tools like Discourse and Cloudera etc but am wondering if I need a custom role/playbook

if I do need a custom role/playbook for just update and dist-upgrade, how do I tie that into debops so it runs as part of a regular command?

I know, a few questions

drybjed commented 9 years ago

I plan to split debops.apt role at some point to allow management of package sources separately from package installation. Upgrade tools (unattended-upgrades, apticron, etc.) will probably be put in a separate role as well. That way you will be able to pick just what you want in your playbook (all will be part of common.yml in DebOps).

I'm not sure if DebOps environment would be compatible at this point with Proxmox per se... If it's OpenVZ you want, and not specifically Proxmox UI, you can use debops.openvz role to setup Wheezy host with OpenVZ support, it works pretty nicely.

As for issues with package versions, this is a problem with Debian itself, not DebOps. I haven't played with Proxmox, so I'm not sure, but if they provide Wheezy repositories it probably should be compatible with Wheezy. DebOps installs several packages from wheezy-backports repository, I'm not sure how Proxmox would behave with these. Can you provide a list of packages that generated conflicts, or error messages during installation?

As an aside, if you use Debian Stable / Oldstable as a base OS, you should get all packages already "current", ie. apt-get dist-upgrade as a part of normal installation process shouldn't be needed. Many Ansible roles include lines like this for no reason other than the assumption that hosts are managed by this one role only. And then, when you use DebOps with them, which handles package upgrades for you, you get into issues. In other words, I think that issue here is not "how to do dist-upgrade" but "how to install Proxmox on DebOps-managed host".

The role that you linked is old, I would probably try and write a new one from scratch, leaving stuff like "dist-upgrade all the system" out of it. You could start by preparing a host with just common.yml and then installing Proxmox on it, taking into account all the steps you need. And don't reboot host automatically, that will only lead to problems. Notify an admin via mail instead, that this host requires a reboot to finish configuration. You can see in debops.openvz or debops.lxc how it's handled.

devekko commented 9 years ago

thanks

its actually a general question

I want to use Debops to manage an application network - using a bunch of complex applications - and from what you describe the debops.apt role is not suitable right now

thats fine, I can work around it, and use a simple update and upgrade playbook using ansible core

will post more soon

devekko commented 9 years ago

before I forget, I need to work out what I need to turn off on debops for complex apps...

it maybe all I want is ferm & auth, maybe I do that in inventory

another kludge would be to have a non debops only inventory ...

I'd rather work out what to turn off, so that complex applications like Proxmox, Discourse, Cloudera are not effected, and only basic stuff like auth and ferm are managed by Debops

drybjed commented 9 years ago

Well, the way to do it is, you either use common.yml playbook and add your own changes as needed, or you write your own common play and pick the roles from DebOps as you see fit. From the looks of it, I would try the 2nd way to see if that's you want.

drybjed commented 9 years ago

@devekko Also, you might want to come over to #debops channel on IRC, there are more people with different use cases there, you certainly could get some good feedback. :)

devekko commented 9 years ago

couldnt I just have in host inventory?

pki:False apt:False etc etc..

drybjed commented 9 years ago

Of course, but then you might have ~100-200 skipped tasks each time you run common.yml. Your choice. :-)

devekko commented 9 years ago

sure, but I do intend to build out infrastructure using debops services..

just want to mix it with some non Debops complex apps

will investigate further

drybjed commented 8 years ago

@devekko It took longer than I thought but finally debops.apt manages only the repository configuration, other stuff has been moved to separate roles. Could you check if this issue still stands for you?

niccolox commented 7 years ago

will test this in coming weeks

these latest security breach revelations make me want to shift all my systems over to a debops foundation and I am hoping this might be key

THANKS