This message was deleted.
# office-hours
s
This message was deleted.
j
yeah, we spent some time looking at that... but
ensure => latest
is ambiguous in this context
it's not possible to differentiate between wanting to upgrade to the latest version versus installing a version whose value is the literal string "latest".
p
I'm not sure module streams have a concept of
latest
I will note it is blocking deployment of a bunch of GPU nodes via puppet
p
Module streams explicitly don't promise an upgrade path from version "A" to version "B"
"we cannot # programatically determine a latest version for ensure => 'latest'" I'd say trying to determine which one is
latest
would be a misuse of the modularity interface
j
If I'm understanding what you're saying, I think that's the mismatch. Puppet assumes
ensure => latest
means something very specific. The provider must be able to determine what the latest available version is and if the package is not insync? then the provider must have the "upgradeable" feature and be able to update to the latest version
p
I think we're on the same page. If a more interactive chat would be helpful I'd be happy to join one. While I'm not the foremost authority on modularity, I've got some code in it. Gallagher wrote the spec, but he can be hard to pin down
c
Just saw this. Yes. The package management platform is what is being sourced with the “latest” value. Professional services had us tell customers to use a patch system (like Spacewalk or Satellite, for instance), and to use channel releases to update to latest on some products. When the new version became available, the package manager would resolve that the currently installed package had a delta between itself and what was available, and “latest” would then be invoked. You are correct that you cannot necessarily know programmatically what that is (you could actually do the work, but it would take some serious programmatical “standing on your head”, but why do that when the provider has the plumbing to do it already?
p
It is a tricky situation, I'm mostly just caught between the grid folks who say "If we can't manage nvidia with puppet, then switch to something else" and my infrastructure that is (nearly) all puppet
c
you can barely manage nvidia with YUM LOLOL
I’d end-around the whole thing. Make yourself a yum (or apt) repo, make a new repofile, and write a script that checks releases, dropping them into the repo and running the repo update/refresh command automagically. Then, when Puppet runs, it’ll get what they want it to get, and it will be invisible to them.
“I made a shiny new just-for-you Yum/Apt repo that does exactly what you want”™