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

cloud-init: 0.7.6 -> 0.7.9 + module improvements #23024

Merged
merged 7 commits into from
May 22, 2017

Conversation

phile314
Copy link
Contributor

Motivation for this change

Update cloud-init version and make the configuration an option. Also properly wait for online network. Based upon earlier work by @alexandergall .

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@mention-bot
Copy link

@phile314, thanks for your PR! By analyzing the history of the files in this pull request, we identified @FRidh, @domenkozar and @madjar to be potential reviewers.

@nlewo
Copy link
Member

nlewo commented Feb 21, 2017

I think a lot of cloud-init modules enabled by default don't work on nixos. Maybe it would be better to just set those that we use (this could be addressed later).
Otherwise, LGTM.

@phile314
Copy link
Contributor Author

I agree that the default config probably should be changed, but I don't know enough about cloud-init to do that myself. I only added the distro setting, apart from that the config is just copied from the current NixOS cloud-init module. But as you said, this can still be improved later on.

@nlewo
Copy link
Member

nlewo commented Feb 25, 2017

I don't understand why you need networkd? Could you precise a bit your use case?
Since cloud-init can do several retry to fetch datas, we could assume it will be able to get them.
Moreover, since it is possible to use cloud-init without network (by attaching an iso that contains datas), I thiknk we should not depend on networkd.

@fpletz
Copy link
Member

fpletz commented Feb 25, 2017

network-online.target is fixed by 66f5539 so the dependency on networkd can be dropped.

@phile314
Copy link
Contributor Author

The example code I based this PR on had a network-online.target dependency, that's why I added the service dependency. But you are right, this is unnecessary as cloud-init will just retry. The networkd dependency was just to work around the (now fixed) bug mentioned by @fpletz . I will remove the networkd dependency and change the service dependency from network-online.target to network.target tomorrow.

@phile314
Copy link
Contributor Author

phile314 commented Mar 6, 2017

I made the changes, any more comments?

@nlewo
Copy link
Member

nlewo commented Mar 6, 2017

I didn't try it again but code looks good to me.

