4 ms·

No, there is no caveat; we're working on openstack first, then rackspace, then others. It's just started out obviously. We examined goose/juju and preferred to

by jnoller 13y ago

No, there is no caveat; we're working on openstack first, then rackspace, then others. It's just started out obviously. We examined goose/juju and preferred to approach this via the Apache 2 license ala all of the other tooling/SDKs out there we (Rackspace) support and assign developers to. Yes, it is currently focused on openstack clouds, but the goal is to reach parity with Fog (ruby), jclouds (Java), Libcloud (Python), pkgcloud (node.js), and so on. The focus is a series of clean abstractions for users to be able to build tools and programs which can talk across any cloud provider easily using a common set of names / abstractions.

kapilvt 13y ago
ic. Probably worth updating the readme then atm its got "Gophercloud provides a Go binding to OpenStack cloud APIs." fwiw. goose is LGPL. I'm at a bit of a toss up re LCD between clouds vs exposing the underlying functionality of the clouds. The LCD apis (libcloud from experience) break down with real world usage even for simple things like net security groups, or zones spec into provider specific usage. It seems like most cross cloud apps ends up needing to redefine the abstraction layer within itself rather than attempting to reuse the same LCD code across clouds at which point its not clear that the LCD layer isn't a limitation to taking advantage of a native cloud functionality.
- jnoller 13y ago
  Thanks! I'll take care of it or file an issue. As for GPL vs LGPL - I am aware, but given the goals of not focusing on openstack solely and also that all of our other work is Apache 2 for maximum flexibility and freedom, we currently prefer this approach. The LCD issue is being resolve in libcloud - we have multiple FT devs working on it right now, and does not come up as an issue with Fog, jclouds, or pkgcloud. It's possible to make an abstraction that is simple enough to start but powerful enough to access the advanced features of each individual cloud host. I hope users and consumers will keep us honest - as we said in the post, our interest is pretty much no lock-in on an API level (hence: openstack) and no lock-in on the code level. We really want to make tools that allow our users and others to fluidly move between hosts.
