I think current practice (followed by the ec2 and digitalocean backends, anyway) is not to store the API key in the NixOps state database, but to require the user to set the appropriate environment variable when creating/destroying instances.

I thought it might be something like that.

I've made a change to not store the Linode personal API key in the database.

Instead it will look first in deployment.linode.personalAPIKey, and then in env variable LINODE_PERSONAL_API_KEY.

To make this work, the MachineState has to call depl.evaluate() on MachineState.__init__, to force it to load all the properties from the user supplied definition files.

Is this ready for testing?

domenkozar: it works for me at the moment if you want to try it out.

I will run the tests today on my linode account and merge if everything is working.

See #820 to discuss nixos-infect and nixos-infect.linode

I don't really understand test_send_keys_sends_keys.py.

single_machine_secret_key.nix defines a key, but says storeKeysOnMachine = false;.

The first thing the test does after deployment is check if that key is stored on the machine using test -f /run/keys/secret.key.

Can anyone explain?

Getting the following stack trace when running tests:

Traceback (most recent call last):
  File "/nix/store/bmkc8xrrrdi59sp0487rwj3cs1wrwcyc-python2.7-nose-1.3.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/rbvermaa/src/nixops/tests/functional/single_machine_test.py", line 59, in test_linode
    self.run_check()
  File "/home/rbvermaa/src/nixops/tests/functional/test_rollback_rollsback.py", line 22, in run_check
    self.depl.deploy()
  File "/home/rbvermaa/src/nixops/nixops/deployment.py", line 1036, in deploy
    self.run_with_notify('deploy', lambda: self._deploy(**kwargs))
  File "/home/rbvermaa/src/nixops/nixops/deployment.py", line 1028, in run_with_notify
    f()
  File "/home/rbvermaa/src/nixops/nixops/deployment.py", line 1036, in <lambda>
    self.run_with_notify('deploy', lambda: self._deploy(**kwargs))
  File "/home/rbvermaa/src/nixops/nixops/deployment.py", line 975, in _deploy
    nixops.parallel.run_tasks(nr_workers=-1, tasks=self.active_resources.itervalues(), worker_fun=worker)
  File "/home/rbvermaa/src/nixops/nixops/parallel.py", line 44, in thread_fun
    result_queue.put((worker_fun(t), None, t.name))
  File "/home/rbvermaa/src/nixops/nixops/deployment.py", line 948, in worker
    r.create(self.definitions[r.name], check=check, allow_reboot=allow_reboot, allow_recreate=allow_recreate)
  File "/home/rbvermaa/src/nixops/nixops/backends/linode_backend.py", line 259, in create
    plan = LinodeState.get_plan(client, defn.type_id)
  File "/home/rbvermaa/src/nixops/nixops/backends/linode_backend.py", line 72, in get_plan
    for t in client.linode.get_types():
TypeError: 'bool' object is not iterable

Any idea why? get_types() seems to return False

Hi rbvermaa, sorry my fault for not mentioning. This is because it currently also depends on this change to nixpkgs NixOS/nixpkgs#33928

Linode changed the behaviour of the HTTP endpoint for their API, breaking the previous version.

Status update:

Linode have released their final set of breaking changes to their HTTP API. I'm waiting for them to update their Python library that calls that API, then I'll finish this up.

I tested this PR running nixops master on NixOS 18.03. I used the linode-api package from the nixos-unstable channel which is at version 4.1.8b1 of the upstream linode-api for Python.

I was able to create the single-node webserver network from the beginning of the nixops manual. I tried create, deploy, check, ssh, destroy, and delete. It all worked pretty well and I was able to browse to the webserver after deploying.

I noticed 2 minor issues compared to running the webserver tutorial with the virtualbox backend. One is that some parts of the deployment seemed to be pulling from 17.09 instead of 18.03. The other is that nixops check showed one of the systemd units failed (binfmt something?). Unfortunately I didn't write it down at the time.

This looks very promising and I hope it can be merged soon. I'm already finding it useful.

Anything that needs to be tested?

Hello, I was curious about this feature and came across your PR. Is there still a chance this will be merged?

Hi attente, the answer is 'maybe', depending on whether I can find some time to do the work needed to finish it.

The Linode API looks like it has settled down a bit now, so what I need to do is:

• Update the Python Linode API package to a recent version.
• Probably rebase this pull request to a more recent version of NixOps.
• Look again at the copy of the nixos-infect script and see if it needs any tidying. (Probably won't merge this in with the DigitalOcean one after all).
• Read the latest documentation for the Linode API and compare to the work I did to see if there are any changes.
• Run the tests again and make sure everything is working.

I have used this work a bit, and there doesn't seem to be a lot left to do.

• The rebase with master is trivial, and everything builds and works after adding linode to setup.cfg
• The Linode API only has one minor and one patch version bumps since the latest NixOS version, so I guess the changes should be minor?
• The DigitalOcean nixos-infect hasn't changed since this pull request was last updated. It does seem to need some tidying, but I personally haven't had any problems using it.

It would be nice to get this over the finish line. I'd like to help, but I'm pretty new to both nixops internals and linode, so I don't really know how to test it comprehensively.

Hello!

Thank you for this PR.

In the past several months, some major changes have taken place in
NixOps:

1. Backends have been removed, preferring a plugin-based architecture.
   Here are some of them:

   • https://github.com/NixOS/nixops-aws
   • https://github.com/NixOS/nixops-hetzner
   • https://github.com/nix-community/nixops-vbox
   • https://github.com/nix-community/nixops-libvirtd
   • https://github.com/nix-community/nixops-datadog

2. NixOps Core has been updated to be Python 3 only, and at the
   same time, MyPy type hints have been added and are now strictly
   required during CI.

This is all accumulating in to what I hope will be a NixOps 2.0
release. There is a tracking issue for that:
#1242 . It is possible that
more core changes will be made to NixOps for this release, with a
focus on simplifying NixOps core and making it easier to use and work
on.

My hope is that by adding types and more thorough automated testing,
it will be easier for contributors to make improvements, and for
contributions like this one to merge in the future.

However, because of the major changes, it has become likely that this
PR cannot merge right now as it is. The backlog of now-unmergable PRs
makes it hard to see which ones are being kept up to date.

If you would like to see this merge, please bring it up to date with
master and reopen it. If the or mypy type checking fails, please
correct any issues and then reopen it. I will be looking primarily at
open PRs whose tests are all green.

Thank you again for the work you've done here, I am sorry to be
closing it now.

Graham

To be fair, I should've finished this thing 2 years ago.

I guess I'm going to be spending some time at home for a while, so maybe I can look at redoing this for the new plugin architecture.