New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AWS VPC resources + Diff engine #697
Conversation
- Experimenting with a different state represention based on NixOS#648 - Experimenting with a diff structure that allows showing resource attributes changes before deploying if NIXOPS_PLAN env var is set. * Resource VPC dhcp options: initial nix options
need to associate the default one before deleting the dhcp options.
the dhcp options. Use the new diff structure maybe ?
* Introducing a seperate Handler class, that allows a handler to define a set of keys/options that it can manage and have an abstract method handle to be implemented by developers adding resources. A handler can also set the different dependencies that it needs to wait for before being called. * During plan operation, the diff engine chooses the minimal set of handlers that are needed to realize the change then performs a topological sort of the chosen handlers by representing them as a DAG based on the dependencies between them.
as it's a "dangerous" operation
inherit region accessKeyId; | ||
vpcId = resources.vpc.vpc-nixops; | ||
rules = [ | ||
{ toPort = 22; fromPort = 22; sourceIp = "41.231.120.171/32"; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a check if fromPort
is set otherwise the following error message is thrown:
AttributeError: 'NoneType' object has no attribute 'get'
from
from_port = int(rule_xml.find("attr[@name='fromPort']/int").get("value"))
UPDATE this problem is probably independent from this pull request. please ignore.
I tested the following: https://gist.github.com/Mic92/f262cbd1c386a15e8ffa166fda8a861f |
a nixops deploy cmd is interrupted the user can run nixops check or nixops deploy --check to have a consistent state.
Removing ip addresses also does not work yet. |
@Mic92 can you share more details on the issue you had ? is this during a machine destroy or elastic ip destroy ? |
@domenkozar @rbvermaa I'm ok to merge this if there are no objections. I tried to address some of Eelco's comments and I'll create few issues for the remaining improvements to work on them later. |
I have a machine, that I only start for benchmarks. As I have not found a way to remove an elastic ip, when the machine was stopped, I have removed it manually in the web interface. To assign a new ip I created a new resource in nixops each time. Now I have a number of obsolete
|
eip api call doesn't throw a client error in case the eip doesn't exist and only return an empty list.
@AmineChikhaoui thanks. that solved the issue. |
resources. use a smaller instance for tests/example.
@domenkozar @rbvermaa Would you mind looking at this again. I've added few basic tests to |
yay 🎆 , thanks @edolstra |
This PR adds integration for AWS VPC resources and an implementation of the ideas discussed in #648 .
The suggested way of implementing resources is by using a diff engine that can be instantiated using
nixops.resources.ec2_common.setup_diff_engine()
this diff engine will handle the comparison between the state and the target configuration and then generate a plan which is composed of the various handlers that needs to be called to realize the target state.A resource can basically define the handlers and setup the right dependencies between them e.g
self.handle_entries = Handler(['entries'], after=[self.handle_create_network_acl], handle=self.realize_entries_change)
This means that this handler will handle the entries option changes and will run after create_network_acl if they're invoked in the same deploy operation and will use the method realize_entries_change to realize the required changes.
There is an experimental option --plan-only (supported only for the VPC resources which can be added to the
nixops deploy
cmd to show the changes that will be made and exit.Note that this doesn't implement a global DAG for the resources in a network but rather for the attributes handlers per resource.
For the VPC resources, what was already implemented is:
The remaining work:
I would appreciate some initial feedback on the suggested implementation of #648 though to be able to make appropriate changes if needed.