@nlewo nlewo mentioned this pull request Mar 6, 2017
7 tasks
@@ -19,10 +20,15 @@ in pythonPackages.buildPythonApplication rec {
--replace /etc $out/etc \
--replace /lib/systemd $out/lib/systemd \
--replace 'self.init_system = ""' 'self.init_system = "systemd"'
substituteInPlace cloudinit/sources/DataSourceAltCloud.py \
--replace /sbin/modprobe ''${kmod}/bin/modprobe \
--replace /sbin/udevadm ''${systemd}/bin/udevadm
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will these quoted systemd refs ever be substituted?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, that's wrong. Nothing broke when I removed those, so doesn't seem to be necessary.

@phile314
Copy link
Contributor Author

phile314 commented Mar 9, 2017

ping

Travis build error looks unrelated:

error: while querying the derivation named ‘kiwix-0.9’:
while evaluating the attribute ‘nativeBuildInputs’ of the derivation ‘kiwix-0.9’ at /tmp/nix-build-nixpkgs-tarball-17.09pre1234.abcdef.drv-0/nixpkgs/pkgs/applications/misc/kiwix/default.nix:38:3:
cannot coerce a set to a string, at /tmp/nix-build-nixpkgs-tarball-17.09pre1234.abcdef.drv-0/nixpkgs/pkgs/applications/misc/kiwix/default.nix:38:3

@phile314
Copy link
Contributor Author

ping

1 similar comment
@phile314
Copy link
Contributor Author

ping

@@ -19,15 +20,17 @@ in pythonPackages.buildPythonApplication rec {
--replace /etc $out/etc \
--replace /lib/systemd $out/lib/systemd \
--replace 'self.init_system = ""' 'self.init_system = "systemd"'

patchPhase
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you call the patchPhase again from within the patchPhase?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this won't work. Best to move all this into prePatch.

Copy link
Contributor

@alexandergall alexandergall Apr 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why wouldn't it? It does work AFAICT (my understanding is that this will simply call the original patchPhase script, won't it?). But prePatch is probably cleaner.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It definitely does work, but don't ask me why :-) Anyway, I will change it to use prePatch.

@alexandergall
Copy link
Contributor

The problem is that now the original patch phase script is not run and hence the add-nixos-support.patch patch is not applied. That was the purpose of the call to patchPhase. This is not a recursion as @FRidh seems to have implied (one patchPhase is the name of a built-in shell script, the other is just the name of an attribute).

@phile314
Copy link
Contributor Author

Sorry, my bad, I only tested the build after that change but I forgot to actually run my test VM. You are right, the call to patchPhase is necessary and I reverted that change. I also disabled the set_hostname/update_hostname functionality by default, as this broke the cloudinit test in #23173 .

@alexandergall
Copy link
Contributor

It appears that /etc/ is mounted read-only since 17.03, that's why the standard set_hostname module no longer works. I guess this needs to be fixed in the nixos cloud-init distro.

Also, resizing of the root disk doesn't work because growpart is missing. Can you please add it to pkgs? Here is how I build it in my cloud-image code: https://github.com/alexandergall/nixos-cloud-image/blob/master/nixos/modules/services/system/cloud-init.nix

@phile314
Copy link
Contributor Author

phile314 commented Apr 21, 2017

The growpart support should now work, but is untested as there is no nixos test case for it and I don't have any other test VMs at hand right now. But I tested that cloud-init itself still works, so it doesn't do any harm.

I think this PR should be merged as-is, the hostname problem can be solved in a separate PR. It's broken with the current cloud-init package in NixOS too anyway, so there is no regression here, only improvements.

@alexandergall
Copy link
Contributor

growpart runs into at least one of the problems I've fixed in my build rules, i.e. it doesn't find gnused in its search path. I also had to fix up the reference to awk. And maybe you should check whether cloud-utils-0.29 has the two patches applied to make it work with sfdisk and partx.

@alexandergall
Copy link
Contributor

While you're at it, can you please add

# Usage:
# $ NIX_PATH=`pwd`:nixos-config=`pwd`/nixpkgs/nixos/modules/virtualisation/cloud-image.nix nix-build '<nixpkgs/nixos>' -A config.system.build.cloudImage

{ config, lib, pkgs, ... }:

with lib;

{
  system.build.cloudImage = import ../../lib/make-disk-image.nix {
    inherit pkgs lib config;
    partitioned = true;
    diskSize = 1 * 1024;
    configFile = pkgs.writeText "configuration.nix"
      ''
        { config, lib, pkgs, ... }:

        with lib;

        {
          imports = [ <nixpkgs/nixos/modules/virtualisation/cloud-image.nix> ];
        }
      '';
  };

  imports = [ ../profiles/qemu-guest.nix ];

  fileSystems."/".device = "/dev/disk/by-label/nixos";

  boot = {
    kernelParams = [ "console=ttyS0" ];
    loader.grub.device = "/dev/vda";
    loader.timeout = 0;
   };
          
   services.openssh.enable = true;
   services.openssh.permitRootLogin = "without-password";

   users.extraUsers.nixos = {
     isNormalUser = true;
   };
          
   security.sudo.extraConfig = ''
     nixos ALL=(ALL:ALL) NOPASSWD: ALL
   '';
          
   services.cloud-init.enable = true;
}

as nixos/modules/virtualisation/cloud-image.nix? That's what I use to create a disk image. This also creates the user nixos. I suggest to use that as the default via

system_info:
  distro: nixos
  default_user:
    name: nixos

  users:
    - default

  disable_root: true

That's what cloud images usually do (e.g. Ubuntu has the user ubuntu and a login attempt for root will tell you what to do).

@phile314
Copy link
Contributor Author

@alexandergall I don't follow, what has the cloud-image.nix to do with cloud-init? This PR is about updating/improving the cloud-init servcie, not about the image generation itself.

@alexandergall
Copy link
Contributor

It seems logical to me to include it in this PR because cloud-init is all about booting an image and it would save a PR. Feel free to ignore it if you don't agree and I'll create a PR for it myself.

@grahamc
Copy link
Member

grahamc commented Apr 24, 2017 via email

@alexandergall
Copy link
Contributor

Here is the problem with growpart, i.e. the build recipe for cloud-utils

  buildPhase = ''
    mkdir -p $out/bin
    cp bin/growpart $out/bin/growpart
    sed -i 's|awk|gawk|' $out/bin/growpart
    sed -i 's|sed|gnused|' $out/bin/growpart
    ln -s sed $out/bin/gnused
    wrapProgram $out/bin/growpart --prefix PATH : "${stdenv.lib.makeBinPath [ gnused gawk utillinux ]}:$out/bin"
  '';

I don't understand the reason for the replacements, since sed and awk are already contained in thegnused and gawk packages. The line ln -s sed $out/bin/gnused creates a dangling symlink that actually breaks growpart. I've verified that the trivial

  buildPhase = ''
    mkdir -p $out/bin
    cp bin/growpart $out/bin/growpart
    wrapProgram $out/bin/growpart --prefix PATH : "${stdenv.lib.makeBinPath [ gnused gawk utillinux ]}"
  '';

works as expected.

@nlewo
Copy link
Member

nlewo commented May 12, 2017

@alexandergall I don't understand the relationship between this PR and your last comment. Could you open another PR or issue to speak about the problem you mentioned?

I personally really would like to see this PR merged since it improves the current cloud-init module.

@alexandergall
Copy link
Contributor

cloud-init is basically useless without a working growpart. Why not fix it right here? @phile314 commented The growpart support should now work, but is untested. I tested it and it doesn't work. Is there a policy in this community that a broken dependency must be fixed in a separate PR?

@phile314
Copy link
Contributor Author

phile314 commented May 13, 2017

Sorry for having been a bit unresponsive here lately, has been a busy month... I can't really spend much more time on this PR. While having bugs in the cloud-init package is not so nice, I strongly suggest that we merge this if there are no regressions. As growpart is already broken in the old version, the growpart bug is not a regression. Please open a separate PR/Issue for any remaining bugs.

@alexandergall While I can understand your point of view, this PR has already been open for a long time and I am very reluctant to put anything more into it. Delaying it anymore increases the risk of not merging this at all. I think the best way forward is to merge this improvement and make separate issues/PRs for any remaining issues. Also, this PR appears to be useful to other people so we shouldn't block it indefinitely.

@alexandergall
Copy link
Contributor

@phile314 sure, please go ahead.

@phile314
Copy link
Contributor Author

Ping. Can we merge this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants