On 05/11/2011 06:04 AM, Mark McLoughlin wrote:
>> I'm a bit surprised to see all this happening in
http_method=
>>
>> Care to explain why, just for my own education? :)
>
>
> Sure. When it comes to puppet resource types and providers you can only
> perform operations in properties, for example in the 'service' provider
> type, setting the 'ensure' property to 'running' will invoke
'service
> <name> start', while setting the 'enable' property to
'true' will invoke
> 'chkconfig <name> on'.
>
> Honestly wasn't sure what the best name for the property to actual
> perform the operation in in this case, if you have a better suggestion
> than 'http_method', I'm all ears.
Okay, after reading a bit more I'm starting to grok it :)
I'm still struggling to convince myself that we can be sure all the
resource parameters are set before the http_method property is assigned
to - i.e. that @resource[:uri] is guaranteed to be set before
http_method= is called.
This occurs because uri is a property where as http_method is a
parameter. Properties are set before the parameter methods are invoked.
Also, maybe in this case a property assignment isn't the best
interface
between the resource type and the provider - we can define any interface
we like and do e.g.
newproperty(:http_method) do
...
newvalue(:get) do
provider.get
end
newvalue(:post) do
provider.post
end
end
Dunno, just an idea
Actually a good idea, like it alot, simplifies the interface a bit and
makes it more intuitive. Sent a follow up patch to the list doing this.
>> Would something like this be better:
>>
>> unless => { http_method => 'get',
>> uri =>
'https://localhost/conductor/admin/providers',
>> parameters => { 'q' => $name },
>> verify =>
".*/admin/providers/.*>$name</a>.*" }
>>
>> i.e. run a search query and use a more specific regexp?
>
> Well it actually does run a search query as is right now. And the nice
> thing is that we can set the regex to whatever we want to look for in
> the aeolus-configuration recipe without modifying the backend web
> provider itself.
>
> At some point though I would like to expand this to not only be able to
> supply a regex but an xpath location at which that regex should appear.
I just mean that, in order to check whether a provider exists, we could
limit the providers returned by the GET using the q=$provider_name query
parameter and tighten up the regexp to match the HTML provided
Since the method is 'get' in this case the parameters will be appended
onto the end of the uri by the web provide, thus it should currently
only be returning the one (the regex check is performed since currently
a http status 200 will be returned regardless if the provider exists or not)
It sounds like we're going to have an XML and JSON REST API for this
stuff, though, which would make this much less error prone
Agreed, that will be ideal.
>> Also, now that I type that ... it looks like "unless" doesn't
re-use the
>> web type, right? i.e. parameters are automatically provided? It'd be
>> cool if it re-used the same type somehow
>
>
> It does reuse the web type. You can specify the parameters as you
> suggested as is right now.
Hmm, I don't see that:
+ if @resource[:unless]
+ result = web_request(@resource[:unless]['http_method'],
i.e. if you add a new parameter to the web type, it isn't automatically
available to use in unless clauses
(Again, what you have is fine - I'm just trying to understand puppet
better)
Ah ya misunderstood. This would be tricky todo as there isn't
necessarily an overlap between the two request parameters (sure not
impossible tho if we really wanted to)
>>
>> Without 'Accept: text/html', I'm seeing:
>>
>> The error occurred while evaluating nil.[]):
>> app/controllers/admin/hardware_profiles_controller.rb:206:in
`build_hardware_profile'
>> app/controllers/admin/hardware_profiles_controller.rb:14:in `index'
>> app/controllers/admin/hardware_profiles_controller.rb:11:in `index'
>> compass (0.10.4)
lib/compass/app_integration/rails/actionpack2/action_controller.rb:7:in `process'
>>
>> i.e. it's following the "format.js" path and breaking. Is that a
>> conductor bug?
>>
>
> Not fully sure what the issue your describing here. Do we need to
> specify this additional header in the request for this to work? How does
> format.js play into this?
>
> It seemed to be fully working when I tried it out, not sure what the
> difference between our environments is. If there is an error in the
> conductor logs due to this request, I'm tempted to say its an issue on
> that side (since the request looks like it should be valid). We'll need
> to debug this further tho.
Yep, I think there's an issue on the conductor side
Compare the result of:
$> /usr/bin/curl -H 'Accept: text/html' -b /tmp/aeolus-admin.cookie
http://localhost:3000/conductor/hardware_profiles
to:
$> /usr/bin/curl -b /tmp/aeolus-admin.cookie
http://localhost:3000/conductor/hardware_profiles
The backtrace above is the error I see with the latter
Ah hrm, think you're url is incorrect, it should be
http://localhost:3000/conductor/admin/hardware_profiles. Shouldn't be
the cause of that backtrace tho, is there something non-conventional
about your env?
-Mo