Re: Packaging terraform?
On Thu, Jun 21, 2018 at 04:30:38PM -0400, Noah Meyerhans wrote: > 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. Alternatively, terraform itself could be packaged, but not the provider binaries. By default, it will download the providers. I don't know of any easy way to force terraform to use system-installed provider binaries anyhow. Maybe not ideal, but also not that different from the situation with maven, pip, golang, etc. I'm not sure there'd be much benefit though. Ross
Re: Packaging terraform?
>From my experience it's much healthier for the stability of your infra to gradually update the version of ansible you're using to manage it, rather than trying to use a dramatically new version of ansible infrequently. Just because there's less room for error in small compatibility changes your playbooks when compared to large ones. On Fri, Jun 22, 2018, 7:46 AM Georg Faerber wrote: > Hi, > > On 18-06-21 07:06:35, Paul Dejean wrote: > > Oh I'd also like to add, for a practical example of such a noob trap, > > see the ansible package (which I wouldn't recommend using). > > Could you please elaborate on that? > > Cheers, > Georg >
Re: Packaging terraform?
Hi, On 18-06-21 07:06:35, Paul Dejean wrote: > Oh I'd also like to add, for a practical example of such a noob trap, > see the ansible package (which I wouldn't recommend using). Could you please elaborate on that? Cheers, Georg signature.asc Description: Digital signature
Re: Packaging terraform?
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 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 > >
Re: Packaging terraform?
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
Re: Packaging terraform?
On a different note, I'm guessing that because Go programs encourage libraries to be bundled in, they a pita to package. Either you break from upstream and compile them dynamically linked, which is a compatibility nightmare. Or you statically compile the package like upstream does, which is a security nightmare (because rather than just security patching the library you need to security patch everything that has that library statically compiled in). I'm really just guessing though, but the presumption is that debian wouldn't throw up their hands on docker (which btw is kinda a big deal now) without good reason. On Thu, Jun 21, 2018, 3:03 PM Thomas Goirand wrote: > On 06/21/2018 01:57 PM, Paul Dejean wrote: > > Because terraform interfaces with proprietary apis usually, it needs to > > be updated more often than stable is updated to be useful. > > 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? > > Cheers, > > Thomas Goirand (zigo) > >
Re: Packaging terraform?
On 06/21/2018 01:57 PM, Paul Dejean wrote: > Because terraform interfaces with proprietary apis usually, it needs to > be updated more often than stable is updated to be useful. 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? Cheers, Thomas Goirand (zigo)
Re: Packaging terraform?
Oh I'd also like to add, for a practical example of such a noob trap, see the ansible package (which I wouldn't recommend using). Stability is mainly useful on software that you run on production, rather than software you use for setting up production. So for instance I'd love for a docker package to be a thing in stable, but you don't always get what you want in life. On Thu, Jun 21, 2018, 6:57 AM Paul Dejean wrote: > Because terraform interfaces with proprietary apis usually, it needs to be > updated more often than stable is updated to be useful. > > So while it may (or may not, i dunno all the details) be technically > allowed and possible. A terraform package in stable would be something of a > noob trap. > > On Thu, Jun 21, 2018, 3:27 AM Bastian Blank wrote: > >> On Thu, Jun 21, 2018 at 09:45:27AM +0200, Thomas Goirand wrote: >> > Has any of you ever tried terraform, and would it be worth packaging? >> > Should this go in the cloud team as well? Any volunteer? >> >> You mean: Terraform and the providers? I don't think you want to open >> that pit. >> >> Bastian >> >> -- >> Without facts, the decision cannot be made logically. You must rely on >> your human intuition. >> -- Spock, "Assignment: Earth", stardate unknown >> >>
Re: Packaging terraform?
Because terraform interfaces with proprietary apis usually, it needs to be updated more often than stable is updated to be useful. So while it may (or may not, i dunno all the details) be technically allowed and possible. A terraform package in stable would be something of a noob trap. On Thu, Jun 21, 2018, 3:27 AM Bastian Blank wrote: > On Thu, Jun 21, 2018 at 09:45:27AM +0200, Thomas Goirand wrote: > > Has any of you ever tried terraform, and would it be worth packaging? > > Should this go in the cloud team as well? Any volunteer? > > You mean: Terraform and the providers? I don't think you want to open > that pit. > > Bastian > > -- > Without facts, the decision cannot be made logically. You must rely on > your human intuition. > -- Spock, "Assignment: Earth", stardate unknown > >
Re: Packaging terraform?
On Thu, Jun 21, 2018 at 09:45:27AM +0200, Thomas Goirand wrote: > Has any of you ever tried terraform, and would it be worth packaging? > Should this go in the cloud team as well? Any volunteer? You mean: Terraform and the providers? I don't think you want to open that pit. Bastian -- Without facts, the decision cannot be made logically. You must rely on your human intuition. -- Spock, "Assignment: Earth", stardate unknown
Packaging terraform?
Hi, Has any of you ever tried terraform, and would it be worth packaging? Should this go in the cloud team as well? Any volunteer? Cheers, Thomas Goirand (zigo)
