Jira (PUP-11597) 'puppet generate types' does not account for changes in the PuppetX module namespace

14 views
Skip to first unread message

Nate McCurdy (Jira)

unread,
Jul 25, 2022, 9:04:02 PM7/25/22
to puppe...@googlegroups.com
Nate McCurdy created an issue
 
Puppet / Bug PUP-11597
'puppet generate types' does not account for changes in the PuppetX module namespace
Issue Type: Bug Bug
Affects Versions: PUP 6.28.0, PUP 7.18.0
Assignee: Unassigned
Created: 2022/07/25 6:03 PM
Priority: Normal Normal
Reporter: Nate McCurdy

Puppet Version: 7.18.0, 6.28.0
OS Name/Version: CentOS 7

The Problem

When deploying changes to a custom type that includes relative code from the PuppetX namespace, and only the PuppetX ruby files have changed, the 'generate types' command skips the type because it thinks it's up-to-date.

This means any new/removed type properties possibly won't be available due the environment isolation problem that puppet generate types was meant to solve.

Actual Behavior

The 'puppet generate types' command uses the following implementation to determine if a custom type's attributes should be built into '<environment>/.resource_types/*.pp':

Puppet::FileSystem::exist?(f) && (Puppet::FileSystem::stat(@path) <=> Puppet::FileSystem::stat(f)) <= 0

That's from https://github.com/puppetlabs/puppet/blob/7.18.0/lib/puppet/generate/type.rb#L49

This compares the modified timestamp of the type file with that of the generated .resource_types/*.pp file.

But if the file in lib/puppet/type/*.rb didn't change, it's timestamp will not get updated and Puppet will think the generated types are up to date.

Desired Behavior

'puppet generate types' should account for PuppetX namespaced code (e.g. "<module>/lib/puppet_x/<namespace>/.rb" ) that is included by a type that lives at <module>/lib/puppet/type/.rb.

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)
Atlassian logo

Nate McCurdy (Jira)

unread,
Jul 25, 2022, 9:06:02 PM7/25/22
to puppe...@googlegroups.com
Nate McCurdy updated an issue
Change By: Nate McCurdy
*Puppet Version:* 7.18.0, 6.28.0
*OS Name/Version:* CentOS 7

h3. The Problem

When deploying changes to a custom type that includes relative code from the {{PuppetX}} namespace, and only the {{PuppetX}} ruby files have changed, the '{{generate types}}' command skips the type because it thinks it's up-to-date.

This means any new/removed type properties possibly won't be available due the environment isolation problem that {{puppet generate types}} was meant to solve.

h3. Actual Behavior


The '{{puppet generate types}}' command uses the following implementation to determine if a custom type's attributes should be built into '{{<environment>/.resource_types/*.pp}}':
{code:ruby}

Puppet::FileSystem::exist?(f) && (Puppet::FileSystem::stat(@path) <=> Puppet::FileSystem::stat(f)) <= 0
{code}

That's from https://github.com/puppetlabs/puppet/blob/7.18.0/lib/puppet/generate/type.rb#L49

This compares the modified timestamp of the type file with that of the generated {{.resource_types/*.pp}} file.

But if the file in {{lib/puppet/type/*.rb}} didn't change, it's timestamp will not get updated and Puppet will think the generated types are up to date.

h3. Desired Behavior

'{{puppet generate types}}' should account for PuppetX namespaced code (e.g.
" ' {{<module>/lib/puppet_x/<namespace>/*.rb}} " ' ) that is included by a type that lives at ' {{<module>/lib/puppet/type/*.rb}} ' .

Nate McCurdy (Jira)

unread,
Jul 25, 2022, 10:03:02 PM7/25/22
to puppe...@googlegroups.com
Nate McCurdy updated an issue
*Puppet Version:* 7.18.0, 6.28.0
*OS Name/Version:* CentOS 7

h3. The Problem

When deploying changes to a custom type that includes relative code from the {{PuppetX}} namespace, and only the {{PuppetX}} ruby files have changed, the '{{ {} generate types { }} }
' command skips the type because it thinks it's up-to-date.

This means any new/removed type
properties parameters possibly won't be available due the environment isolation problem that {{puppet generate types}} was meant to solve.

h3. Actual Behavior

The '{{
{} puppet generate types { }} } ' command uses the following implementation to determine if a custom type's attributes should be built into '{{ {} <environment>/.resource_types/*.pp { }} } ':
{code:ruby}

Puppet::FileSystem::exist?(f) && (Puppet::FileSystem::stat(@path) <=> Puppet::FileSystem::stat(f)) <= 0
{code}
That's from
[ https://github.com/puppetlabs/puppet/blob/7.18.0/lib/puppet/generate/type.rb#L49 ]

This compares the modified timestamp of the type file with that of the generated {{.resource_types/*.pp}} file.

But if the file in {{lib/puppet/type/*.rb}} didn't change, it's timestamp will not get updated and Puppet will think the generated types are up to date.

h3. Desired Behavior

'{{
{} puppet generate types { }} } ' should account for PuppetX namespaced code (e.g. '{{ {} <module>/lib/puppet_x/<namespace>/ { * } .rb {* } { } }}{*} ') that is included by a type that lives at '{{ {} <module>/lib/puppet/type/ {}}}{ * }{{{} .rb { }} } '.

Nate McCurdy (Jira)

unread,
Jul 25, 2022, 10:08:01 PM7/25/22
to puppe...@googlegroups.com

Nate McCurdy (Jira)

unread,
Jul 26, 2022, 2:03:03 PM7/26/22
to puppe...@googlegroups.com
Nate McCurdy updated an issue
*Puppet Version:* 7.18.0, 6.28.0
*OS Name/Version:* CentOS 7
h3. The Problem

When deploying changes to a custom type that includes relative code from the {{PuppetX}} namespace, and only the {{PuppetX}} ruby files have changed, the '{{{}generate types{}}}' command skips the type because it thinks it's up-to-date.

This means any new/removed type parameters possibly won't be available due the environment isolation problem that {{puppet generate types}} was meant to solve.

h3. Actual Behavior

The '{{{}puppet generate types{}}}' command uses the following implementation to determine if a custom type's attributes should be built into '{{{}<environment>/.resource_types/*.pp{}}}':
{code:ruby}Puppet::FileSystem::exist?(f) && (Puppet::FileSystem::stat(@path) <=> Puppet::FileSystem::stat(f)) <= 0
{code}
That's from [https://github.com/puppetlabs/puppet/blob/7.18.0/lib/puppet/generate/type.rb#L49]

This compares the modified timestamp of the type file with that of the generated {{.resource_types/*.pp}} file.

But if the file in {{lib/puppet/type/*.rb}} didn't change, it's timestamp will not get updated and Puppet will think the generated types are up to date.
h3. Desired Behavior

'{{ {} puppet generate types { }} } ' should account for PuppetX namespaced name-spaced code (e.g. '{{ {} <module>/lib/puppet_x/<namespace>/ { \ * } .rb {* } { } }}{*} ') that is included by a type that lives at '{{ {} <module>/lib/puppet/type/ {}}}{ \ * }{{{} .rb { }} } '.

Nirupama Mantha (Jira)

unread,
Jul 26, 2022, 4:15:01 PM7/26/22
to puppe...@googlegroups.com

Nate McCurdy (Jira)

unread,
Jul 26, 2022, 4:43:01 PM7/26/22
to puppe...@googlegroups.com
Nate McCurdy commented on Bug PUP-11597
 
Re: 'puppet generate types' does not account for changes in the PuppetX module namespace

Based on a quick Slack conversation in the #puppet community channel, here's an extremely raw proof-of-concept fix for this problem: https://github.com/puppetlabs/puppet/pull/8928

It just enumerates all <module>/lib/*/.rb files and compares their timestamps to the generated .resource_types/*.pp file.

Reply all
Reply to author
Forward
0 new messages