-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error from SL API: Unable to find image template #0. #58
Comments
Same issue here. Also have a ticket opened. Appears verifyOrder is not happy with the order template being generated by generateOrderTemplate (bad imageTemplateId in the generated template). |
Hi, if you can provide some debug output by setting VAGRANT_LOG=debug in environment variable it would help us figure out if theres something we need to fix here, in upstream, or pass it up to the SoftLayer API side. cc @SLsthompson looks like its an api bug for now. |
Debug output: https://gist.github.com/riethm/367a8339d13699fc183a |
Im trying to reproduce this using the upstream Can you provide the dump for us of your order template stripped of any confidential stuff as needed by doing the following:
|
Did you really mean to include the "pp" at the beginning of that line? I get:
So I took the liberty of adding this line instead:
But I didn't get any extra output. Sorry but I guess my Ruby isn't good enough. Let me know what else I can try. Thanks for your support.
|
Sorry, i thought that was automatically loaded with 2.x, add a require above the pp line:
|
Here it is:
Aside from the recurringFee (I changed all to 'xx'), this is verbatim |
Crap sorry, was looking for the pre converted order hash it should have been this:
|
Here's mine with a few "999999"s thrown in
|
How about this?
|
Or this?
|
Looks like you might have hit a validation bug on our end. You dont have |
It looks like the "imageTemplateId" field is assigned to the empty string:
If I had to guess I would say this is a variant of the problem where our XMLRPC interface is not able to handle "nil" values properly. |
That's what I get for doing 2 things at once, sorry.
|
Same for me:
|
We have a few machines using vagrant and this plug-in. It's worth noting that this was working fine on a brand new machine for the last week+ or so and then suddenly started giving this error somewhere between Wed. night and Thurs. morning of this week. |
@SLsthompson so our only solution would be not to pipe the Upstream you are just calling I guess Im not understanding how this would be an issue now and not before (since we have been on the XMLRPC for a while now with this like that). |
@poflynn, @riethm short term fix is probably just to comment out the order verification line for now (untested), I dont see anything wrong with the order options themselves aside for the validation bug we have to fix. Change it to:
|
verifyOrder can take a block that can change the template. You could add a block that strips out the offending empty field. Now that the REST interface handles Object Filters... in the long run we could switch all of the softlayer_api back to the REST interface (which does handle nil properly). I've also got an internal ask for the XMLRPC interface to support the extension that allows it to handle nil's properly, but that's having a bit of trouble bubbling up high enough in the priority queue. |
We are still using the service calls directly we havent migrated to the upstream |
OK so based on testing it is the XMLRPC issue with empty string but technically the bug is upstream in the API (im guessing it wants the equivalent of nil and not the empty string since when I delete the imageTemplateId it works, and thats consistent with the API turning the empty string into an int and getting template number 0). This also highlights a logic problem in upstream Regardless of the above, it also means something changed in the API this week for this to stop working now because we havent changed this code in months since we moved to XMLRPC. |
I tried to tell SL something must have changed in their API but as always you mention this plug-in and they just reply saying it is unsupported, which I'd expect them to say, but really IMO they should be bending over backwards to help you given the popularity of Vagrant. But I guess that's another battle for another day. I did send them the link to this issue BTW. Thanks again for your efforts. |
Par the course, which is why I was trying to do a minimal test without |
BTW, wanted to let you know that i also ran into this problem and found this thread via google. I'm a developer for Gateway as a Service for SoftLayer (https://gateway-as-a-service.com/) and as part of that we order virtual svr instances via the SL API python client. The situation is as you say: the generateOrderTemplate() method returns an order structure with 'imageTemplateId' as a key whose value is the empty string, and the verifyOrder() method can't seem to handle that. (Although the error has been on and off for the last several weeks, and i'm not sure why.) But the work around is easy: after calling generateOrderTemplate() to get the order structure, remove the imageTemplateId key from it before passing it to verifyOrder. |
The fundamental issue causing this is being looked at internally and a fix may be forthcoming. No timelines are available yet. |
It appears the fundamental issue is also breaking provisioning with image_guid. Bringing machine 'default' up with 'softlayer' provider... Exception class: XMLRPC::FaultException |
Howdy! We pushed out a release that should resolve this issue. @ju2wheels did some initial testing and it is looking good. Please try again and let us know if anything is wonky. |
It appears to work! Awesome, thanks everyone. |
Anyone seen this before? Our VagrantFile etc hasn't changed, I just fired up a new machine, installed latest vagrant, latest plug-in etc and am suddenly getting this error. The same VagrantFile continues to work fine on my old machine using slightly older versions of vagrant and this plugin. We are using an image provided by SL ("provider.operating_system = "CENTOS_5_64""), not a custom one.
Any thoughts? I also logged a ticket with SL,
Thanks,
Paul
The text was updated successfully, but these errors were encountered: