NixOps - Travis CI test failure on Azure private IP PR

So I’m trying to address Azure deployment should allows use of private IP for deployment/ssh. · Issue #767 · NixOS/nixops · GitHub with, but Travis CI keeps kicking back issues similar to .

I’ve found a common theme among PRs that pass vs fail is the line:
unpacking source archive /nix/store/

In builds that succeed, I’m seeing that they point to a location in the nix store corresponding to nixops.

Any way you slice it, hacking on nixops is new to me, so I could use some guidance in getting this PR sorted out. Any advice?

Yup. There is a slew of PRs both in Nixpkgs and NixOps to fix this. Until both sides are fixed, you’ll have that error because the azure library changed.

1 Like

Amine-Chikhaoui said the same (more so that TravisCI is using the unstable branch rather than the 18.09 branch (where I did my hacking)- the unstable branch doesn’t have a working nixops anyway to my knowledge due to a dependency issue).

Just ran python2 tests.functional -A azure to verify in the interim and all tests passed.

Hoping the PR does some good for anyone needing Azure vm private IPs

The version of the azure library used in NixOps is from 4 years ago.

Until someone feels responsible for bringing it up to date and fixing further issues, I think we should remove Azure support from Nixops.

What do you think?

I’d have to disagree with you there.

My use cases may be limited, but I’m currently able to utilize Azure fairly effectively using NixOps (I always stick to an LTS, like 18.09, tho).

That said, I’m starting to get more involved in the community (I actually pushed a fix for this private IP problem that is a bit too naiive (I’ll be legitimately fixing it shortly now that I’ve legitimately fixed it for GCE as well), so I at least have some familiarity with the code base at this point) and my current employer is a Microsoft partner- so the responsible party you mention may in fact be me (I definitely feel an onus to beef NixOps up for enterprise (I mean hell, this stuff conquered Google Anthos’ territory years ago)).
I definitely have access to an MPN account at the moment and have personally drank the Nix kool-aid all the way down to Disnix… (methinks my only obstacle is my own newb-idity)


It’s great to hear that you drank the koolaid and that you’re willing to help :slight_smile:

But as you say, you’re on an older nixpkgs version, so you agree that this issue is blocking updates.

Wouldn’t it therefore make sense to remove Azure support from master, fix it on a branch, and merge it back once it’s ready?

What do we gain by having a broken 19.03 NixOps?

To my understanding, it still /works/ on 19.03 as well. The only broken version is on the unstable branch- I’ll test that out at work to verify, but either way, I guess I don’t see what you mean by “drop support”.

From my own perspective, I want to pull many people into the fold and my employer is a Microsoft partner, so having Azure support is vital to me in getting others on-boarded to Nix.

As long as we can use an LTS to continue to use NixOps in Azure like we currently do, I guess I have no qualms with what you’re suggesting- but my next move after squaring this private IP space nonsense up would then be to update whatever has changed from an Azure API perspective to something modern so that “NixOps doesn’t support Azure” is true for as least amount of time as possible

I don’t think it works, see here.

And even if that were to be merged and backported, it seems to me there could be other problems (although haven’t had time to verify).

Ah- I see.

Still, I hesitate to “drop support” when it’s the platform I’m using with most of my clients and coworkers. I really think we could see a big Nix usage uptick in the US if cloud support were to continue for AWS, GCE, and Azure.

To that end, I’m running a few tests today (I actually think my private IP fix for Azure wasn’t so naiive after all- going to switch my mgmt srvr to gce today and verify) and after that, I’d love to stop us from “dropping support” by immediately grinding away at the updated API issue :salute:

Also, I just verified on my hyper-v instance that I just upgraded to 19.03- you are indeed correct: it is broken there as well as master

I’ve created a PR to disable the Azure backend for now. disable Azure backend :( by AmineChikhaoui · Pull Request #1131 · NixOS/nixops · GitHub
I’d like to get some feedback on that before merging. I realize that it’s quite unfortunate but if there are other solutions, I’m happy to keep it.

I’m hoping this is the first step in a successful journey to bring support back to Azure:

1 Like

In the end, does NixOps support Azure at the moment? If not, how can one help to move this along?

I followed the above mentioned PR#60435 to PR#71797 by @jonringer (Nov 23, 2019) and as far as I could tell all issues have been closed in reference to that.

The reason I’m confused is that

  • the NixOS/nixops repo says that it “Currently supports deployments to AWS, Hetzner, and GCE”,
  • the Executing Tests section does mention Azure,
  • but there is a commit on Apr 02, 2020 saying that “The backend is broken anyway and Azure support should be reimplemented as a plugin.”.

The NixOps manual references PR#1131 but that is from April 17, 2019.

The NixOS images on Azure thread also doesn’t mention whether it is possible to do provisioning with NixOps.

my PRs were to re-enable azure-cli “v2.0” to nixpkgs. the original azure-cli was written in node, but was deprecated.

Nixops azure support was supported by very early versions of the azure python sdk. And I think those need to be updated as they are fairly out of date.

Ultimately, someone should give azure support some love in nixops to have parity of the other public clouds, but that someone is not me :slight_smile:

1 Like

I saw that you are busy with all things Nixpkgs (besides work) so I don’t blame you. I have zero experience with Python, only with Ruby, but I guess some of that could be translated to the former.

I was trying to figure out where to start, and noticed that there doesn’t seem to be a consensus where backends should live (or maybe that doesn’t even matter):

  • NixOS has nixops itself, nixops-dashboard, and the backends nixops-aws and nixops-hetzner
  • nix-community holds the rest of the backends (libvrt, GCE, VirtualBox, Datatog)

There also seems to be 2 versions of the NixOps manual:

I started my effort while working for an Azure-minded consultancy.

At the time, Azure deployments were supported, albeit through the beta libraries that were originally used to create the support.

My commit was a manual update of the used python dependencies that ended up working fairly well in Azure, but the more I looked back at my code, the more broken I realized I’d made a few things (I had a need to expose private ips in Azure to work smoothly with a client I was working with- to be clear, the Azure shop I was in did not value nix, so this was done in my personal time).

IIRC The feedback I received on the library updates was that the manual process was untenable (which I agree with) and that an automated solution that meshes with nixpkgs would be preferred (which I also agree with).

I was a total noob at the time, so I put a pin in my efforts. Since then I’ve found other employment and no longer use the Azure cloud as a backend.

1 Like

Thanks for sharing your experiences - it seems that I am you a year later:) The reply below from another thread suggests that there is more to the deprecation of the old Azure backend than just the python SDK, and other than the NixOps source itself there’s not much documentation on how to start (except maybe this thread). And yeah, I’m not a Nix* expert either.