Date   
pdk 0.2.0

David Schmitt
 

Hi folks,

We fixed the system binary fallback, and added a few more commands, so we wanted to refresh what's available on rubygems. This is still a development snapshot with a couple of rough edges, but these commands do work:

  • pdk new module
  • pdk new class
  • pdk validate puppet
  • pdk validate ruby

See the CHANGELOG for details.

The pdk-module-template has also been updated to support those features.

If you need a ruby for your platform to run this, we also have a preview of the native packages we will be providing: https://drive.google.com/open?id=0Bz0tCHSb1u41alR4MmZfRHBTV1k Please note that you need to upgrade the pdk gem in those packages!


As always, I'd love to hear your feedback on this, either here, or in private.

Cheers, David

Re: Puppet SDK (pre-)announcement

David Schmitt
 

And I finally uploaded the current master to rubygems. Initially I expected folks around here to just run it from a clone, obviously I've been wrong.

Next step: automate the rubygems upload :-D

Cheers, David

On 1 June 2017 at 23:59, Bryan Jen <bryan.jen@...> wrote:
Hi folks,

One missing step from David's original email. If you are running pdk via the cloned git repo, you also will need to set an additional environment variable: PDK_USE_SYSTEM_BINARIES=true and ensure you have the appropriate binaries, like git, installed and in your path.

Thanks,
Bryan

On Thu, Jun 1, 2017 at 10:34 AM, David Schmitt <david.schmitt@...> wrote:
Hi folks,

in the spirit of release early, release often, we've just opened up the repositories for the pdk to the public: https://github.com/puppetlabs/pdk

The README there details some of what is planned for the next weeks, the implementation currently only has the "new module" command implemented. "new class" is currently in progress. The other commands will follow as the project progresses.

The second part of this are the templates at https://github.com/puppetlabs/pdk-module-template. Again, they are in a very early stage of development, but the long-term goal is to act as a one-stop-shop for all module related templating needs. Specifically, as a first step, replace our own modulesync_configs, and - if at all possible - the voxpupuli's one too. The format of the templates is intentionally based on modulesync, and should be bi-directionally usable for the time being.


Since we're just ramping up all the infrastructure around this project, the only sensible way to run the pdk currently is through bundler with a reference to the cloned Gemfile:

BUNDLE_GEMFILE=~/git/pdk/Gemfile bundle exec pdk help





I'd love to hear all your feedback, either here, or in private!


Cheers, David






--
Bryan Jen
Senior Software Engineer

Save the date:
PuppetConf 2017, 10-12 October
San Francisco, California

Re: Puppet SDK (pre-)announcement

David Schmitt
 



On 2 Jun 2017 22:45, "Rob Nelson" <rnelson0@...> wrote:
David,

Thanks for the preview! I've only had time to review it on the surface, but one question about rubocop. I know the SDK will be opinionated, but do you envision the ability to use the SDK without rubocop? While VP uses it heavily, I don't use it in my modules and we don't use it at work because the pre-1.0.0 nature of it leads to a lot of breakage at the absolute worst times. VP *does* pin it to reduce those impacts, at least, whereas the SDK right now is not pinned or bound at all.

The goal is to provide a coherent, tested set of tools, based on top of the templates. That of course includes a matching rubocop config and version. There are also provisions to run tools one-by-one. 

Please don't call it opinionated. With Bryan Jen, James Stocks, Jean Bond, Jesse Scott, Tim Sharpe, and myself, we've got a bunch of people working on improving the story across the board. For the pdk the goal is to capture the essence of module development workflow to provide the best experience possible, both to newcomers and experts.

Cheers, David 


Rob Nelson
rnelson0@...


Re: Group register: Vox Pupuli

 

Hi everybody,

Vox Pupuli is now a registered freenode group. This means that we can
handle out cloaks to everybody who wants one. The current group contacts
are our PMC members:

Hunner
dhoppe
nibalizer
fraq
bastelfreak

If anybody of you is interested in getting a cloak, just get in touch
with us. We can forward your request to the freenode staff people.

Cheers, Tim


-------- Forwarded Message --------
Subject: Re: Group register: Vox Pupuli
Date: Sat, 03 Jun 2017 18:23:53 +0200
From: fuchs@... <fuchs@...>
Reply-To: fuchs@...
Organization: freenode
To: Tim <@bastelfreak>
CC: projects@...

