Decision: move to fog-softlayer?

[emyl]

IMHO moving from SL API client to fog-softlayer could be worthwhile:

PROS

• Support for bare metal instances baked in
• A well tested higher-level library (so less code to maintain)
• Open up the road to a full test suite to be written with the help of vagrant-spec

CONS

• Load balancer support missing (but it's in the roadmap)
• A lot of work to do 😄

@ju2wheels WDYT? I could start working on a fog branch in the next weeks, in the event that it is worthwhile for you too.

[ju2wheels]

I like the simplified interface a lot. But my biggest concern/con with this is its feature level compared to what is offered with SL API.

Looking at this, a lot of work is a bit of an understatement when you compare what it offers to what we currently use and may potentially want to use based on the other milestone discussion thread. A few of the the missing items that jump out at me are the following:

1. No interface for waiting for virtual server order/transaction completion (probably wont be needed at all with the bare metal).
2. No load balancer support as you stated.
3. No support for the other categories supported by the bare metal and virtual server advanced order functionality (which for my clients at least will be important to customize things like monitoring, a/v software, notifications etc).
4. No interface or abstraction models for accessing the categories/items available for products for developing vagrant-softlayer-productpackage tool or similar end user aid.

If we can come up with fog models for these things and not be at risk of trading SL API's functionality for added development of fog-softlayer just for the sake of a simplified interface and still not being up to par with SL API, then im all for the transition and willing to help where I can.

[ju2wheels]

@emyl : just want to touch basis regarding our last conversation, hoping you have had a chance to review the other topic on direction. Would you like to move forward with fog-softlayer or continue with softlayer_api just to get the features out the door and come back to fog-softlayer once it has similar features?

If we move to fog-softlayer then we would scrap the 2.x migration branch and we wouldnt be able to replace the timeout functionality unless fog has a builtin timeout feature for calls (I didnt see any specifically in fog-softlayer but in this fog patch theres a reference to Fog.timeout so it may be builtin but i havent looked further: chris-maginatics/fog@07ce84f#diff-0cb327cd048d944b77e791db03dec94cL52 ).

Regardless of which direction, I think we should backport the wait_until_ready code from softlayer_api into vagrant-softlayer as the last fix for a known issue in 0.3.x branch and start the chosen new direction as 0.4 or 1.0 .

@irifed : theres nothing really holding that PR back from technical perspective, although I can currently merge the branch I was waiting on direction from this thread as it would change the implementation if we go with fog-softlayer (and wouldnt make sense to merge it if we are changing to that).

[emyl]

Well, I'm still convinced that fog should be the right way to, but as we've pointed out it is defintely too young.

@ju2wheels: The roadmap you proposed sounds very good to me, so to summarize:

version 0.3.4: backport wait_until_ready
version 0.4.0: bump to SL API 2.x
sooner or later: fog

@ju2wheels, please let me know if you'd like to work yourself to wait_until_ready or if you prefer me to do it 😉

[ju2wheels]

I can have the pushed by the weekend, working on some work stuff at the moment.

Ill see if I can talk to the lead fog-softlayer developer (I think he is a fellow IBMer) and get his thoughts on fog-softlayer direction and implementing some of the functionality we need there.

[emyl]

👍

[ju2wheels]

Will have this pushed in a few hrs.

0.4.0 will push to 3.x API instead of 2.x as this was just released (I had done testing with it before it hit beta and it was working ok with the 2.x changes and we dont use any of the actual new 3.x features at this point) and is where the addons for virtual server package order will land (softlayer/softlayer-ruby#51). This will avoid having to bump it again when we are ready.