Virtual definitions: What's the correct behaviour? (#1157)

[Luke Kanies]

Hi all,

Arjuna just filed #1157[1], which basically asks for an inverse of the
behaviour committed in #997[2].

Basically, up until (I think) 0.24.3, if you had a defined resource
that was virtual (or exported, which is a superset), then the defined
resource would get expanded into a list of virtual resources. This
meant you could realize/collect individual resources from within the
definition, but it also meant that you couldn't collect defined
resources (because the definition itself isn't stored, only the
component resources, at least at this point).

This does introduce a potential race condition:

hostA exports a resource created with definition 1.0
hostB collects that resource using definition 1.1 a bit later

This race condition wouldn't really exist if we expanded everything,
but it would be much harder to collect exported resources.

Here are the two choices I see, with the bits I can think of:

1) Virtual/Exported defined resources get expanded into the component
resources.

* At least for now, you won't be able to collect defined resources,
although I expect we could add this ability eventually.

* Collects inside virtual definitions should also be made virtual, and
the should get evaluated if the defined virtual resource is realized.
This shouldn't be *too* much code, but it's at least "some".

* You can realize just a part of a defined resource, rather than the
whole thing.

* Contained resources acquire defaults from the exporting host.

2) Virtual/Exported defined resources do not get expanded.

* You can immediately export and collect defined resources.

* Defined resources are a bit more like first-class objects.

* You can't reach into the guts of a virtual defined resource and just
realize a single resource; you have to treat the whole thing.

* The above mentioned race condition, which can appear when the
exporting and collecting hosts are operating against different
versions of the configurations.

* Contained resources acquire defaults from the collecting host.

So, what do people think?

I'm leaning toward #2, which not so coincidentally is the current (and
thus easiest to implement) behaviour.

1 - http://reductivelabs.com/trac/puppet/ticket/1157
2 - http://reductivelabs.com/trac/puppet/ticket/997

--
Basic research is what I am doing when I don't know what I am doing.
--Wernher von Braun
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

[Arjuna Christensen]

I'm actually indifferent regarding this change; the current behaviour can be worked around by simply modifying the resources-to-be-exported inside of the define block and as you mentioned allows for a collection of defines, and, virtual AND exported sub resources inside a parent define (clarification of individual sub resources).

+1 for whichever you feel is best; if the current behaviour is "intended", then let's concrete it and make sure everyone is aware of the potential? manifest changes.

I don't want to hold up 0.24.4 with a silly bug which no one apart from me really cares about, especially with such an easy workaround.

n.b.; is sub resources the correct term? Child resources?

Regards,

Arjuna Christensen | Systems Engineer 
Maximum Internet Ltd
DDI: + 64 9 913 9683 | Ph: +64 9 915 1825 | Fax:: +64 9 300 7227
arjuna.ch...@maxnet.co.nz| www.maxnet.co.nz

[James Turnbull]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1 for #2.

My biggest gripe for the 100th odd time is documentation. :) If someone
would like to expand on the documentation - even if just to document
this scenario with appropriate examples that'd be greatly appreciated.

Cheers

James

- --
James Turnbull (ja...@lovedthanlost.net)
- --
Author of:
- - Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
- - Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
- - Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH6JIe9hTGvAxC30ARAh7VAJ9xge3UVwkQ5mlU/SXRqWdouqZsKQCgndNR
Ik3IkSoE313liudSJEqSA4w=
=dcJy
-----END PGP SIGNATURE-----

[Luke Kanies]

On Mar 25, 2008, at 12:48 AM, James Turnbull wrote:

> +1 for #2.
>
> My biggest gripe for the 100th odd time is documentation. :) If
> someone
> would like to expand on the documentation - even if just to document
> this scenario with appropriate examples that'd be greatly appreciated.

Okay, we've got 2/2 votes (not counting myself) for leaving it as it
is. With this (and no heinous bugs filed between now and tomorrow
afternoon my time) we'll get 0.24.4 around lunchtime my time.

--
Ninety-eight percent of the adults in this country are decent,
hard-working, honest Americans. It's the other lousy two percent that
get all the publicity. But then--we elected them. --Lily Tomlin

[Luke Kanies]

On Mar 24, 2008, at 10:12 PM, Arjuna Christensen wrote:

