lp:~hardware-certification/maas-cert-server/trunk

Created by Jeff Lane on 2014-03-27 and last modified on 2017-04-12
Get this branch:
bzr branch lp:~hardware-certification/maas-cert-server/trunk
Members of hardware-certification-users can upload to this branch. Log in for directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
hardware-certification-users
Project:
maas-cert-server
Status:
Development

Recent revisions

76. By Jeff Lane on 2017-04-12

fixes a typo that broke automatic setting of KVM images in conf file during deployment.
Also adds bits to automatically set LXD images in conf file if they exist on the MAAS server.

75. By Jeff Lane on 2017-04-12

adds ability to mirror LXD images in the cloud dir on hte MAAS server

74. By Rod Smith on 2017-04-04

This MR fixes bug #1679758, which was blocking deployment of Ubuntu 17.04 zesty beta on MAAS when our custom preseeds were in use. There were two issues:

1) Under zesty, installing canonical-certification-server results in
   the installation of mailutils, which in turn causes postfix to
   be installed. Unfortunately, postfix requires interaction during
   installation, so everything falls apart. Explicitly installing
   sendmail along with canonical-certification-checkbox causes
   postfix to not be installed, thus working around this issue.
2) The "secureid" mini-script in the preseed was causing something
   in /dev to remain open, thus preventing it from being
   unmounted at the end of the installation, and the install
   would then fail. Adding "sleep 5;" to the end of the
   "secureid" mini-script seems to fix this problem.

I've applied these fixes to both the standard and custom preseeds and tested with both, although we probably won't be using custom images with zesty or later.

73. By Rod Smith on 2017-01-19

Fixes oldish but minor bug that caused maniacs-setup to complain about small MAAS API changes.

72. By Rod Smith on 2016-12-09

This merge adds automatic configuration of virtualization images to /etc/xdg/canonical-certification.conf via MAAS curtin userdata files. Specifically:

- The node uses wget to see what images are available in the gateway's
  (assumed to be MAAS server's, as in other curtin userdata functions)
  web server's /cloud directory.
- If one or more images with a filename of the form
  ".*$DISTRIB_CODENAME-server-cloudimg-$arch.*img" exists, the first of
  these is set in the conf file.
- If such an image does not exist, but image(s) of the form
  ".*server-cloudimg-$arch.*img" exists, the last of these is set in
  the conf file. (Presumably the last one will be the most recent
  Ubuntu version.)

71. By Rod Smith on 2016-12-09

Some simple formatting changes I noticed would be desirable when doing a MANIACS revision.

70. By Jeff Lane on 2016-11-18

hotfix to address changes in curtin_userdata

69. By Rod Smith on 2016-11-17

Make maniacs-setup less aggressive in what it pulls down for cloud images for virtualization tests. This change enables the user to specify what Ubuntu releases and architectures to get (defaults to the latest LTS and amd64 ONLY), then grabs the .img files for those versions only, omitting other versions and unnecessary extra files from the cloud-images.ubuntu.com site. This greatly reduces bandwidth used and storage space required on the server.

68. By Rod Smith on 2016-11-17

This is not-quite-a-fix for bug #1641971 (using maniacs-setup fails to import i386 images by default under MAAS 2.1, resulting in error messages). Instead of addressing the issue head-on, this version returns the script to the behavior it had in the past (with MAAS 2.0): It imports i386 custom images if and only if standard MAAS i386 images already exist on the server. The error messages seem to be a result of pxelinux being split out into its own unique image in MAAS 2.1, which was not the case with MAAS 2.0. This results in the need for a more complex test to see if an i386 image is loaded. Note that, because this doesn't precisely address the issues in bug #1641971, I have not marked this as a fix for that bug.

67. By Jeff Lane on 2016-11-16

Removes the code at the end of the curtin_userdata files. This code was causing the deployments to choke, the default MAAS Curtin_userdata files no longer include those lines, so removal should be safe.

To test, I did Xenial custom and stock deployments on 2.1, and Xenial and Trusty custom and stock deployments on 2.0 and all were successful with the modified curtin_userdata files.

Power was also tested successfully on 2.0 using modified curtin_userdata files.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.