Implementations become Providers
After
discussions,
I've changed implementations to providers. This makes it easy to talk
about them:
package { ssh:
provider => rpm,
ensure => installed
}
And the class names and instance variables all become pretty easy, too.
I've been making significant progress in the work, but as I get closer to completion, I see more and more parts of Puppet that are now code and should instead be data. For instance, unless I change things some, all of my User states will look something like this:
newstate(:gid) do
def retrieve
@is = provider.gid
end
def sync
provider.gid = self.should
return :user_changed
end
end
That's basically silly. Sure, I can make a base class for User states, so
that I don't have to repeat within that one class, but that's still all
basically data disguised as code. I think I've got a way to be able to trim
it down the basics -- the state will assume that the retrieve method is named
after the state, so it knows to call provider.gid in this case, and the
sync method will be basically the same.
Of course, User is a bit weird in that basically all of the states have essentially infinite valid values. Packages, on the other hand, have a fixed list of valid values, basically:
newstate(:ensure) do
newvalue(:installed) do
provider.install
return :package_installed
end
newvalue(:absent) do ... end
newvalue(:latest) do ... end
end
I should be able to change that code to something like this:
newstate(:ensure) do
newvalue(:installed, :event => :package_installed, :method => :install)
newvalue(:absent, :event => :package_removed, :method => :uninstall)
newvalue(:latest, :event => :package_upgraded, :method => :upgrade)
end
Notice that I have the exact same information here, but it's now all presented as data.
I don't know that this is the best long-term option, and it's not quite this rosy since some methods need values and some don't, but this is what I'm searching for, anyway.
Thu, 10 Aug 2006 | Tags: puppet, providers, naming