Puppet: System Administration Automated

Support

Ticket #466 (new enhancement)

Opened 2 years ago

Last modified 7 months ago

Relationships to abstract resources

Reported by: ianburrell Assigned to: luke
Priority: normal Milestone:
Component: language Version:
Severity: normal Keywords:
Cc: Triage Stage: Needs design decision
Attached Patches: None Complexity: Hard

Description

It would be nice if resources could declarate a virtual resource that other one depends on. For example, an exec should require the binary but the exec resource should not care where the binary is coming from. It could come from a package then the exec needs to require the package name. Or it could from a remote file or some other definition. It would be nice if the source of the binary could provide a virtual resource that the exec requires. This would give some abstraction.

I see two ways to implement the virtual resources. One is to have a special virtual type which is only used for the virtual provides. This keeps them in a separate namespace which does not interfere with other types. 

package { "stow":
  provides => "/usr/local/bin/stow"
}

exec { "/usr/local/bin/stow":
  require => Virtual["/usr/local/bin/stow"]
}

The other is to have the provides parameter make virtual resources of any type. This allows it to satisfy automatic requires. 

package { "stow":
   provides => File["/usr/local/bin/stow"]
}

exec { "/usr/local/bin/stow":
  requires => File["/usr/local/bin/stow"]
}

In this case, it might be nice to have a virtual parameter for declaring resources as virtual.

Change History

01/30/07 03:41:50 changed by luke

I expect I would implement this using something akin to aliases. That is, if one resource "provided" a virtual resource (e.g., a package providing a file), then the internal file map would get modified to return the package when the file was asked for.

This shouldn't be too problematic because resources are normally entirely decoupled, but it could possibly do some weird things if something internal assumes that when we ask for a file we actually get a file.

It might be a better idea to have something special in the sorting process that only uses the virtual (we can't actually use this term because it's already in use) resources when sorting, and possibly when event handling, but does not actually return the resources from the internal File[] method.

04/05/07 22:39:09 changed by luke

  • specification set to None.
  • patch set to None.
  • complexity set to Hard.
  • approval set to Unnecessary.
  • compatibility set to Unknown.
  • stage set to Needs design decision.

06/18/07 23:04:43 changed by luke

  • summary changed from Virtual provides to Relationships to abstract resources.

Changing the name of the ticket to provide more information.

04/24/08 07:38:15 changed by luke

  • component changed from library to language.

05/02/08 23:27:40 changed by ianburrell

I think the first suggestion of a type that is just a name and doesn't have any behavior would solve problems without introducing much complexity. If virtual is already used, would "abstract" work for a type name?

I could see a special "provides" parameter that worked like this: 

package { "stow":
  provides => "/usr/local/bin/stow"
}

Would be equivalent to: 

package { "stow":
  
}
virtual { "/usr/local/bin/stow": requires => Package["stow"] }