> "Updating all server lists for every yum command was very annoying."
This isn't the case. It updates information when the cache expires, so this will only happen about every 30 minutes or slow. It should also only take (usually) way less than a minute.
> BTW ansible sucks for this aspect
Yep, it's not meant to understand how to remove resources it doesn't know about. That being said, it feels like I've created PHP at times, and I don't mind people not liking it. Many of the ways we have to automate Linux systems (due to lack of structure and API) are kludgy at times, but removal of packages not present in a master manifest seems dangerous to me for various reasons (group installs, tools self-bootstrapping, work happening out of band). Fair enough.
> is not the only valid way to do things
This was not the argument for immutable systems (though I like them), but rather that you need a good disaster recovery strategy and this is likely the best way to handle a major distribution version upgrade.
Minor versions? Continue to do what you do. Major upgrades between EL versions are full of all sorts of fun.
I've typically seem them done with upgrade kickstarts and the like, and you don't get good error reporting there at all when things go wrong. There were some advances in pre-downloading and then doing upgrades but... yeah... not a fan of doing them in automated context.
> " I can confidently say "
Trying to drive it programatically, yum seems much better engineered to me than apt. One example recently (and maybe there's a way in apt to do this) was to be able to select just one repo to use during an update to grab packages from, and I was missing --disablerepo=* --enablerepo=X. But there are a lot of things like that. Config files also seem a lot more capable. My opinion there too of course.
> This isn't the case. It updates information when the cache expires, so this will only happen about every 30 minutes or slow.
It doesn't do full downloads of files, but (as of RHEL5) it still makes HEAD requests or something, re-processes package lists (I guess apt does this too), I dunno. "-C" makes a significant difference. I want it to take less than a second to make a decision or spit out information; other package managers can do that.
EDIT: also want to say, I appreciate ansible overall, and I appreciate your attitude towards it. I've been close to a project that was good for a couple of uses, got kinda popular, and then people wanted it to be good for all purposes...
This isn't the case. It updates information when the cache expires, so this will only happen about every 30 minutes or slow. It should also only take (usually) way less than a minute.
> BTW ansible sucks for this aspect
Yep, it's not meant to understand how to remove resources it doesn't know about. That being said, it feels like I've created PHP at times, and I don't mind people not liking it. Many of the ways we have to automate Linux systems (due to lack of structure and API) are kludgy at times, but removal of packages not present in a master manifest seems dangerous to me for various reasons (group installs, tools self-bootstrapping, work happening out of band). Fair enough.
> is not the only valid way to do things
This was not the argument for immutable systems (though I like them), but rather that you need a good disaster recovery strategy and this is likely the best way to handle a major distribution version upgrade.
Minor versions? Continue to do what you do. Major upgrades between EL versions are full of all sorts of fun.
I've typically seem them done with upgrade kickstarts and the like, and you don't get good error reporting there at all when things go wrong. There were some advances in pre-downloading and then doing upgrades but... yeah... not a fan of doing them in automated context.
> " I can confidently say "
Trying to drive it programatically, yum seems much better engineered to me than apt. One example recently (and maybe there's a way in apt to do this) was to be able to select just one repo to use during an update to grab packages from, and I was missing --disablerepo=* --enablerepo=X. But there are a lot of things like that. Config files also seem a lot more capable. My opinion there too of course.