I’ve found a common theme among PRs that pass vs fail is the line: unpacking source archive /nix/store/0d3y29xjhplqc9bsq10j3ka20k0qyl61-azure-mgmt-network-2.5.1.zip
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.
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.py 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
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)
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
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:
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”,
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
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.
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.
