I don't think I get your point. If you just created the resource inside your
create method, you should already now the status of the resource - you created it.
In general puppet syncs all properties, which means it will run the getter and setter commands for each property. One exception to that rule (as you noticed) is the
ensure property which will always be the first one to be checked (by running the
exists? method of your provider). If this is out of sync (the resource is absent but you want it to be present / the resource is present but you want it to be absent) the
destroy method of your provider is executed and nothing else. Puppet will just expect that if you destroyed a resource there is no point in checking any remaining properties and if you just created a resource, you'll create the resource in the desired state right away.
If you take the user provider for example: To create a user you should run
useradd in a way that uid, gid, groups etc are already set up correctly and there is no point to run any
There are only a few exceptions to the rule that don't fit into this pattern and the mount type comes to mind. Here a change form
mounted is realized by running
mount /foo, but this does not fix any incorrect entries in
/etc/fstab. So inside the mount type you will find a really ugly hack that syncs all other properties from within the ensure property. That's not a good idea and probably means your
ensure property is bad designed.
Can you point us to some sample code or at least explain what your custom type is about?