Hi Tim,
thanks for your interest in registering as a project on freenode and the
verification we did on IRC / GitHub.
You are now registered as a freenode group, voxpupuli. This means:
1) The group contacts can now, on IRC, request cloaks from any member of
staff (check /stats p or in #freenode for active staffers). Recipients
need a valid nickserv account
Cloaks have the format voxpupuli/optional/mandatory while most
projects do role/name, e.g. voxpupuli/pmc/bastelfreak (name does
not have to match your freenode name) Cloaks have a lenght limit
(unlikely to be hit) and only valid DNS characters are allowed, e.g. no
underscores. Users usually can only have one cloak at a time, so any
existing cloak would be overwritten (we ask for confirmation on these,
except when the current one is unaffiliated)

2) the group contacts can now, on IRC, request channels in the
#voxpupuli-* namespace if needed (apparently you already have all you
need, that would just be if e.g. someone unrelated grabs
#voxpupuli-puppies and you'd like to reclaim that)
Changes to GCs need to be done via e-mail, to groups@... (by an
existing GC)
If you have any remaining questions, feel free to poke any member of staff.
Kind regards,
Christian (Fuchs on freenode)

Re: Puppet SDK (pre-)announcement

Rob Nelson
 

David,

Thanks for the preview! I've only had time to review it on the surface, but one question about rubocop. I know the SDK will be opinionated, but do you envision the ability to use the SDK without rubocop? While VP uses it heavily, I don't use it in my modules and we don't use it at work because the pre-1.0.0 nature of it leads to a lot of breakage at the absolute worst times. VP *does* pin it to reduce those impacts, at least, whereas the SDK right now is not pinned or bound at all.

Rob Nelson
rnelson0@...

Re: Puppet SDK (pre-)announcement

David Schmitt
 



On 2 June 2017 at 16:22, David Hollinger <david.hollinger@...> wrote:
Awesome! This looks incredibly useful.

Thank you!
 

Couple questions:
  • Will this replace using 'puppet module generate' to create a new module?
I would wish so, see https://tickets.puppetlabs.com/browse/PUP-7398 ; I can't tell if and when that'll happen. Not before a release and soak time on the SDK side, for sure.
 
  • Will this use the Puppet Module Skeleton that 'puppet module generate' uses today or is it designed specifically to be used only with modulesync?
By default, the SDK's templates will reside in https://github.com/puppetlabs/pdk-module-template. This is overridable on a case-by-case basis, allowing you to provide your own templates. If you have PMG templates at the moment, you'll need to translate them, but I expect that to be relatively easy, as both use ERB. Should a significant number of folks pipe up with PMG compatible custom templates, we could consider implementing additional render support for those too.

More generally, if you have custom templates, we are also very interested in what you need there, so we can improve the SDK's templates so that this need goes away.


Cheers, David

Re: Puppet SDK (pre-)announcement

David Hollinger
 

Awesome! This looks incredibly useful.

Couple questions:
  • Will this replace using 'puppet module generate' to create a new module?
  • Will this use the Puppet Module Skeleton that 'puppet module generate' uses today or is it designed specifically to be used only with modulesync?

Re: Puppet SDK (pre-)announcement

Thomas Mueller <thomas@...>
 

Am 01.06.2017 um 19:34 schrieb David Schmitt:
Hi folks,

in the spirit of release early, release often, we've just opened up
the repositories for the pdk to the public:
https://github.com/puppetlabs/pdk
Nice! This is something I think could work out to be very useful.

- Thomas

Re: Puppet SDK (pre-)announcement

Bryan Jen <bryan.jen@...>
 

Hi folks,

One missing step from David's original email. If you are running pdk via the cloned git repo, you also will need to set an additional environment variable: PDK_USE_SYSTEM_BINARIES=true and ensure you have the appropriate binaries, like git, installed and in your path.

Thanks,
Bryan

On Thu, Jun 1, 2017 at 10:34 AM, David Schmitt <david.schmitt@...> wrote:
Hi folks,

in the spirit of release early, release often, we've just opened up the repositories for the pdk to the public: https://github.com/puppetlabs/pdk

The README there details some of what is planned for the next weeks, the implementation currently only has the "new module" command implemented. "new class" is currently in progress. The other commands will follow as the project progresses.

The second part of this are the templates at https://github.com/puppetlabs/pdk-module-template. Again, they are in a very early stage of development, but the long-term goal is to act as a one-stop-shop for all module related templating needs. Specifically, as a first step, replace our own modulesync_configs, and - if at all possible - the voxpupuli's one too. The format of the templates is intentionally based on modulesync, and should be bi-directionally usable for the time being.


Since we're just ramping up all the infrastructure around this project, the only sensible way to run the pdk currently is through bundler with a reference to the cloned Gemfile:

