I am going to sound like an annoying product manager here... asking the 'WHY' questions 😄 Having it be 'yum' or 'apt' or browsable http/https/rsync are solutions. What they don't tell me is the 'WHY". What problem is happening? Why is this a more annoying approach than the repos? (And also, isn't Bolt still available through the repos too? I thought the deliver.perforce.com was just another way to get it)

repos haven't been updated since Perforce closed the source in 2025. apt.puppet.com

right there is a reason why: we can see what is available if it is browsable

Okay, so the need is to be able to browse and see what is available, like we had on the old apt.puppet.com, but the new apt-puppetcore.puppet.com is not providing that browsing capability, right?

Right now, I think there is a browseable HTML endpoint is here: apt-puppetcore.puppet.com/public/index.html , but it also doesn't have the new stuff.

and you don't offer rsync, so it's hard to setup internal mirrors

big companies run CI pipelines and those pipelines shouldn't rely on an internet connection nor on any authentication

> and you don't offer rsync, so it's hard to setup internal mirrors Exactly that. We heavily rely on mirrors for all sorts of repositories and sources throughout the entire company. > Right now, I think there is a browseable HTML endpoint is here: apt-puppetcore.puppet.com/public/index.html , but it also doesn't have the new stuff. True, but this only exists for the public repo. For the auth barred repo I can't even get an index. To all this I can basically respond with… "WHY" Why did Perforce choose to construct such a monstrosity. The company should know their customers and should know that very well established processes exist that when taken away cause a lot of friction for everyone. I guess if you release software only 4 times a year one can think "Sure, just create a download site and have humans log in to download the latest release which they then can distribute however they please" but yeah To me this feels like generalists who are resistant to critical feedback from inside and outside the org chose this path either not knowing why or simply not caring (but l'll give Perforce the benefit of the doubt for now).

just a quick question, is there some way to do pattern matching for targets to assign defaults? I have a dynamic targets, that are ad-hoc brokered the one thing they have in common is just a "naming convention" in the url

Hi @Lawrence Kok. I'm not aware of any for static targets in inventory. Though some dynamic inventory plugins has mapping support. So I'd say it depends. Also you can implement your own dynamic inventory plugin for this case. It's easy as a creating a task in any language actually.

FYI, most of community (and openbolt development) is in voxpupuli slack these days.

Hi, we have a server where all our bolt modules and scripts resides. When i want to run a command on that server with the $targetname as parameter is that possible, It is for setting downtime in icinga during a reboot. So the question is: How do i run al local command in a plan. And how do i use parameters like $target as a parameter to that command?

I'd recommend to read the documentation :) it's just a few pages, really

You want run_command() function. Your target is one of the plan parameters

Though, if that's about PE and orchestrator, then I have no idea, never used that

@Yury Bushmelev I saw dynamic inventory plugins, but I guess the problem with that is that puppet bolt wants to have a finite set of targets so it can do pattern matches against that group e.g. run command -t *web etc. But i don't really have a point where i can query for all targets, but i just want to do some normal stuff like, if your hostname has a certain pattern the sudo password is this.

You can call a plan to discover your nodes and run another plan with matching subset

Also, it's possible to pass one plan results to another bolt invocation with some trickery and jq command :)

yeah but that implies everything would have to be written as formal plans, so you loose the abillity to quick one of commands. In my case my nodes have empheral id's, so i activate ssh manually and then have something like <uuid>-suffix for ssh, so i can do bolt command 'hostnamectl' -t and then list the empheral-ids.

You should be able to get those via your cloud API I guess. But maybe you should consider either puppetdb queries or go choria.io instead

I have some ideas here, but I'll work on that in openbolt (as perforce's bolt is closed source effectively)

yeah that's fair enough, i didn't even know that openbolt existed yet, I made a bug fix for bolt (windows) yesterday i'll see if i can forward it to openbolt later w.r.t. my problem: I'm working with constrained edge devices, so we don't really have a run of the mill traditional "cloud stack".

fixes are welcome to openbolt 🙏🏻 🙂

I’d recommend you to at least evaluate choria then. It’s quire suitable for embedded devices orchestration/management.

just in case, this is what I’m using sometimes:

bolt plan run control_repo::find filter='$t.vars["pp_environment"] == "prod1"' --format=json | jq -r '.[]' | bolt command run -t- 'apt update'

control_repo::find

plan does some magic to return list of nodes, suitable to transfer to another plan as targets on stdin.

jq

is required to convert json to plain text list.

Where do you search the nodes, in openvoxdb? Or choria?

@bastelfreak i dont search for the nodes, just have a simple pattern in the hostname and when it matches the pattern we'll do some plumbing under the water to make ephemeral ssh connection- but yeah it's just silly to collect a (dynamic) list of devices/inventory where all devices are in non-connected state just to associate the right passwords.

@Lawrence Kok: You mentioned using edge devices, just wondering if you'd explored any of the new EdgeOps module stuff with your solution? I know that not everybody has it, just wondering if you might have had feedback around it.

no i havent