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

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.