BUNDLE_GEMFILE=~/git/pdk/Gemfile bundle exec pdk help





I'd love to hear all your feedback, either here, or in private!


Cheers, David






--
Bryan Jen
Senior Software Engineer

Save the date:
PuppetConf 2017, 10-12 October
San Francisco, California

Puppet SDK (pre-)announcement

David Schmitt
 

Hi folks,

in the spirit of release early, release often, we've just opened up the repositories for the pdk to the public: https://github.com/puppetlabs/pdk

The README there details some of what is planned for the next weeks, the implementation currently only has the "new module" command implemented. "new class" is currently in progress. The other commands will follow as the project progresses.

The second part of this are the templates at https://github.com/puppetlabs/pdk-module-template. Again, they are in a very early stage of development, but the long-term goal is to act as a one-stop-shop for all module related templating needs. Specifically, as a first step, replace our own modulesync_configs, and - if at all possible - the voxpupuli's one too. The format of the templates is intentionally based on modulesync, and should be bi-directionally usable for the time being.


Since we're just ramping up all the infrastructure around this project, the only sensible way to run the pdk currently is through bundler with a reference to the cloned Gemfile:

BUNDLE_GEMFILE=~/git/pdk/Gemfile bundle exec pdk help





I'd love to hear all your feedback, either here, or in private!


Cheers, David



Re: Changes to the Vox Pupuli Github Org Management

Julien Pivotto
 

On 26 May 14:21, Igor Galić wrote:
i noticed today that terraform also supports mailgun:
https://www.terraform.io/docs/providers/mailgun/index.html
unfortunately, their provider only supports managing the domain itself,
and we would also need to manage the coc@ & security@ list.

judging from
https://github.com/hashicorp/terraform/blob/master/builtin/providers/mailgun/resource_mailgun_domain.go
it doesn't look too hard to implement tho… so we could probably
contribute that.

​​​​​​--
Igor Galić
Yes Terraform is evolving into an API calling tool :)

--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu

Re: Changes to the Vox Pupuli Github Org Management

Igor Galić
 

i noticed today that terraform also supports mailgun:
https://www.terraform.io/docs/providers/mailgun/index.html
unfortunately, their provider only supports managing the domain itself,
and we would also need to manage the coc@ & security@ list.

judging from
https://github.com/hashicorp/terraform/blob/master/builtin/providers/mailgun/resource_mailgun_domain.go
it doesn't look too hard to implement tho… so we could probably
contribute that.

​​​​​​--
Igor Galić

Tel: +43 (0) 664 886 22 883
Web: https://brainsware.org/

Checkout our https://sealas.at/ The first end-to-end encrypted
accounting software!

On Thu, 25 May 2017, at 23:01, Igor Galić wrote:
Juilen,

i love this idea and would love to see it implemented, asap (so i can
steal it)

imo, in a first step, we should simply configure what we currently have
which is, everyone has access to all repos, and the PMC has admin
access.

On Wed, 17 May 2017, at 15:24, Julien Pivotto wrote:
On 17 May 07:38, Mike Terzo wrote:
So we gonna have a python team for managing puppetboard and pypuppet?
We could ; I have no real idea on how it is configure now.


On May 17, 2017, at 5:33 AM, Julien Pivotto <roidelapluie@...> wrote:

Hi,

As Security Officer, I am planning to make a few changes
in the way we manage our Github Organization. I would like for us to
stop clicking around in the web interface, without any visibility of who
did what. I would like to define our github infrastructure as code.

---

Why ?

Here are the benefits:
- Reduce the number of people with extended right on the github
organisation
- Clearly define every group we have in the organisation ; permissions
- Have consistent Github repositories settings accross all repos ; e.g.
protecting master branch.
- Let new members auto register via pull requests

---

Cons ?

- Obviously if you were using your admin rights to do strange things,
this will need to be done in the control repo, at everyone's sight
- Membership will be public ; it is something we did not enforce in the
past.

---

WHAT?? public membership??

I think it is important that people know who has and does not have
access to our git repositories. For an org like Vox Pupuli, where
everyone has a role to play and a lot of power, I think it can only be
like that. Public membership is important.

---

Technical

The technical solution for this would use Terraform to do this.

https://www.hashicorp.com/blog/managing-github-with-terraform/

It is not clear yet if we would do it with travis-ci or not.

We would have a SecPupuli org, completely different from the VoxPupuli
Org, but still completely public.

---

Now I would like to know if anyone has any concern with this --
including public membership -- before I dig deeper in the implementation..


​​​​​​--
Igor Galić

