4 ms·

I think it's a noble effort, but I'd be strongly concerned with the ease of use/digestion/maintainability of something that strives to cover most major cloud AP

by gtaylor 13y ago

I think it's a noble effort, but I'd be strongly concerned with the ease of use/digestion/maintainability of something that strives to cover most major cloud APIs. This stuff moves fast, and I can't imagine having to try to keep up with multiple larger platforms. While we were getting Pathwright launched, we contributed a whole lot to boto, which is primarily (but not exclusively) catered to AWS. It grew Eucalyptus (not a huge jump) and Google Compute support, but they were badly documented/tested and still seem to see much less maintenance than the AWS stuff. The situation has improved slightly as Amazon has hired a few more guys to help the maintainer make boto awesome, but they're still playing catchup with the core competency (AWS). This isn't to talk badly of boto, it's more to illustrate the magnitude of the task of keeping up with even one aggressively developing vendor. I worry that these "mega-cloud-libs" are the wrong approach. The OpenStack stuff will probably end up with excellent support, but the others are likely to see much less attention, documentation, maintenance, help. The neglected areas of the codebase get to be embarrassing and not up to the quality standards of the primary focus (OpenStack in this case). Perhaps they end up falling behind in API versions for some vendors, limiting their utility. This is definitely not to poo-poo the effort, I think it's a really neat ideal. Personally, I'd love to see them focus on making a kick ass OpenStack Go API with top notch documentation and tests, and leave the other services to their respective communities. That alone would be noteworthy.

jnoller 13y ago
Thank you for the feedback - there is definitely a risk of lowest common denominator, and some truth that a generalized toolkit won't be as "good" as a domain-specific tool. For openstack specifically there's goose/juju right now. We (rackspace) have had great success with Fog, jclouds, pkgcloud, libcloud, and other multi-cloud toolkits. For openstack / Rackspace cloud we also have php-opencloud, openstack.net and pyrax (which uses the python-XXXX clients from openstack core). It definitely is a fine line to walk; a good abstraction though means that you can use the most common features easily and float through providers, but you have access to the advanced features if you need or want them. Commonly those advanced features (on a provider level) mean a greater level of vendor lock-in which is why they may not make sense to expose in the higher level abstraction.
kc5tja 13y ago
I'd also like to point out that having a base-line level of functionality often allows for domain-specific extensions to be written, either as adjunct libraries (c.f., libcloud and rackspace-monitoring libraries for Python), or as integrated extensions in succeeding versions (how Emacs evolved over time). You're right to think it's impossible to keep up; even getting this far, I've heard rumors and tremors about up-coming V3 APIs in several areas. I'm sure by the time V3 support is contributed, V4 will be on the drawing board. Thankfully, the general availability of a V3 API does not usually preclude the continuing support for V2. All we can do is deliver value to our users in a consumable format while trying to remain aware of any changes in our ecosystem.

by gtaylor 13y ago

jnoller 13y ago

Thank you for the feedback - there is definitely a risk of lowest common denominator, and some truth that a generalized toolkit won't be as "good" as a domain-specific tool. For openstack specifically there's goose/juju right now. We (rackspace) have had great success with Fog, jclouds, pkgcloud, libcloud, and other multi-cloud toolkits. For openstack / Rackspace cloud we also have php-opencloud, openstack.net and pyrax (which uses the python-XXXX clients from openstack core). It definitely is a fine line to walk; a good abstraction though means that you can use the most common features easily and float through providers, but you have access to the advanced features if you need or want them. Commonly those advanced features (on a provider level) mean a greater level of vendor lock-in which is why they may not make sense to expose in the higher level abstraction.

kc5tja 13y ago

I'd also like to point out that having a base-line level of functionality often allows for domain-specific extensions to be written, either as adjunct libraries (c.f., libcloud and rackspace-monitoring libraries for Python), or as integrated extensions in succeeding versions (how Emacs evolved over time). You're right to think it's impossible to keep up; even getting this far, I've heard rumors and tremors about up-coming V3 APIs in several areas. I'm sure by the time V3 support is contributed, V4 will be on the drawing board. Thankfully, the general availability of a V3 API does not usually preclude the continuing support for V2. All we can do is deliver value to our users in a consumable format while trying to remain aware of any changes in our ecosystem.