I'll echo what Noah said. Backwards compatibility is maintained but new
features and API's are constantly evolving and being added. The issue with
any Cloud platform is that all API clients need to be updated frequently in
order to maintain state with the current platform. Things like Terraform
will therefore have frequent updates. Sometimes, maintaining a package
update schedule (like every 3 months) is good enough however. This is the
same problem we talked about in the Debian Cloud sprints as it relates to
Cloud guest software such as cloud-init or the Linux guest daemon's for GCE
or Azure.

-----
Zach

On Thu, Jun 21, 2018 at 4:37 PM Noah Meyerhans <[email protected]> wrote:

> On Thu, Jun 21, 2018 at 10:03:32PM +0200, Thomas Goirand wrote:
> > I have to admit I don't know a lot about proprietary apis. But as for
> > OpenStack, APIs are quite stable, and (almost?) always backward
> > compatible thanks to API micro-versions and auto-discoverability. In
> > fact, I haven't found yet an example of something that broke API
> > backward compatibility.
> >
> > Do we see such breakage often in AWS / Azure / GCE? I'm amazed to read
> > this, really. How come customers aren't complaining about this then?
>
> No, AWS is extremely disciplined about maintaining backwards
> compatibility. I imagine GCE and Azure are the same. The issue is that
> new APIs are being added *all the time* by all the providers supported
> by terraform. You could certainly package it, but IMO it's not really
> worth including in stable because it would lag so far behind. Even
> maintaining packages for unstable and stable-backports would amount to
> running on a treadmill.
>
> Consider the terraform AWS provider:
> https://github.com/terraform-providers/terraform-provider-aws/releases
> It has a release on a weekly basis. GCE and Azure are bi-weekly:
> https://github.com/terraform-providers/terraform-provider-google/releases
> https://github.com/terraform-providers/terraform-provider-azurerm/releases
>
> I'm not at all opposed to having these packages easily available, but I
> see it being a lot of work and a generally thankless job.
>
> noah
>
>

Reply via email to