Tel: +43 (0) 664 886 22 883
Web: https://brainsware.org/

Checkout our https://sealas.at/ The first end-to-end encrypted
accounting software!



Re: Candidate module for testing Puppet Forge namespace migration?

Igor Galić
 

Has anyone considered making this public (authenticated) API?


--
Igor Galić

Tel: +43 (0) 664 886 22 883
Web: https://brainsware.org/

Checkout our https://sealas.at/ The first end-to-end encrypted accounting software!


On Thu, 25 May 2017, at 22:56, Robin Bowes wrote:
Hi,

I've been asked to report that I have migrated the logstash module to voxpulpuli.

I've also added it to the Google sheet.

Can you please do the namespace migration on the forge?

Thanks,

R.





Re: Changes to the Vox Pupuli Github Org Management

Igor Galić
 

Juilen,

i love this idea and would love to see it implemented, asap (so i can
steal it)

imo, in a first step, we should simply configure what we currently have
which is, everyone has access to all repos, and the PMC has admin
access.

On Wed, 17 May 2017, at 15:24, Julien Pivotto wrote:
On 17 May 07:38, Mike Terzo wrote:
So we gonna have a python team for managing puppetboard and pypuppet?
We could ; I have no real idea on how it is configure now.


On May 17, 2017, at 5:33 AM, Julien Pivotto <roidelapluie@...> wrote:

Hi,

As Security Officer, I am planning to make a few changes
in the way we manage our Github Organization. I would like for us to
stop clicking around in the web interface, without any visibility of who
did what. I would like to define our github infrastructure as code.

---

Why ?

Here are the benefits:
- Reduce the number of people with extended right on the github
organisation
- Clearly define every group we have in the organisation ; permissions
- Have consistent Github repositories settings accross all repos ; e.g.
protecting master branch.
- Let new members auto register via pull requests

---

Cons ?

- Obviously if you were using your admin rights to do strange things,
this will need to be done in the control repo, at everyone's sight
- Membership will be public ; it is something we did not enforce in the
past.

---

WHAT?? public membership??

I think it is important that people know who has and does not have
access to our git repositories. For an org like Vox Pupuli, where
everyone has a role to play and a lot of power, I think it can only be
like that. Public membership is important.

---

Technical

The technical solution for this would use Terraform to do this.

https://www.hashicorp.com/blog/managing-github-with-terraform/

It is not clear yet if we would do it with travis-ci or not.

We would have a SecPupuli org, completely different from the VoxPupuli
Org, but still completely public.

---

Now I would like to know if anyone has any concern with this --
including public membership -- before I dig deeper in the implementation..


​​​​​​--
Igor Galić

Tel: +43 (0) 664 886 22 883
Web: https://brainsware.org/

Checkout our https://sealas.at/ The first end-to-end encrypted
accounting software!

Re: Candidate module for testing Puppet Forge namespace migration?

Robin Bowes
 

Hi,

I've been asked to report that I have migrated the logstash module to voxpulpuli.

I've also added it to the Google sheet.

Can you please do the namespace migration on the forge?

Thanks,

R.

Re: Candidate module for testing Puppet Forge namespace migration?

Lindsey Smith
 



On Wed, May 17, 2017 at 8:59 AM, <david.hollinger@...> wrote:
On Thu, Mar 23, 2017 at 11:42 am, Lindsey Smith wrote:
https://docs.google.com/spreadsheets/d/16aCE7VYHrLw44k3stjwFuFPKN5YQqM6GxLvz-CtN1D0/edit#gid=0

 Resurrecting a 2 month old topic, but can we get this link some more visibility in the VP community. I (like Rob) can't put enough emphasis on how awesome this is, but it doesn't look like many people have added to the spreadsheet and it's probably just out of ignorance.


Thanks for bring this back up David.

Also keep this in mind for next week's Puppet hack day. If anyone with a migrated module participates, we can get their permission to mark the module as deprecated.

Lindsey

 


Should there be a blog post on voxpupuli.org and perhaps a link added to the IRC Topic?


Re: Candidate module for testing Puppet Forge namespace migration?

David Hollinger
 

On Thu, Mar 23, 2017 at 11:42 am, Lindsey Smith wrote:
https://docs.google.com/spreadsheets/d/16aCE7VYHrLw44k3stjwFuFPKN5YQqM6GxLvz-CtN1D0/edit#gid=0

 Resurrecting a 2 month old topic, but can we get this link some more visibility in the VP community. I (like Rob) can't put enough emphasis on how awesome this is, but it doesn't look like many people have added to the spreadsheet and it's probably just out of ignorance.


