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:
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.