[chef-testing-stack] decouple openstack cooks from role dependencies

[Jesse Nelson]

As many people prefer to not use roles very heavily I think it would be in our best interest in attracting as much support as possible. To enable the searches for endpoints and other functions to use attributes,recipes, or roles. It should be pretty easy to build a fall-through in the various search methods.

What I want to understand is how we would prefer the default precedence to be.

I suppose also we could set a preferred search method attribute.

Feedback is appreciated. I intend on doing this work for our implementation.

P.S.
In setting up a reference implementation I ran into a number of issue getting roles working right. One local issue is developing with chef-zero, which doesn't support .rb roles. So I had to convert everything over to .json roles (which brings my local out of sync with upstream). Another was the memcached bugs that have patches pending.

[Christopher H. Laco (claco)]

Role names and recipe names change as people start composing lib books into app/wrapper books. Attributes stay the same more often imho. +1

[Jay Pipes (jaypipes)]

Totally agreed. We're slowly moving away from roles ourselves because of myriad issues with them, including the order in which role attributes are evaluated and the fact that you can't version roles.

[Jay Pipes (jaypipes)]

I think that the way we've done things like node["openstack"]["mq"]["servers"] is the right way to go. Basically, the search_for stuff and rabbit_servers methods first look to see if that attribute is set to something and if not, look up nodes based on a role name. A wrapper cookbook would set the above attribute to whatever the deployer wants, depending on the environment, etc.

[Jesse Nelson (spheromak)]

My only really issue with using the node["openstack"]["mq"]["servers"] is that it relies on having pre-defined info vs discovered info. Makes it so that you have to put this attribute in a role or environment, and update that if topology changes.

I suppose nothing stops me from searching for this in a wrapper and then populating the attribute. So from a library cook standpoint it may make the most sense to use this over everything else.

So are we advocating getting rid of the search lookups for endpoints in favor of attributes ?

[Jay Pipes (jaypipes)]

No, I'm saying we should make everything follow the pattern of:

1) Attributes in openstack-common library should be checked first
2) If attributes are nil, use a role-based lookup

At this point, I believe only the MQ servers and memcached servers stuff follows the above pattern. We should use it for all places where we currently hard-code role-based lookup, IMHO.

Hope that clarifies my point,

-jay

[Jesse Nelson (spheromak)]

I can go with this as the model. Then wrappers can set attributes however they like, and our default is simple to understand. We would also want to make the search role an attribute as well. This is also something that the mq stuff is doing at the moment.

[Mark Vanderwiel (vanderwl)]

This has had enough time to move, closing for now.