Feature: pengine: Support id-ref in nvpair with optional "name" #425

merged 2 commits into from Apr 9, 2014


None yet

2 participants

gao-yan commented Jan 29, 2014

If "name" isn't specified, it inherits the name from the referenced nvpair.

It's very convenient if there are plenty of resources' parameters that are supposed to have same values.

beekhof commented Feb 18, 2014

Could I see a real-world example?

gao-yan commented Feb 18, 2014

For example, we have an IPaddr2 resource that has the parameter ip="". There could be quite a few other resources would like to reference the same IP address value, while they might have different parameter keys, like "host", "service_ip" and so on.

beekhof commented Feb 21, 2014

So referencing the original instance_attributes doesn't help because the new location might need the value supplied with a different name, eg. other-ip vs. ip. Is that the idea?

Because otherwise you can just split up the original attributes into shared and non-shared and use [instance-attributes id-ref="shared-ones"/]

gao-yan commented Feb 21, 2014

Exactly the idea :-) And we think it's not uncommon that they have different parameter names

gao-yan commented Mar 3, 2014

nvset.rng is used everywhere, even in 1.0.rng. So I added a separate nvset-nvpair-ref.rng for this, and only enabled it for resource instance attributes in 1.1.rng for now.

beekhof commented Mar 4, 2014

Any reason to limit it to just resources? The code works for everywhere right?

gao-yan commented Mar 5, 2014

Yes, it works for everywhere. I was thinking resource instance attributes is the mostly used case. Do you prefer enabling it everywhere?

beekhof commented Mar 7, 2014

Its potentially easier to document - an admin would probably expect to use it anywhere.
Can you imagine any legitimate use outside of resources?

gao-yan commented Mar 7, 2014

Would someone want to use a resource's attribute as a global crm_config or rsc_defaults? Inside of resources, probably it could be used also for utilization and meta_attributes. There seems to be no harm to enable it everywhere.

gao-yan commented Mar 7, 2014

If we enable it everywhere, do you think it'd be better to move the old nvset.rng to nvset-1.0.rng for use of pacemaker-1.0, and to patch nvset.rng with the new feature, so that pacemaker-1.1 and pacemaker-1.2 will get it. So we use the best naming for latest stuff.

gao-yan commented Mar 11, 2014

The current commits support idref in nvpair everywhere. Moved the old nvset.rng to nvset-1.0.rng

gao-yan commented Apr 8, 2014

Rebased. Hope I did the schema in the right way ;-) I guess we'd better move the old nvset.rng to nvset-1.0.rng when the feature is added for 1.2 schema.

@beekhof beekhof merged commit 6442c5a into ClusterLabs:master Apr 9, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment