Class ordering via anchor patterns not working in a pretty simple setup

[Abhijeet Rastogi]

Hi everyone,

I've 2 simple base classes:

class profile::base {
  anchor { 'base_repos_start': }
  class { '::yum::repo::epel': require   => Anchor['base_repos_start']}
  class { '::yum::repo::puppet': require =>  Anchor['base_repos_start']}
  anchor { 'base_repos_end': }
}

class profile::openstack::base {
  anchor { 'rdo_repo_start': }
  class { '::yum::repo::rdo': require => Anchor['rdo_repo_start']}
  anchor { 'rdo_repo_end': }
}

And then I use this classes in another class which is related to a particular class of servers.

class role::openstack::controller {
  class { '::profile::base': } ->
  class { '::profile::openstack::base': } ->
  class { '::profile::openstack::keystone': } ->
  class { '::profile::openstack::glance': } ->
  class { '::profile::openstack::nova::controller': } ->
  class { '::profile::openstack::neutron::controller': }
}

When I run puppet, I observe that "stuff" in class ::profile::openstack::glance starts happening before the repos get added via base classes profile::base & profile::openstack::base. The reason I say that resources from ::profile::openstack::glance start getting applied before base classes is (The output is from the first puppet run and the package installation of openstack-glance is present in class ::profile::openstack::glance):

Debug: /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_endpoint[RegionOne/neutron]: Autorequiring Keystone_service[neutron]
Info: Applying configuration version '1418737032'
Debug: Prefetching yum resources for package
Debug: Executing '/usr/bin/rpm --version'
Debug: Executing '/usr/bin/rpm -qa --nosignature --nodigest --qf '%{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}\n''
Debug: Executing '/usr/bin/rpm -q openstack-glance --nosignature --nodigest --qf %{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}\n'
Debug: Executing '/usr/bin/yum -d 0 -e 0 -y list openstack-glance'
Error: Execution of '/usr/bin/yum -d 0 -e 0 -y list openstack-glance' returned 1: Error: No matching Packages to list
Error: /Stage[main]/Glance/Package[openstack-glance]/ensure: change from absent to present failed: Execution of '/usr/bin/yum -d 0 -e 0 -y list openstack-glance' returned
 1: Error: No matching Packages to list
Notice: /Stage[main]/Glance::Notify::Rabbitmq/Glance_api_config[DEFAULT/kombu_ssl_keyfile]: Dependency Package[openstack-glance] has failures: true

I think I'm using anchor patterns correctly but they don't seem to be working. Is there anything that I'm doing fundamentally wrong? Any possible reasons this might not be working?

--
Cheers,
Abhijeet Rastogi (shadyabhi)

[jcbollinger]

On Tuesday, December 16, 2014 7:59:00 AM UTC-6, Abhijeet Rastogi wrote:
 
[...]

class profile::base {
  anchor { 'base_repos_start': }
  class { '::yum::repo::epel': require   => Anchor['base_repos_start']}
  class { '::yum::repo::puppet': require =>  Anchor['base_repos_start']}
  anchor { 'base_repos_end': }
}

[...]
 

 

I think I'm using anchor patterns correctly but they don't seem to be working. Is there anything that I'm doing fundamentally wrong? Any possible reasons this might not be working?

Yes.  Contrary to your assertion, you are not using the anchor pattern correctly.  Your contained classes are related only to the starting anchor, not to the ending anchor.  Correct use of the anchor pattern would look more like this:

class profile::base {
  anchor { 'base_repos_start': }

  class { '::yum::repo::epel': require   => Anchor['base_repos_start'], before => Anchor['base_repos_end'] }
  class { '::yum::repo::puppet': require =>  Anchor['base_repos_start'], before => Anchor['base_repos_end'] }
  anchor { 'base_repos_end': }
}

If you are using a sufficiently recent Puppet, however, then you should instead use the new(ish) 'contain()' function.  In full generality that would look like this:

class profile::base {
  class { '::yum::repo::epel': }
  class { '::yum::repo::puppet': }
  contain '::yum::repo::epel'
  contain '::yum::repo::puppet'
}

Since your classes don't (any more) require any parameters to be specified in your manifests, however, you can shorten that further to simply

class profile::base {
  contain '::yum::repo::epel'
  contain '::yum::repo::puppet'
}


John

[Abhijeet Rastogi]

Hi John,

Thanks for replying. I tried using contain.

class profile::base {
  contain '::yum::repo::epel'
  contain '::yum::repo::puppet'
}

Still didn't work for me. Is there a possibility of known bug being triggered?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4e8e0699-0857-47dc-a77b-1b916ab5d9e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

On Wednesday, December 17, 2014 9:20:19 AM UTC-6, Abhijeet Rastogi wrote:

Hi John,

Thanks for replying. I tried using contain.

class profile::base {
  contain '::yum::repo::epel'
  contain '::yum::repo::puppet'
}

Still didn't work for me. Is there a possibility of known bug being triggered?

I am unaware of any known bugs in this area.

Ensure that the master is actually using the version of the class with 'contain' (i.e. flush the environment cache or restart the master altogether; put notice() calls in the class body so you can verify that it is being evaluated at the master, and put in at least one Notify resource to confirm that the agent is applying a catalog built from that version).  If the order still doesn't seem right then post the order you observe with 'contain'.  Also, check your output for warnings, especially any talking about resource cycles.


John

[Felix Frank]

On 12/17/2014 04:19 PM, Abhijeet Rastogi wrote:
> contain '::yum::repo::epel'
> contain '::yum::repo::puppet'

Are these "flat" classes, i.e. do they only declare actual resources?

If these include more classes, those might be out of order regardless.