Alright folks that's a wrap, see you in two weeks!

fry dancing Next up is 🧑‍🏫Puppet Forge in 42 hours

allthethings 🧑‍🏫Puppet Forge is about to start up in 15 minutes

Hey folks, John Murray here, UX designer on Forge. Just shout if you have any questions

Sometimes I see modules with missing project url (no repo on github anymore e.g.).. it'd be nice to see some sign of it (and affect the score maybe if not yet)

Thanks @Yury Bushmelev if you have any examples, I can take a look into how we might handle that.

Let me try to find one..

E.g. this one - there is 404 when clicking the “project url” link

Perfect, thank you!

kermit typing Next up is 🧑‍🏫 Bolt in 121 hours

the more you know 🧑‍🏫 Bolt is about to start up in 15 minutes

Hiya friends! Bolt office hours are open 😄 shout If you have any questions about Bolt!

Hi @mcdonaldseanp. There was a discussion in the past to remove bolt-server from the repo. Do you know if this is still plannend? (I would love to see this in the bolt repo)

Yes we are still considering moving bolt-server out of the bolt repo. What use-case are you using the bolt-server implementation in the Bolt repo for?

Yes we are still considering moving bolt-server out of the bolt repo. What use-case are you using the bolt-server implementation in the Bolt repo for?

starting plans/tasks via an API. for example to integrate it into foreman

building bolt cli arguments feels a bit... wrong 😄

Ha, fair enough 😄 Part of the reason we are considering moving the bolt-server implementation out of Bolt is because the implementation of what bolt-server is and does could change as we grow and improve PE and Orchestrator's architecture, and removing it from the lifecycle of Bolt makes that an easier transition and means better features faster in PE and it means less headaches when building new features in Bolt that need to ensure compatibility for bolt-server's use in PE with every commit. If we do decide to move the implementation of bolt-server somewhere else we will be sure to announce that to users before doing so. For the use-case you're describing I don't see a reason why we couldn't keep around the code in the current bolt-server implementation in the Bolt repo and just have PE's bolt-server implementation start somewhere new. Though I'll note that we don't have the capacity to maintain two implementations, so the implementation in Bolt would need to be maintained by the community.

Ha, fair enough 😄 Part of the reason we are considering moving the bolt-server implementation out of Bolt is because the implementation of what bolt-server is and does could change as we grow and improve PE and Orchestrator's architecture, and removing it from the lifecycle of Bolt makes that an easier transition and means better features faster in PE and it means less headaches when building new features in Bolt that need to ensure compatibility for bolt-server with every commit. If we do decide to move the implementation of bolt-server somewhere else we will be sure to announce that to users before doing so. For the use-case you're describing I don't see a reason why we couldn't keep around the code in the current bolt-server implementation in the Bolt repo and just have PE's bolt-server implementation start somewhere new. Though I'll note that we don't have the capacity to maintain two implementations, so the implementation in Bolt would need to be maintained by the community.

Ha, fair enough 😄 Part of the reason we are considering moving the bolt-server implementation out of Bolt is because the implementation of what bolt-server is and does could change as we grow and improve PE and Orchestrator's architecture, and removing it from the lifecycle of Bolt makes that an easier transition and means better features faster in PE and it means less headaches when building new features in Bolt that need to ensure compatibility for bolt-server's use in PE with every commit. If we do decide to move the implementation of bolt-server somewhere else we will be sure to announce that to users before doing so. For the use-case you're describing I don't see a reason why we couldn't keep around the code in the current bolt-server implementation in the Bolt repo and just have PE's bolt-server implementation start somewhere new. Though I'll note that we don't have the capacity to maintain two implementations, so the implementation in Bolt would need to be maintained by the community.

I don't care in which repo the code is, as long as you keep it under apache-2 license, if that helps

I think it would be sad if the API got a PE-only license

I don't think we would have any reason to move the current API in bolt-server to a PE-only license, so if what exists today is working for your use-case then I don't believe anything the team has talked about would hinder your ability to keep using the already existing APIs. Really what I'm thinking about is medium and long term as the use-cases of Bolt in PE continue to mature we may want to completely change what bolt-server does or decide if there even is a bolt-server in PE at all vs. a new architecture that uses a different/new set of services.

I don't think we would have any reason to move the current API in bolt-server to a PE-only license, so if what exists today is working for your use-case then I don't believe anything the team has talked about would hinder your ability to keep using the already existing APIs. Really what I'm thinking about is medium and long term as the use-cases of Bolt in PE continue to mature we may want to completely change what bolt-server does or if there even is a bolt-server in PE at all vs. a new architecture that uses a different/new set of services.

I don't think we would have any reason to move the current API in bolt-server to a PE-only license, so if what exists today is working for your use-case then I don't believe anything the team has talked about would hinder your ability to keep using the already existing APIs. Really what I'm thinking about is medium and long term as the use-cases of Bolt in PE continue to mature we may want to completely change what bolt-server does or decide if there even is a bolt-server in PE at all vs. a new architecture that uses a different/new set of services.

And in those scenarios it may make more sense not to continue to have those changes in the bolt repo

And in those scenarios it may make more sense not to continue to have those changes in the bolt repo

Hi @mcdonaldseanp, in the bolt channel I have raised a question in regard to the use of OS environment variables with the PCP transport. At this moment I get a notimplemented error, is there a technical reason why this is not implemented in the PCP transport?

indeed _🦊Vox Pupuli monthly sync; see calendar event for info_ is about to start up in -15 minutes