Ir para o conteúdo
Mostrar cesto Esconder cesto
Voltar a Blog
Tela cheia

Hierarchical, multi-instance and attributes oriented LWRP

20 de Janeiro de 2015, 20:31 , por Bráulio Bhavamitra - 0sem comentários ainda | Ninguém está seguindo este artigo ainda.
Visualizado 1641 vezes

When porting the biggest LWRP I maintain (https://supermarket.chef.io/cookbooks/noosfero) from the "old" fashion of node attributes to LWRPs, I had to face many conflicts from the shift of paradigm. In the end, I had mixed and used concepts of both.

The standard LWRP of Chef wasn't enough, as LWRPs aren't:

  • Multi-instance Usually a LWRP isn't designed on multi-instance services or applications, so that on one given node you have multiple services/applications configured. Not only applications but also services are also going into that direction.
  • Hierarchical For big configurations, it doesn't make sense to put everything on one LWRP. But also, it doesn't make sense to make them completely independent, as each LWRP is linked to one instance of the application or service. Besides, one LWRP configuration may depend on the configuration of another LWRP.
  • Attributes-oriented The wrapper cookbook pattern really don't make sense to me, just as mixing data with arbitrary Ruby code would add too much logic to data. A parallel to this is the logicless templates. So the cookbook's LWRP must handle a simple transformation between node attributes and the LWRP's attributes and actions.

Multi-instance

In the case of noosfero cookbook the top-level LWRP that defines an instance is noosfero_site. Each site defines a service_name that is the identifier of the instance. All child LWRPs have this identifier so that can be called independently. This is implemented with an attribute defined on a base class used by all LWRPS.

It is also used as part of the identifier of other LWRP used, for example:

bash "#{new_resource.service_name} some script" do
end

Hierarchical

The noosfero_site LWRP may call any other LWRP prefixed with noosfero_. An example explain better:

noosfero_site 'cirandas' do
server_name 'cirandas.net'

server do
backend 'unicorn'

proxy do
with 'nginx'
end
cache do
with 'varnish'
end
end
backup do
to 'mybackuphost'
user 'backup'
end
end

In the above example, the noosfero_server, noosfero_proxy, noosfero_cache and noosfero_backup LWRPs were used.

The support for this was also implemented on the base LWRP class, see method child_resource and method_missing.

Attributes-oriented

The above example can be translated almost directly to node attributes, for example, inside a role:

default_attributes({
noosfero: {
sites: {
cirandas: {
server_name: 'cirandas.net',

server: {
proxy: {
with: 'nginx',
},
cache: {
with: 'varnish',
},
},

backup: {
to: 'mybackuphost',
user: 'backup',
},
},
},
},
})

This way we can still take benefit from attribute precedence and merge, by defining values on base roles for multiple instances. The support for this was implemented by redefining set_or_return LWRP's method at the same place.

Future

I hope the support for multi-instance, hiercharchical and attributes-oriented LWRP comes to Chef core in the near future. While it is yet not available, feel free to use https://github.com/coletivoEITA/noosfero-cookbook/blob/master/libraries/noosfero_lwrp.rb as your LWRPs' base class.

 

 


0sem comentários ainda

    Enviar um comentário

    Os campos são obrigatórios.

    Se você é um usuário registrado, pode se identificar e ser reconhecido automaticamente.

    Cancelar