On Fri, 2011-05-13 at 02:49 -0400, Mo Morsi wrote:
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.
Yeah, that seems to be the case, but I can't find where the docs state
that, nor where in the puppet code this happens :-)
> 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.
Cool. ACK to both patches, they look good to me.
>>> 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.
It moved recently - see 75533078651 in conductor.git
Shouldn't be the cause of that backtrace tho, is there something
non-conventional about your env?
Not that I can think of, I'll dig into it further soon
Cheers,
Mark.