Add support for operation headers about puppet-wildfly HOT 5 CLOSED

👍

That's very interesting. It opens a door for a lot of possibities.

Management API docs used to be really shallow when I started writing this module. Always had to write something in CLI and convert to HTTP API syntax, even had to investigate Management Console interactions with HTTP API to better understand this...

Do you think we should have a custom type that supports plain JSON requests? So people could tests commands using HTTP API before using it in the module.

from puppet-wildfly.

I'm not sure. I'm leaning on two different thoughts regarding this:

• it would be nice to have this as a 'last resort' type to get things done with the module even when there's no specific type for it (this is what I actually use wildfly::util::resource for right now)
• on the other hand this would be the exec type of Wildfly. And I think using exec is bad. Well, at least 99% of the time... An exec can always be replaced with a custom type.

What do you think @jairojunior?

from puppet-wildfly.

It's nice when you automate a task and are able to easily transport it to Puppet, but as you suggested, we should stick the simple for now.

Let's just introduce a new parameter for operation headers in our custom types.

👍

from puppet-wildfly.

Operation headers are now supported with the new CLI Parser implemented in v1.0.0 branch and it should work for wildfly_cli. Just need to introduce this parameter for wildfly_resource and wildfly_deployment.

Not sure whether should use CLI syntax:

wildfly_resource { '/resource=name':
  operation_headers => '{header1=value;header2=value}'
}

Or a typed alternative which I would be able to validate headers name:

wildfly_resource { '/resource=name':
  operation_headers => {'rollback-on-runtime-failure' => false}
}

from puppet-wildfly.

Done for wildfly_resource and wildfly_deployment and its wrappers. Tested for wildfly_cli using {header1=value;header2=value} syntax.

from puppet-wildfly.