Skip to content
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

libvirt: Allow control over boot image configuration #587

Closed
wants to merge 3 commits into from

Conversation

@Nadrieril
Copy link
Contributor

@Nadrieril Nadrieril commented Jan 19, 2017

This PR adds a deployment.libvirtd.boot_config option that is used to specify the NixOS configuration to use for the first boot.
This is useful in non-standard configurations, for example in networks without DHCP, in case of needing external filesystems, or if special devices are enabled.
It ensures sharing of the base image to make build times reasonable.

@Nadrieril Nadrieril force-pushed the Nadrieril:libvirt-boot-config branch from 9839992 to f6dde2d Jan 19, 2017
@Nadrieril Nadrieril force-pushed the Nadrieril:libvirt-boot-config branch 2 times, most recently from 712fa00 to 972e89b Jan 25, 2017
@rbvermaa
Copy link
Member

@rbvermaa rbvermaa commented Jan 30, 2017

Could you remove the 499 fix from this PR?

@Nadrieril
Copy link
Contributor Author

@Nadrieril Nadrieril commented Jan 30, 2017

It doesn't work without it, so I would rather wait for #596 to be merged before removing it (by then rebasing on top of master).

@domenkozar
Copy link
Member

@domenkozar domenkozar commented Feb 3, 2017

I don't think we should inline make-disk-image here. The last thing we want is to fragment that code again, after investing so much time to generalize it.

@Nadrieril
Copy link
Contributor Author

@Nadrieril Nadrieril commented Feb 7, 2017

Well, it was already pretty much inlined already. Should I replace it with make-disk-image directly ? I thought there were some issues with it like NixOS/nixpkgs#20471.
On the other hand I do need to inline bits of it for the edit_image function, because I don't think there exists any equivalent function in nixpkgs yet.

@copumpkin
Copy link
Member

@copumpkin copumpkin commented Feb 20, 2017

Also somewhat relevant (especially if you duplicate the image building code): NixOS/nixpkgs#21943

@Nadrieril
Copy link
Contributor Author

@Nadrieril Nadrieril commented Feb 20, 2017

Yes, I'm following your PRs closely :)

@3noch
Copy link

@3noch 3noch commented Apr 12, 2017

#596 was merged!

@Nadrieril Nadrieril force-pushed the Nadrieril:libvirt-boot-config branch from 972e89b to 68231c1 Apr 20, 2017
@Nadrieril
Copy link
Contributor Author

@Nadrieril Nadrieril commented Jul 16, 2017

I'm closing this because I'm not using nixops anymore. If anyone still wants this, you can fetch the branch from my fork and make a new PR yourself.

@Nadrieril Nadrieril closed this Jul 16, 2017
@3noch
Copy link

@3noch 3noch commented Jul 16, 2017

@Nadrieril Would you mind leaving it open? Regardless of whether or not it is useful to you, it is likely still useful to the rest of us.

@domenkozar
Copy link
Member

@domenkozar domenkozar commented Jul 16, 2017

+1, also if you can let us know why you're not using nixops, it might be useful feedback :)

@Nadrieril Nadrieril reopened this Jul 16, 2017
@Nadrieril
Copy link
Contributor Author

@Nadrieril Nadrieril commented Jul 16, 2017

Ok.
I'm not using nixops anymore for two reasons: I needed something like nixos-rebuild test and after trying to implement it in nixops I gave up; also I wanted to have a build host separate from the targethost.
In the end it turned out that nixos-rebuild did almost everything I needed. I'm only missing libvirt management but I'm working on a nixos libvirt module that would do that.

@Nadrieril
Copy link
Contributor Author

@Nadrieril Nadrieril commented Jul 16, 2017

Oh, and also I wanted remote deployment but the PR to add remote libvirt deployment seems stalled. And statelessness as much as possible, to make it easier to deploy from multiple machines.
Sorry if I sound like I'm complaining, I think the general idea is that nixops was not the tool I needed.

@grahamc
Copy link
Member

@grahamc grahamc commented Mar 26, 2020

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:

  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

@grahamc grahamc closed this Mar 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants
You can’t perform that action at this time.