search

audiolize / vagrant-softlayer

This is a Vagrant plugin that adds a SoftLayer provider to Vagrant, allowing Vagrant to control and provision SoftLayer CCI instances.
MIT License
42 stars 15 forks source link

Decision: move to fog-softlayer? #30

Open emyl opened 9 years ago

emyl commented 9 years ago

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

PROS

CONS

@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 commented 9 years ago

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 commented 9 years ago

@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: https://github.com/chris-maginatics/fog/commit/07ce84f9907213c0b30f3eef7bf701ea564057d4#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 commented 9 years ago

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 :wink:

ju2wheels commented 9 years ago

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 commented 9 years ago

:+1:

ju2wheels commented 9 years ago

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 (https://github.com/softlayer/softlayer-ruby/issues/51). This will avoid having to bump it again when we are ready.