https://www.puppet.com/community logo
Join Slack
Powered by
This message was deleted.
# puppet
s
This message was deleted.
b
I still have a few customers that use the f5 module and I think that requires device_manager
thankyou 1
d
If device manager was dropped from being a supported module do you think that would be problematic for them or is it just stuff that keeps working since i'm looing at the F5 module not being updated since 2019?
b
every customer I know has a fork of f5 because Puppet and F5 stopped developing the module
in case puppet_manager works with Puppet 8 people are happy, I don't think they need active support
d
interesting
b
(we mentioned this a few times to sales that there's potential interest in a new f5 module or an update to it, but sales said Puppet wont continue working on it, same did f5)
f5 doesn't even know they once payed for the module development
😂 1
y
I think as long as there is a way to do the same via scheduled orchestartor task in PE nobody cares much
(though I don’t have real customers so just guessing)
b
people care a lot because rewriting the whole code is a pain. especially the f5/device stuff
d
thats what I was concerned about
if anyone does have a commit change is a pain
from our point of view as a supported module it probably doesn't make sense
but how to make sure maintenance and development don't fall short of whats needed
b
what is the state of ACE? David Schmitt said back in the days that ACE is the successor of 
puppet device
but it seems to lack documentation/migration path
y
you may donate some money to voxpupuli to support it 😄
d
ACE is certainly part of PE
I will follow that lead and ask
b
the problem with f5 is that you need their appliances to properly develop the module. And I hate f5. No sane person should buy this overpriced piece of shitty software. But strangely management doesnt like to hear from me 'you bought crap for 150k, use haproxy instead'
😞 1
lol 1
d
it may be theres a middle ground where ACE is maintained for orchestrater anyway so it wouldn't be too much work to use it instead of device-manager
b
I'm happy to migrate existing f5 setups to haproxy, but I really don't want to keep working on f5 😄
I cannot imagine a single FOSS user for puppet device.
y
I feel the same about f5.. the only good part of having it is you can throw your tasks over the wall to the networking guys who is in charge to deal with it 🙂
but 2x Linux servers can outperform it in any way
but.. you’ll be responsible in this case 🙂
b
I take that as a pro argument for linux routers 😄
d
the pay to blame a vendor game never really works 😂 or certainly i never got any less blame when I was on the other side 🙂
☝🏻 1
on the F5 point @bastelfreak do you think there would be anyway to create a community module / sensible alternative already out there because I hate having a unmaintained partner one
b
unless f5 sponsors their (virtual) appliance, I don't think so
d
I mean even in terms of us approaching F5 and saying do you want to hand this module over ? Or is it really only good for maintain a set of legacy F5 devices
b
I think it works with their current devices but doesn't support their full API, but enough to use it
from a Vox Pupuli perspective I don't want to maintain a module I cannot test
d
i 100% get that
b
and I don't want to maintain a module for free that PE makes revenue with
/me looks at metadata-json-lint and all the puppet-lint plugins shipped in CD4PE but are owned by Vox Pupuli
ideally we just archive device_manager/ and f5 and people will switch to haproxy, but that won't happen. People will keep using the module because the f5 appliance was damn expensive and is usually deeply integrated into the network
and even if someone starts maintaing it again, the customers usually have forks and I'm not sure how likely it is that they will use an official module again
so the whole situation is tricky 😞
d
ok let me find out about ACE
and I'll have a think
oh also CISCO does anyone use that with device manager
b
yeah. If ACE can be a dropin replacement we could at least get rid of of device manager
s
@David Sandilands I'm just seeing this thread. We use device manager because it is convenient to manage Puppet device runs. the Puppet Primary server does not (and likely never will) have the direct access it needs to connect to the devices. We do device runs on basically a "proxy" agent node. Also, some of our device runs are very run/memory heavy, I'd just as soon not put that on the primary with all the other things it does.
b
which devices do you manage? F5/cisco, something homegrown?
s
homegrown. Satellite/Spacewalk servers, mostly.
b
ah nice
d
interesting
s
as a managed service provider, the ability to proxy that type of connectivity is pretty critical. having one key management node that has the ability to directly SSH/API/WinRM/whatever into every system in every customer bubble isn't easy to do. the agent-as-a-proxy concept makes it doable for device runs.
d
Have you ever looked at bolt? Or is there just no need with device-manager as it is
s
for device runs? no need. device-manager provides a small wrapper that makes it very easy to schedule and run the device modes and it just works
and, more or less "puppet device" runs basically like a one-shot "puppet agent" mode, which meshes well with the rest of things
and when I say some of these are run-heavy like... hour-plus long runs. Satellite is not fast.
not sure how Bolt handles such long runs
b
We've an 11h long running patch plan. that works
s
oh, good to know. and wow. lol
Open in Slack
PreviousNext
Powered by