> I'm actually indifferent regarding this change; the current
> behaviour can be worked around by simply modifying the resources-to-
> be-exported inside of the define block and as you mentioned allows
> for a collection of defines, and, virtual AND exported sub resources
> inside a parent define (clarification of individual sub resources).
>
> +1 for whichever you feel is best; if the current behaviour is
> "intended", then let's concrete it and make sure everyone is aware
> of the potential? manifest changes.
>
> I don't want to hold up 0.24.4 with a silly bug which no one apart
> from me really cares about, especially with such an easy workaround.

Okay, great.

>
> n.b.; is sub resources the correct term? Child resources?

I've been using 'contained resources', but I'm not willing to say
that's a good idea. Someone else came up with the term
'resource' (Digant, I think), so I fully realize the value of getting
help on terminology.

--
Seize opportunity by the beard, for it is bald behind.
-- Bulgarian Proverb

[Arjuna Christensen]

Will find and update the appropriate documentation in the a.m. The collect/export docs really need some love.

Regards,

AJ

Sent from my Windows Mobile® phone.

[David Schmitt]

On Tuesday 25 March 2008, Luke Kanies wrote:
> 1) Virtual/Exported defined resources get expanded into the component
> resources.

-1

> 2) Virtual/Exported defined resources do not get expanded.

+1

> * You can immediately export and collect defined resources.
> * Defined resources are a bit more like first-class objects.
> * You can't reach into the guts of a virtual defined resource and just
> realize a single resource; you have to treat the whole thing.

For all of these reasons.

Regards, DavidS

--
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
-- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking

[Paul Lathrop]

On Mon, Mar 24, 2008 at 7:57 PM, Luke Kanies <lu...@madstop.com> wrote:
> 1) Virtual/Exported defined resources get expanded into the component
> resources.

> 2) Virtual/Exported defined resources do not get expanded.

For what it's worth at this point, I think #2 is the best.

--Paul

[Luke Kanies]

And #2 it is.

Thanks for the feedback, everyone.

--
I can win an argument on any topic, against any opponent. People know
this, and steer clear of me at parties. Often, as a sign of their
great respect, they don't even invite me. -- Dave Barry

[Dan Hughes]

http://wikipedlla.com/virtual_definitions_what_39_s_the_correct_behaviour_1157
> Hi all, > Arjuna just filed #1157[1], which basically asks for an inverse of the &nbsp; > behaviour committed in #997[2]. > Basically, up until (I think) 0.24.3, if you had a defined resource &nbsp; > that was virtual (or exported, which is a superset), then the defined &nbsp; > resource would get expanded into a list of virtual resources. &nbsp;This &nbsp; > meant you could realize/collect individual resources from within the &nbsp; > definition, but it also meant that you couldn't collect defined &nbsp; > resources (because the definition itself isn't stored, only the &nbsp; > component resources, at least at this point). > This does introduce a potential race condition: > hostA exports a resource created with definition 1.0 > hostB collects that resource using definition 1.1 a bit later > This race condition wouldn't really exist if we expanded everything, &nbsp; > but it would be much harder to collect exported resources. > Here are the two choices I see, with the bits I can think of: > 1) Virtual/Exported defined resources get expanded into the component &nbsp; > resources. > * At least for now, you won't be able to collect defined resources, &nbsp; > although I expect we could add this ability eventually. > * Collects inside virtual definitions should also be made virtual, and &nbsp; > the should get evaluated if the defined virtual resource is realized. &nbsp; > This shouldn't be *too* much code, but it's at least &quot;some&quot;. > * You can realize just a part of a defined resource, rather than the &nbsp; > whole thing. > * Contained resources acquire defaults from the exporting host. > 2) Virtual/Exported defined resources do not get expanded. > * You can immediately export and collect defined resources. > * Defined resources are a bit more like first-class objects. > * You can't reach into the guts of a virtual defined resource and just &nbsp; > realize a single resource; you have to treat the whole thing. > * The above mentioned race condition, which can appear when the &nbsp; > exporting and collecting hosts are operating against different &nbsp; > versions of the configurations. > * Contained resources acquire defaults from the collecting host. > So, what do people think? > I'm leaning toward #2, which not so coincidentally is the current (and &nbsp; > thus easiest to implement) behaviour. > 1 - http://reductivelabs.com/trac/puppet/ticket/1157 > 2 - http://reductivelabs.com/trac/puppet/ticket/997 > -- > Basic research is what I am doing when I don't know what I am doing. > &nbsp; &nbsp; &nbsp;--Wernher von Braun > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com >