- tomazmuraus 13y ago
  (disclaimer: I'm one of the Libcloud developers) I want to add some context to this. Our current abstraction provides a relatively simple API which is guaranteed to work across multiple providers. If you want to access provider specific functionality we offer so called extension methods and arguments. This is similar to how jclouds and other cross-provider libraries handle that as well. We support over 30 providers and for the more popular ones this means you can usually access most of the native cloud functionality through the base API + extension methods. Doing that will obviously make it harder and more work to switch between different providers so we always put up a disclaimer and make sure our users are aware of that. We are trying to standardize as many APIs as possible and promote extension methods to the to top level API (proposals and patches are always very welcome and appreciated!), but sadly in a lot of cases this is not possible. Usually this is because the provider APIs are too different and the glue code needed to make it work would be to complex. In the end it's a trade-off, pretty much like everything else in life and a lot of other things in CS (CAP anyone?). If you want good portability and easily switch between providers you will stick to the base API. If you don't care so much about the portability you will also use the extension API. Side note: Even though official provider client libraries exists, a lot of people still tend to use Libcloud with extension methods. Usually the reason is that we support a variety of Python versions and we have a stricter testing policy which tends to result in less buggy code.
  - kapilvt 13y ago
    afaics this only reinforces the use case for just using the underlying native client lib. istm the only portable cloud usage for libcloud is its original use case, read only access for cloudkick monitoring. In some cases its the only decent py lang binding to a given cloud provider and its been great to watch libcloud grow over the years as an apache project that providers target. But the reality check is as an app developer you can get over 90% public cloud marketshare with 3 cloud providers (ec2, openstack, vmwware), and maybe toss in a virt provider masquerading as cloud (ala linode, dotcloud) to get to 95. Given that your extending a from scratch client in libcloud and your abstracting it in an app code base, for most of those you could just go with a native cloud provider and get more functionality. ie. take saltstack's saltcloud as an example of a heavy user of libcloud, they had to create a utility library, and still ended up with 1k lines per cloud of specific code just for something as simple as launching an instance (no volume management, no security group management) just launching an instance. that line count would have dropped and they would have access to more features if they would have just used native cloud libs, if they were willing to grow the per cloud dep. anyways, thats the tradeoff of an lcd library afaics.
kapilvt 13y ago
sorry.. i couldn't let this go.. how is that not a huge caveat? your advocating and advertising for something that doesn't exist, and that does its existing job worse than other options.. ie a better alternative openstack client lib in go that focuses on openstack. i have huge amount of respect for you from pycon, and maybe this is your first rackspace advocacy... but sigh, all this is a call for developers afaics to work on a vaporware project afaics (going by the standard you set of multicloud). you haven't addressed my example of net security groups and how their elegantly solved by a generic lcd library.. because the fact is rackspace has no net security options in their cloud api, and really its incredibly cloud specific, i'm not talking about passing an a k/v for instance creation but actually configuring security groups (ports, etc), which is pretty basic stuff for a cloud provider. "I hope users and consumers will keep us honest - as we said in the post, our interest is pretty much no lock-in on an API level (hence: openstack) and no lock-in on the code level." any api is a lock-in, openstack just happens to be opensource in implementation, but per google v. oracle, there doesn't seem to be any qualms in other opensource impls using the amazon apis (cloudstack, eucalyptus) to deliver what customers want without lock-in.

by jnoller 13y ago

kapilvt 13y ago

ic. Probably worth updating the readme then atm its got "Gophercloud provides a Go binding to OpenStack cloud APIs." fwiw. goose is LGPL. I'm at a bit of a toss up re LCD between clouds vs exposing the underlying functionality of the clouds. The LCD apis (libcloud from experience) break down with real world usage even for simple things like net security groups, or zones spec into provider specific usage. It seems like most cross cloud apps ends up needing to redefine the abstraction layer within itself rather than attempting to reuse the same LCD code across clouds at which point its not clear that the LCD layer isn't a limitation to taking advantage of a native cloud functionality.

jnoller 13y ago
Thanks! I'll take care of it or file an issue. As for GPL vs LGPL - I am aware, but given the goals of not focusing on openstack solely and also that all of our other work is Apache 2 for maximum flexibility and freedom, we currently prefer this approach. The LCD issue is being resolve in libcloud - we have multiple FT devs working on it right now, and does not come up as an issue with Fog, jclouds, or pkgcloud. It's possible to make an abstraction that is simple enough to start but powerful enough to access the advanced features of each individual cloud host. I hope users and consumers will keep us honest - as we said in the post, our interest is pretty much no lock-in on an API level (hence: openstack) and no lock-in on the code level. We really want to make tools that allow our users and others to fluidly move between hosts.
tomazmuraus 13y ago
(disclaimer: I'm one of the Libcloud developers) I want to add some context to this. Our current abstraction provides a relatively simple API which is guaranteed to work across multiple providers. If you want to access provider specific functionality we offer so called extension methods and arguments. This is similar to how jclouds and other cross-provider libraries handle that as well. We support over 30 providers and for the more popular ones this means you can usually access most of the native cloud functionality through the base API + extension methods. Doing that will obviously make it harder and more work to switch between different providers so we always put up a disclaimer and make sure our users are aware of that. We are trying to standardize as many APIs as possible and promote extension methods to the to top level API (proposals and patches are always very welcome and appreciated!), but sadly in a lot of cases this is not possible. Usually this is because the provider APIs are too different and the glue code needed to make it work would be to complex. In the end it's a trade-off, pretty much like everything else in life and a lot of other things in CS (CAP anyone?). If you want good portability and easily switch between providers you will stick to the base API. If you don't care so much about the portability you will also use the extension API. Side note: Even though official provider client libraries exists, a lot of people still tend to use Libcloud with extension methods. Usually the reason is that we support a variety of Python versions and we have a stricter testing policy which tends to result in less buggy code.
- kapilvt 13y ago
  afaics this only reinforces the use case for just using the underlying native client lib. istm the only portable cloud usage for libcloud is its original use case, read only access for cloudkick monitoring. In some cases its the only decent py lang binding to a given cloud provider and its been great to watch libcloud grow over the years as an apache project that providers target. But the reality check is as an app developer you can get over 90% public cloud marketshare with 3 cloud providers (ec2, openstack, vmwware), and maybe toss in a virt provider masquerading as cloud (ala linode, dotcloud) to get to 95. Given that your extending a from scratch client in libcloud and your abstracting it in an app code base, for most of those you could just go with a native cloud provider and get more functionality. ie. take saltstack's saltcloud as an example of a heavy user of libcloud, they had to create a utility library, and still ended up with 1k lines per cloud of specific code just for something as simple as launching an instance (no volume management, no security group management) just launching an instance. that line count would have dropped and they would have access to more features if they would have just used native cloud libs, if they were willing to grow the per cloud dep. anyways, thats the tradeoff of an lcd library afaics.

kapilvt 13y ago

sorry.. i couldn't let this go.. how is that not a huge caveat? your advocating and advertising for something that doesn't exist, and that does its existing job worse than other options.. ie a better alternative openstack client lib in go that focuses on openstack. i have huge amount of respect for you from pycon, and maybe this is your first rackspace advocacy... but sigh, all this is a call for developers afaics to work on a vaporware project afaics (going by the standard you set of multicloud). you haven't addressed my example of net security groups and how their elegantly solved by a generic lcd library.. because the fact is rackspace has no net security options in their cloud api, and really its incredibly cloud specific, i'm not talking about passing an a k/v for instance creation but actually configuring security groups (ports, etc), which is pretty basic stuff for a cloud provider. "I hope users and consumers will keep us honest - as we said in the post, our interest is pretty much no lock-in on an API level (hence: openstack) and no lock-in on the code level." any api is a lock-in, openstack just happens to be opensource in implementation, but per google v. oracle, there doesn't seem to be any qualms in other opensource impls using the amazon apis (cloudstack, eucalyptus) to deliver what customers want without lock-in.