softlayer / softlayer-ruby

http://softlayer.github.io/softlayer-ruby/
MIT License
54 stars 35 forks source link

[new feature] VirtualServerOrder_Package analog to BareMetalServerOrder_Package #51

Closed ju2wheels closed 9 years ago

ju2wheels commented 10 years ago

Im currently looking at how we can expand vagrant-softlayer server creation to support all 4 server types:

Having a VirtualServerOrder_Package analog would allow us to easily provide all four, otherwise it would be a fair amount of work to do the advanced virtual server order.

SLsthompson commented 10 years ago

For the most part, ordering a virtual server by package is almost identical to what you see in BareMetalServerOrder_Package except that the package is 'fixed'.

To put it another way, there is nothing in BareMetalServerOrder_Package that is specific to ordering "bare metal" servers except the name, and the fact that it fixes the "useHourlyPricing" flag to be false (which I believe is a bug... we now offer hourly priced hardware).

Having a separate order class for Virtual Servers is a good suggestion and we can do that. But if you want to get started before someone can submit the change, you could, counter-intuitively, use the BareMetalServerOrder_Package class to order a virtual server :-)

Use the package returned by SoftLayer::ProductPackage.virtual_server_package. You may then pass a block to #verify and #place_order! and change the "useHourlyPricing" flag in that block (along with any other modifications to the order template you feel are necessary).

If you don't care for that approach, you could also use the "basic" ordering mechanism offered by VirtualServerOrder. What you'd have to do is put together some options using that class itself, then generate the more complete order template by calling #verify (the return value to verify should be a product order). With that in hand you can add additional price items (just as you have to do for a "regular" package order) then submit that order using SoftLayer_Product_Order::placeOrder.

Either of those mechanisms might serve as a convenient work around until we can create a dedicated class for Virtual Server package orders

ju2wheels commented 10 years ago

That works, we are already using the basic order mechanism but I dont see anything holding us back from adding the other order types which I think would be useful to have. When we order the bare metal (server or instance) is there any major difference process wise (ie do we have to wait for some sort of approval from SL side, differences in order completion time) compared to a virtual server order (just trying to think ahead in terms of waiting for the transaction completion for order)?

SLsthompson commented 10 years ago

You've stepped a bit outside of my knowledge base.

I know that often sales orders require approval from an actual person, but I'm not totally clear on when that is a required step. As far as I know individual customers can also make arrangements to have orders pre-approved... they would skip the step in that case.

In addition to sales order approval, some hardware orders are "stock" items (that might already be racked and ready to be assigned automatically) while others would require the build folks to get involved and install physical hardware into/onto the server.

I can tell you that I myself have not encountered the "concept" of having a script wait for a Bare Metal Server order to complete they way they often wait on Virtual Servers... but having said that my own experience with "real world" orders is pretty narrow :-)

SLsthompson commented 10 years ago

Ack! I am wrong. The BareMetalServerOrder package also includes the hostname and domain in the order template in a property called 'hardware' which is a hardware server template. Looks like my thoughts on ordering virtual servers with that mechanism is off by a tiny bit more than I thought.

ju2wheels commented 10 years ago

Hi Scott, if I were to submit a PR for this over the next week or two is it likely to be accepted and would it go into 2.x, 3.x or both since it looks like both branches are being maintained in parallel as 3.0 wasnt pushed to master this week.

SLsthompson commented 10 years ago

It would go into a 3.1 release

ju2wheels commented 9 years ago

@SLsthompson does the current implementation of the system allow for an image_template to be used as part of a package order for either BareMetalServerOrder_Package or the new VirtualServerOrder_Package? Trying to decide whether to port this feature from the generic VirtualServerOrder and add it to both.

Based on the containers which both have imageTemplateGlobalIdentifier im guessing it should work but the conflict comes with the configuration options os category being marked required. If we add imageTemplateGlobalIdentifier will it allow an order through without the os category? Otherwise this would be an interesting area where we would not be able to rebuild a machine from an image template while still using the advanced ordering config options to restore it to the way it was.

SLsthompson commented 9 years ago

My understanding is that you can either provide an 'os' category selection OR an imageTemplate. But I cannot say that I've carefully tested that.

What you might do is try using the VirtualServerOrder class and providing an image template to it. I believe the verify method will return a fully constructed order template (just as should be sent to SoftLayer_Product_Order::placeOrder). Inspect that template and see how the image template is incorporated. That should be the same way a VirtualServerOrder_Package would provide it.

(hint just typed into github... once I get a chance I'll try it myself).

ju2wheels commented 9 years ago

Testing that worked ok, im closing. Thx for the input.