Should there be a blog post on voxpupuli.org and perhaps a link added to the IRC Topic?

Re: Changes to the Vox Pupuli Github Org Management

Julien Pivotto
 

On 17 May 07:38, Mike Terzo wrote:
So we gonna have a python team for managing puppetboard and pypuppet?
We could ; I have no real idea on how it is configure now.


On May 17, 2017, at 5:33 AM, Julien Pivotto <roidelapluie@...> wrote:

Hi,

As Security Officer, I am planning to make a few changes
in the way we manage our Github Organization. I would like for us to
stop clicking around in the web interface, without any visibility of who
did what. I would like to define our github infrastructure as code.

---

Why ?

Here are the benefits:
- Reduce the number of people with extended right on the github
organisation
- Clearly define every group we have in the organisation ; permissions
- Have consistent Github repositories settings accross all repos ; e.g.
protecting master branch.
- Let new members auto register via pull requests

---

Cons ?

- Obviously if you were using your admin rights to do strange things,
this will need to be done in the control repo, at everyone's sight
- Membership will be public ; it is something we did not enforce in the
past.

---

WHAT?? public membership??

I think it is important that people know who has and does not have
access to our git repositories. For an org like Vox Pupuli, where
everyone has a role to play and a lot of power, I think it can only be
like that. Public membership is important.

---

Technical

The technical solution for this would use Terraform to do this.

https://www.hashicorp.com/blog/managing-github-with-terraform/

It is not clear yet if we would do it with travis-ci or not.

We would have a SecPupuli org, completely different from the VoxPupuli
Org, but still completely public.

---

Now I would like to know if anyone has any concern with this --
including public membership -- before I dig deeper in the implementation..

--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu



--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu

Re: Changes to the Vox Pupuli Github Org Management

Mike Terzo
 

So we gonna have a python team for managing puppetboard and pypuppet?

On May 17, 2017, at 5:33 AM, Julien Pivotto <roidelapluie@...> wrote:

Hi,

As Security Officer, I am planning to make a few changes
in the way we manage our Github Organization. I would like for us to
stop clicking around in the web interface, without any visibility of who
did what. I would like to define our github infrastructure as code.

---

Why ?

Here are the benefits:
- Reduce the number of people with extended right on the github
organisation
- Clearly define every group we have in the organisation ; permissions
- Have consistent Github repositories settings accross all repos ; e.g.
protecting master branch.
- Let new members auto register via pull requests

---

Cons ?

- Obviously if you were using your admin rights to do strange things,
this will need to be done in the control repo, at everyone's sight
- Membership will be public ; it is something we did not enforce in the
past.

---

WHAT?? public membership??

I think it is important that people know who has and does not have
access to our git repositories. For an org like Vox Pupuli, where
everyone has a role to play and a lot of power, I think it can only be
like that. Public membership is important.

---

Technical

The technical solution for this would use Terraform to do this.

https://www.hashicorp.com/blog/managing-github-with-terraform/

It is not clear yet if we would do it with travis-ci or not.

We would have a SecPupuli org, completely different from the VoxPupuli
Org, but still completely public.

---

Now I would like to know if anyone has any concern with this --
including public membership -- before I dig deeper in the implementation..

--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu


Changes to the Vox Pupuli Github Org Management

Julien Pivotto
 

Hi,

As Security Officer, I am planning to make a few changes
in the way we manage our Github Organization. I would like for us to
stop clicking around in the web interface, without any visibility of who
did what. I would like to define our github infrastructure as code.

---

Why ?

Here are the benefits:
- Reduce the number of people with extended right on the github
organisation
- Clearly define every group we have in the organisation ; permissions
- Have consistent Github repositories settings accross all repos ; e.g.
protecting master branch.
- Let new members auto register via pull requests

---

Cons ?

- Obviously if you were using your admin rights to do strange things,
this will need to be done in the control repo, at everyone's sight
- Membership will be public ; it is something we did not enforce in the
past.

---

WHAT?? public membership??

I think it is important that people know who has and does not have
access to our git repositories. For an org like Vox Pupuli, where
everyone has a role to play and a lot of power, I think it can only be
like that. Public membership is important.

---

Technical

The technical solution for this would use Terraform to do this.

https://www.hashicorp.com/blog/managing-github-with-terraform/

It is not clear yet if we would do it with travis-ci or not.

We would have a SecPupuli org, completely different from the VoxPupuli
Org, but still completely public.

---

Now I would like to know if anyone has any concern with this --
including public membership -- before I dig deeper in the implementation..

--
(o- Julien Pivotto
//\ Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu